Problem/Motivation
Although this issue is reported as a Git issue, it actually relates to the underlying SSH transport protocol onto which Git relies.
I discovered recently that the OpenSSH client cannot establish a connection to git.drupal.org server. For example, with OpenSSH 6.2p2:
$ ssh -v your_ssh_username@git.drupal.org
Will initiate the connection, ask for your passphrase if relevant, and finally stop on the second rekeying request:
debug1: rekeying in progress
To determine whether my SSH client was the problem, I conducted similar tests with:
- github.com:
$ ssh -v git@github.com - bitbucket.org:
$ ssh -v git@bitbucket.org
In both cases, this step passed successfully and the SSH connection was initialized and exited properly.
So from these results, my guess is that the SSH server used on git.drupal.org does not fully support session rekeying and prevents the connection to be established properly when using OpenSSH. The OpenSSH client then remains frozen and should be killed.
Unfortunately, it's not (yet) possible to disable session rekeying in the official OpenSSH client. This means that this client cannot be used (unpatched) when dealing with git.drupal.org, and it also means that it is not possible to push to Git repositories using OpenSSH as the SSH client, as SSH is currently the only transport protocol supported for write access.
However, as I remember that it was possible to use OpenSSH with git.drupal.org a few months ago, I believe that a recent update of OpenSSH introduced the session rekeying feature and created the problem with git.drupal.org
The system I used for these tests:
- Gentoo Linux on amd64
- OpenSSH 6.2p2
Proposed resolution
As OpenSSH is a popular SSH client, I propose to implement full support of session rekeying on git.drupal.org and improve support of latest OpenSSH versions.
Or alternatively, may other transport protocols be offered for Git write access?
Comments
Comment #1
Krizalys commentedTagging.
Comment #1.0
Krizalys commentedProposed resolution reworded
Comment #1.1
Krizalys commentedClarification.
Comment #1.2
Krizalys commentedClarification.
Comment #1.3
Krizalys commentedLink to OpenSSH
Comment #2
Krizalys commentedI did further testing regarding this problem. I downgraded to earlier OpenSSH versions. From my research, I determined that the problem happens starting from OpenSSH 6.2_p2-r4, which is a revision specific to Gentoo (and the latest one available to this OS currently).
Hence, until a resolution is found, if you are using Gentoo and intend to work with Drupal Git repositories, it is suggested to mask this version (and possibly future ones) of the OpenSSH package.
Note that the popular Ubuntu 13.10, just released, might face a similar issue since it is also based on OpenSSH version 6.2p2, although I am not able to check this myself.
Comment #3
helmo commentedJust tried this with an image from http://cloud-images.ubuntu.com/saucy/current/
Cloning worked fine here both with a forwarded ssh agent and anonymous.
Maybe Gentoo has some special build option enabled?
Comment #4
Krizalys commentedYes, I believe the issue happens when applying the latest HPN patch. Gentoo does it by default in the latest OpenSSH package.
For Saucy, the HPN patch is available separately, and if the issue does appear when applying this patch, using openssh 1:6.2p2-6hpn14v1~wrouesnel~saucy1 is likely to introduce a similar issue on Ubuntu.
I'm still not sure whether the problem is in HPN or in Drupal' SSH server, but it's worth reminding that other SSH servers (github.com, bitbucket.org) seem to handle the patched OpenSSH correctly.
Comment #4.0
Krizalys commentedMarkup
Comment #5
polSame problem with
net-misc/openssh-6.4_p1-r1on Gentoo.Comment #6
uhkis commentedGentoo users probably knew this already, but adding
net-misc/openssh -hpnto /etc/portage/package.use fixes the problem for Gentoo.Comment #7
mvlabat commentedThank you, Uhkis, your solution helped me a lot! It's a pity that I only found it after 2 weeks struggling.