Categories
Network Technologies Security

The IT Detective agency: the case of the incompatible sftp client

Intro
I was asked for assistance with this sftp problem:

$ sftp <user@host>

DH_GEX group out of range: 1536 !< 1024 !< 8192
Couldn't read packet: Connection reset by peer

We actually spoke with the operator of the sftp server who said their server is not compatible with openSSH version 6.2

The details
you can see your version of openssh and a lot more by running it again with the <v flag:

$ sftp ‐v [email protected]

OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to securefile.drj.com [50.17.188.196] port 22.
debug1: Connection established.
debug1: identity file /home/drj/.ssh/id_rsa type -1
debug1: identity file /home/drj/.ssh/id_dsa type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version SSHD
debug1: no match: SSHD
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: kex: client->server aes128-cbc hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<7680<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
DH_GEX group out of range: 1536 !< 1024 !< 8192
Couldn't read packet: Connection reset by peer

At the same time, I could successfully connect on an older system – SLES 11 SP2 – whose detailed connection looked like this:

Connecting to securefile.drj.com...
OpenSSH_5.1p1, OpenSSL 0.9.8j-fips 07 Jan 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to securefile.drj.com [50.17.188.196] port 22.
debug1: Connection established.
debug1: identity file /home/drj/.ssh/id_rsa type -1
debug1: identity file /home/drj/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version SSHD
debug1: no match: SSHD
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: kex: client->server aes128-cbc hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'securefile.drj.com (50.17.188.196)' can't be established.
RSA key fingerprint is 13:bb:75:21:86:c0:d6:90:3d:5c:81:32:4c:7e:73:6b.
Are you sure you want to continue connecting (yes/no)?

See that version? it is only openSSH version 5.1. It seems to permit a shorter Diffie Hellman group exchange key length than does the newer version of openssh.

My solution
The standard advice on duckduckgo is to set this parameter in your $HOME/.ssh/config:

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

But this did not work for my case. And I didn’t want to change a setting that would weaken the security of all my other sftp connections. So I settled on using an additional command-line argument which is an openSSH parameter when running sftp:

$ sftp ‐o KexAlgorithms=diffie‐hellman‐group14‐sha1 <host>

And this worked!

And this works as well:

$ sftp ‐o KexAlgorithms=diffie‐hellman‐group1‐sha1 <host>

Why the change?
The minimum key length was changed from 1024 to 1536 and later to 2048 to avoid the logjam vulnerability.

Conclusion
Not all versions of openSSH are equal. In particular openSSH v 6.2 may be incompatible with older sftp servers. I showed a way to make a newer sftp work with an older server. Case closed.

References and related
Novell’s discussion of the issue is here: https://www.novell.com/support/kb/doc.php?id=7016904
Here’s some more information on the logjam vulnerability: https://weakdh.org/

Leave a Reply

Your email address will not be published. Required fields are marked *