10

I'm having a sudden issue SSHing into my server:

ssh -v --@--
OpenSSH_7.2p2 Ubuntu-4ubuntu1, OpenSSL 1.0.2g-fips  1 Mar 2016
debug1: Reading configuration data /home/paul/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to -- [--] port 22.
debug1: Connection established.
debug1: identity file /home/paul/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paul/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paul/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paul/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paul/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paul/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paul/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paul/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu1
debug1: Remote protocol version 1.99, remote software version OpenSSH_6.6.1p1
debug1: match: OpenSSH_6.6.1p1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to --:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
ssh_dispatch_run_fatal: Connection to -- port 22: DH GEX group out of range

I've read this question SSH: DH_GEX group out of range extensively however it doesn't seem to answer this. I control both the client and the server, they both use regular OpenSSH and Ubuntu Linux. No 3rd party. The error seems a bit different too, it's not complaining about the bitsize.

Community
  • 1
PaulBGD
  • 203
  • 1
  • 2
  • 6

2 Answers2

10

If you want to use newer OpenSSH to connect to deprecated servers:

ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-dss my.host.com

Add -v if you want to see what's happening, and -o HostKeyAlgorithms=ssh-dss if it still doesn't work:

ssh -v -o HostKeyAlgorithms=ssh-dss -o KexAlgorithms=diffie-hellman-group14-sha1 my.host.com

You can also, of course, edit /etc/ssh/ssh_config or ~/.ssh/ssh_config, and add:

Host my.host.com *.myinsecure.net 192.168.1.* 192.168.2.*
    HostKeyAlgorithms ssh-dss
    KexAlgorithms diffie-hellman-group1-sha1

https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 mentions the following fix on Mikrotik Routerboards:

/ip ssh set strong-crypto=yes

(Noting this here because this answer also comes up on web searches when looking for a similar error message.)

If you want to use it over Git without editing your ssh_config or updating the SSH server:

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@host/path-to-repository
Dagelf
  • 625
  • 5
  • 15
  • 1
    Thanks, this was a helpful answer. I would add that it is also possible to specify `-o diffie-hellman-group14-sha1` only, and that is still generally considered secure and will comply with most organizations' security policies at this time. Group 14 is 2048-bit. Especially in enterprise scenarios (like when OpenSSL/OpenSSH have been incorporated into commercial products), people will probably be using newer clients to connect to older (but patched and/or securely configured) server versions for some time. – joelhardi Feb 23 '17 at 19:59
  • 1
    (I'll note that I say this on the very day Google announced they've found a SHA1 collision so this won't be true forever! But currently 2048-bit keys are still considered secure and you can't always control who you have to interop with. People should still proceed with dropping SHA1 when they can.) – joelhardi Feb 23 '17 at 20:01
7

It looks like you are running a newer OpenSSH client (OpenSSH 7.2p2) against an older OpenSSH server (OpenSSH 6.6.1p1). In the OpenSSH 7.1p2 release notes, it mentions:

  • ssh(1), sshd(8): increase the minimum modulus size supported for diffie-hellman-group-exchange to 2048 bits.

From the error message reported, it looks like it is your client which is refusing the DH group exchange value presented by the _server.

Thus I am wondering if the "sudden issue" started happening around the time when your client machine had some packages/updates applied.

According to this SecurityExchange post, which describes a very similar issue, the "solution" may be to a) modify the /etc/ssh/moduli file on the server end such that the server does not use DH groups smaller than 2048 bits, or b) upgrade the server to OpenSSH 7.1p2 or later.

Community
  • 1
Castaglia
  • 3,349
  • 3
  • 21
  • 42
  • Thanks for the help, there's one bit that's missing though. Since I was running Ubuntu 14.04, there was no package for openssh 7.1p2 I could install. Updating Ubuntu and upgrading my packages fixed this issue. – PaulBGD Jun 28 '16 at 17:47