It is not clear what the problem is... the third slash?

Yep. The third slash is added by the plugin.
ssh://git@github.com:/github/git.git results in ssh:///git@github.com:/github/git.git and that's an invalid url.

The git plugin does not support a colon embedded in an ssh:// protocol URL other than immediately following the protocol string (ssh). I think it is a bug in the plugin, but the investigation in the JENKINS-26680 bug report shows that there seem to be differences in handling of that style of URL between git versions.

If allowed, an alternate work around is to not include the second ":" character in the URL, but use an absolute path instead.

Are you confident that your git repository URL with the extra colon actually works from the git command line?

I have a private GitHub repository named "bin" which clones successfully on my Ubuntu 14.04 with git 2.3.3 with the command:

$ git clone git@github.com:MarkEWaite/bin.git

When I attempt to clone that same repository using what I believe is your ssh syntax, the git command line fails. My results look like:

$ git clone ssh://git@github.com:MarkEWaite/bin.git
Cloning into 'bin'...
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Hi Mark,

yes it is actually works from the git command line.
I use Jenkins within a Glassfish Server running under Windows 2008 R2 Standard.
As I described above the short notation for ssh protocol is working for me: git@github.com:/github/git.git
The extra slash after the colon is required (for me) without it won't work.

Thanks in advance.

That URL syntax seems to only work with msysgit on Windows. I haven't found a form of the ssh:// URL specification which works on multiple platforms with command line git and includes more than one ":" character in the URL. Command line git tries to interpret the first word after the second colon as a network protocol, not as part of a path to the repository in all the Linux variants I tried. I suspect it interprets similarly on other Unix variants like FreeBSD, OpenBSD, Solaris, and HP-UX.

mwaite@mark-pc1:~/tmp$ git clone ssh://git@github.com:MarkEWaite/bin.git
Cloning into 'bin'...
ssh: Could not resolve hostname github.com:markewaite: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Note that it says "github.com:markewaite: Name or service not known".

It works if I perform the same clone but with "short notation" (no ssh:// scheme specifier at the start of the URL)

mwaite@mark-pc1:~/tmp$ git clone git@github.com:MarkEWaite/bin.git
Cloning into 'bin'...

When I attempt the URL you listed in the bug report, I get a different error message than you get:

mwaite@mark-pc1:~/tmp$ git clone ssh://git@github.com:/github/git.git
Cloning into 'git'...
ssh: Could not resolve hostname github.com:: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I ran tests on various git versions and various platforms using command line git and as far as I can tell, Windows (32 bit and 64 bit, Windows 7, Windows 8, and Windows Home Server 2011 running various versions of msysgit) is the only platform where the ssh://git@github.com:/github/git.git format works.

Debian (6, 7, and 8), Red Hat (6 and 7), and Ubuntu (14.04) all reject that format in all the versions to which I have access (32 bit and 64 bit). That matches with what you described of how you're using Windows 2008 R2 Standard.

It also tells me that support of that URL syntax is too platform specific to justify spending time fixing the bug for only one platform. It is a bug that the plugin rewrites the URL to an invalid syntax, but even if it didn't rewrite the URL, the syntax would be rejected by command line git on non-Windows platforms.