Since this morning I'm getting the following error message when trying to connect to my remote Ubuntu 14.04 LTS machine via ssh from a MacBook Air Yosemite 10.10.1.

ssh_exchange_identification: read: Operation timed out

When using -vvv flag the following verbose message appears

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /Users/felix/.ssh/id_rsa type -1
debug1: identity file /Users/felix/.ssh/id_rsa-cert type -1
debug1: identity file /Users/felix/.ssh/id_dsa type -1
debug1: identity file /Users/felix/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Operation timed out

For many months this connection worked perfectly fine. I've never experienced any issues. Other solutions such as found here and here did not help.

Any suggestions on how to fix this issue?

2

1 Answer

debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Operation timed out

According to your debug trace, you're managing to connect to the remote SSH server, and the server isn't dropping the connection, but the server isn't sending its software identification string. This is the first thing done by client and server, and it's done in clear text.

I think the problem is going to come down to one of three things:

1. Some network device between you and the server is interfering with the connection. For example, if the remote host is behind a NAT router, the port forwarding for port 22 may be set up wrong and you're connecting to the wrong service.

2. The SSH server program on the remote host may be hanging or malfunctioning. I've seen this sort of thing happen for example when the host is heavily overloaded or low on virtual memory. Or the server may be using something like TCP wrappers, and it's doing a DNS query on your client IP which is taking a long time to resolve.

3. The remote host is set up in an unusual way, and the service running on port 22 isn't an SSH server.

If you can get to the server, focus your troubleshooting there. Find the logs for the ssh server--they ought to be in /var/log and see if it has logged anything about these failed connect attempts. Try running ssh to localhost from the server and see if that works properly.

If you have root access to the server, you can try to start a debugging instance of sshd to see what it logs when your client connects. Halt the normal sshd server, and in a root terminal window, run /path/to/sshd -d. This will run a copy of sshd which will accept one connection and print debugging information to the terminal window. See if you can reproduce the problem, and then examine what the server logged.

If you can't take the normal ssh server offline, you can run sshd on another port: /path/to/sshd -p 42 -d runs a copy of sshd listening on port 42. Specify the same port number when running the ssh client: ssh -p 42 user@host. If your problems are due to an interfering network device, this may behave differently than connections to port 22.

2

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy