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:

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

Krizalys’s picture

Component: User interface » Git
Category: support » feature

Tagging.

Krizalys’s picture

Issue summary: View changes

Proposed resolution reworded

Krizalys’s picture

Issue summary: View changes

Clarification.

Krizalys’s picture

Issue summary: View changes

Clarification.

Krizalys’s picture

Issue summary: View changes

Link to OpenSSH

Krizalys’s picture

I 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.

helmo’s picture

Just 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?

Krizalys’s picture

Yes, 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.

Krizalys’s picture

Issue summary: View changes

Markup

pol’s picture

Same problem with net-misc/openssh-6.4_p1-r1 on Gentoo.

uhkis’s picture

Gentoo users probably knew this already, but adding
net-misc/openssh -hpn to /etc/portage/package.use fixes the problem for Gentoo.

mvlabat’s picture

Thank you, Uhkis, your solution helped me a lot! It's a pity that I only found it after 2 weeks struggling.