ssh_exchange_identification: read: Operation timed out

July 12, 2016 2.4k views
LAMP Stack Apache

I usually connect to any droplet using ssh and works normally. Somehow it stopped working and I keep getting the following error:
sshexchangeidentification: read: Operation timed out
Any idea what caused this issue?

14 Answers

@majidhassan @getsavi16
I managed to access the droplet but this is not a final fix so this may help you until the issue is solved.

  1. Reset droplet root password
  2. Use Opera Developer version and enabling VPN
  3. Login to digitalocean and open the droplet's console access
  4. Login using username and the password sent by email.

The console works perfectly without any lagging

It's hard to say for sure without more information but here is what I would check.

1.) run your ssh connection attempt with -vvv to get fully verbose output from the attempt.

2.) Check to be sure that your ssh service is running on your server

3.) Check for any networking issue between your location and your droplet by running a ping and traceroute (or MTR) to check for packet loss or extremely high latency.

I ran it using -vvv and I got the following:

OpenSSH6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh
config
debug1: /etc/ssh/sshconfig line 20: Applying options for *
debug1: /etc/ssh/ssh
config line 102: Applying options for *
debug2: sshconnect: needpriv 0
debug1: Connecting to 46.101.210.170 [46.101.210.170] port 22.
debug1: Connection established.
debug1: identity file /Users/safwany/.ssh/id
rsa type 1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/safwany/.ssh/idrsa-cert type -1
debug1: key
loadpublic: No such file or directory
debug1: identity file /Users/safwany/.ssh/id
dsa type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/safwany/.ssh/iddsa-cert type -1
debug1: key
loadpublic: No such file or directory
debug1: identity file /Users/safwany/.ssh/id
ecdsa type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/safwany/.ssh/idecdsa-cert type -1
debug1: key
loadpublic: No such file or directory
debug1: identity file /Users/safwany/.ssh/id
ed25519 type -1
debug1: keyloadpublic: No such file or directory
debug1: identity file /Users/safwany/.ssh/ided25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH
6.9
sshexchangeidentification: read: Operation timed out

  • @omarsafwany - At least you know it's connecting. In addition to checking the networking (as described by @ryanpq), try this procedure:

    1. login with root privileges via the DO control panel access window
    2. from the command line: tail -f /var/log/auth.log
    3. now remotely try logging in via ssh

    Did the connection attempt from your remote IP show up?

@gndo The console is stuck and I can't type anything. Even if I close it and open again, I am still stuck at the same directory and can't type anything

  • @omarsafwany - Hmm, seems like your system is overloaded. Look in your droplets graphs in the DO control panel to see if there is some extreme activity in one of the graphs.

    • @gndo currently nothing is overloaded but it happened a few times maybe when the console was stuck. Anyways the console is working now and I tried what you stated. Check the screenshot I have attached

@gndo I tried what you mentioned and indeed it showed up I am trying to connect. Unfortunately it kept saying failed password. Check this screenshot

  • @omarsafwany - For now, we'll ignore that you are vulnerable to a brute force attack if you allow password login using ssh, but you should correct that soon. It sounds like your ssh keys are not being recognized for use with that login. That could be cause by a few things, but first thing to check is to make sure your public key is in the authorized_keys file for that login.

I have the same issue. My machine was working fine, then suddenly I started getting this error. Also, any newly spawned droplets have the same issue for some reason.

I tried @gndo's suggestions, checking whether I had any overload, I didn't but resized the droplet anyways. I'm trying to connect using the console, but that isn't working either.

@omarsafwany I'm curious, what your fix/problem was after all.

@majidhassan It just went back working the next day without doing anything else. But I really could not figure out the cause of such problem.

@omarsafwany It turned out it's an issue with my ISP :/ are you by any chance also in Egypt? :D

@majidhassan Yes I am in Egypt. The issue occurred again and till now it's not working. :/

Bumping this guys. I'm in Egypt as well and getting the exact same issue. Anyone make any progress on this?

@omarsafwany Good to know that that's one possible solution.

I talked to TE Data today. They're my current ISP and they control Egypt's Internet backbone as I understand it. They are experiencing some outages with certain services. Not sure if this is related or not, but thought I'd share.

Also, I managed to work around the issue by SSHing into a DO droplet that's working fine for me and then SSHing from that droplet into the otherwise problematic one. Again not a comfortable final solution but works for now.

Egypt seems to be blocking some of the data-centers for DO. Take a snapshot of your server, and deploy it in a different region. I tried Singapore and it worked fine.

  • @sobhy I tried to do so but I can only create a droplet in the same country the original droplet was created. I can not create new one with the snapshot in another region.

    • Just go to snapshots => More ==> add to region

      • Tried Frankfurt again and Singapore but only connected once. After that, the connection got blocked again and back again to the same issue.

Welcome to Egypt !

Same issue here,
Was working fine past week then stopped then worked again,,
and now stopped again :)

Same problem here in Egypt, I have tried a couple of different ISPs but in vain

Have another answer? Share your knowledge.