Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a server XXX ON Amazon EC2.

SSH is running on a standard (22) port.

I placed my pubkey at the /.ssh/authorized_keys file

The fun thing is that YESTERDAY it was working great!

But today, I don't know what happened! I just can't log in.

ssh -vvvv servername

is stuck on

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

I checked my pubkey and it's there! (how I checked?? I asked the other guy to check)

and then I used another computer (windows 7 + putty) and placed my new pubkey. ANd what? I was able to log in! And that's another computer with Win7 is ont the same LAN which menas that the external IP is the same.

My private key works for other servers but not with this.

This thing is killing me )))))

Absolutely strange.

Please help!

share|improve this question
I generated NEW keys and stored new pubkey..the same thing! ha! – bakytn Dec 8 '10 at 12:48
fyi, your problem has nothing to do with pubkey authentication: the DH key exchange (SSH2_MSG_KEX_DH_GEX_REPLY) happens much earlier in the connection. – grawity Dec 8 '10 at 13:46
thank you for information. BTW GUYS, the problem has been resolved by itself. I didn't anything just tried to log in and I was successful. hah – bakytn Dec 8 '10 at 16:01
Bad network latency? much drops? Its just normal message. – Korjavin Ivan Sep 13 '11 at 6:23
probably it is. I now can't reproduce it in any way. So it might from my side. – bakytn Sep 14 '11 at 4:47
up vote 1 down vote accepted

I had the same problem after I upgraded my Ubuntu client machine. I solved my problem by reducing the size of the line "Ciphers" in /etc/ssh/ssh_config. It also works if you specify the cypher in the command line (ex: ssh -c username@hostname)

Tip from here:

share|improve this answer

Change the network interface MTU to solve it. This is a bug for ubuntu 14.04.

This worked for me:

sudo ip li set mtu 1200 dev wlan0


sudo ifconfig wlan0 mtu 1200

ssh fails to connect to VPN host - hangs at 'expecting SSH2_MSG_KEX_ECDH_REPLY'

share|improve this answer

Same exact problem here to access a dedicated server at the datacenter.

Theres no problem after a reboot, no need to change MTU, ssh connection works for 1-3 weeks, then appears this exact same bug , blocking on KEXINIT, no more possible to connect the ssh server.

It could be some kind of sshd bug, but its necessarily triggered by some nework stuff happening after 1-3 weeks, I reproduced this exact problem many times with many different servers on this network, some say it could be related to a cisco bug, possibly related with some DPI options.

That problem never happened with other servers I manage in other datacenters, and that have the exact same distro, config and sshd version .

if you dont want to reboot every 10 days because the datacenter firewalls ( or other network tweaks ) is doing weird stuff :

first connect with one of those client side workarounds :

workaround 1, lowering your local, client side MTU :

ip li set mtu 1400 dev wlan0

( 1400 should be enough but you can try to use lower values if needed )

workaround 2, specifying the chosen cypher for the ssh connection :

ssh -c host

(or try with any another available cypher )

Both of those client side workarounds made it for me, I could connect and save my uptime; but you want to fix this server-side, forever, so you dont have to ask every client to locally tweak their MTU.

On gentoo i just added :


in /etc/conf.d/net

( same mtu option should be available somewhere in your preferred distro network config file )

I ve set the mtu to 1400, but 1460 is probably enough in most cases.

another helping workaround could be to use the following iptables rules to manage fragmentation :

# /sbin/iptables -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# /sbin/ip6tables -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

( but I personaly didnt need this one until now )

also note that the symptoms of this problem can also be :

debug1: SSH2_MSG_KEXINIT sent

not just

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

edit march 2016 :

  • lowering the mtu to 1400 on the server most always work, but I recently had the case where mtu was already lowered to 1400 on the server and the problem reappeared, and the client also had to lower mtu to 1400.

  • The problem also appeared on web login forms waiting for the page to reload until saying "the server have reset the connection", also fixed after the client set the mtU to 1400.

    related links :

share|improve this answer
this can happen especially when you have a very unusual small MTU on client end, f.e. you want to use openvpn on a double-nat network. – Dennis Nolte Dec 21 '15 at 18:12
i used default mtu values before having this problem, lowering the mtu was the solution, not the problem. please explain your comment. – neofutur Dec 24 '15 at 1:55

we solved it commenting out the Ciphers line on /etc/ssh/ssh_config

share|improve this answer

It seems clear the options dialog causes an issue, because I altered the order in which Putty negotiates the key exchange and problem solved.

share|improve this answer
What seems clear? This question was answered (with an accepted answer) over 4 years ago. – David Makogon Jul 1 at 16:59


  • check your ~/.ssh/authorized_keys permission, it should be 600

  • check the on on /var/log/secure, /var/log/messages or /var/log/auth

share|improve this answer
The authorized_keys permission has nothing to do with the error since the client is stuck duing the earlier protocol negitioation. Checking the serverside logs may help, but this line is rather a comment - downvote. – try-catch-finally Jan 25 at 21:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.