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/