Failure to clone/push using https to Express (and perhaps others) [partial solution]

[James Moger]

I am not sure when this started but sometime after the 1.2.1 release pushing/pulling from RedHat OpenShift Express stopped working.  I set aside some time the end of last week to figure out why.

It turns out there is a new (to me, anyway) way for Git https comms to fail: SNI (Server Name Identification).  This appears to be another form of hostname verification.  Unfortunately, http.sslVerify=false is not (yet) up-to-the-task of ignoring SNI failures.

I do not know all the ins-and-outs of this SSL3 feature but I can tell you that by default Java 7 enables SNI checking so JGit-based clients like EGit running on Java 7 will not be happy when confronted with an SNI alert.

For JGit-based clients this manifests as the familiar and not-too-useful "can not open upload/receive pack" message.
In native Linux Git clients this manifests as the slightly more helpful "A TLS warning alert has been received".
In native Windows Git clients this manifest as the pretty useless "error ... SSL23_GET_SERVER_HELLO:reason(1112) while accessing..."

The work-around for Java 7 is to specify a command-line JVM launch parameter to disable SNI enforcement.

-Djsse.enableSNIExtension=false

This can be set on the command-line when launching your Java app or by appending it to eclipse.ini for EGit.

I do not yet know of a workaround for native Git.

-J

[Ralf N]

Hi James,

any updates on this? My problem (which I confronted you with on twitter today.. my bad) seems to be related to this:

I have a server called devtools.mycompany.com which I can access via ssh. 

ssh -l john.doe -p 29418 devtools.mycompany.com

works fine, but every clone/push request etc. results in a password query.

Then I spotted something interesting:

The above ssh command returns the following message:

 You may clone a repository with the following Git syntax:

   git clone ssh://john.doe@DEF-SK0001.mycompany.com:29418/REPOSITORY.git

The name "DEF-SK0001" is the value returned by the "getHostname()" method on the server side. Due to firewalls, load balancer etc. I cannot access this name from the client directly, I have to use the "devtools.mycompany.com" way. 

Is there a way to overcome this problem?!

I am using native git on windows.

\Ralf

[James Moger]

SNI only applies to the https transport.

Are you running your console within an ssh-agent to cache your credentials?

-J

--
You received this message because you are subscribed to the Google Groups "gitblit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gitblit+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ralf N]

James,

to be honest,  I don't know much about ssh. I just followed your documentation to create a keypair, upload it and try to use it.

But I always get the password challenge. I assume it has to do with the discrepancy between the alias I use and the "true" hostname which is returned by the 

 ssh -v -l john.doe -p 29418 devtools.mycompany.com

statement.

But on the other hand, running this with "-v" results in:

debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/jdoe/.ssh/identity
debug1: Offering public key: /c/Users/jdoe/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

So here it seems to work. But 

git clone ssh://john...@devtools.mycompany.com:29418/TestRepo.git

results in a password challenge.

Any idea where to look?

\Ralf