Ubuntu 16.04 ssh on a LAN fails with “connection refused”

sshUbuntu

I have a desktop and laptop in a the same LAN, both running Ubuntu 16.04 x64. Both have both openssh and openssh-server installed and running.
On both ssh'ing to localhost works perfectly, and on neither ssh the other machine works, failing with connection refused.
To be more precise, ssh me@192.168.x.x leads to the same error, although the ip is one of the machine I'm trying this on.
Each machine can ping the other.
Both are using public keys for authentification.
sftp, telnet and ssh-copy-id all fail with the same error.
To the best of my ability I've tried to verify that no firewalls on either machine are blocking ssh traffic (but additional test here are welcome).

What might I be doing wrong and how can I mend that problem?

I'd gladly provide outputs for any relevant checks.

Best Answer

I've found the easiest way to resolve ssh connection issues is to use the debug mode of both the client and server applications.

On one machine, we'll call it pcA, open a terminal and run the following command:

/usr/sbin/sshd -d -p 2222

On the other linux machine, pcB, enter this command and watch the server output on pcA:

ssh -vv -p 2222 [IP Address of pcA]

What we are doing here is running a 'foreground' version of the ssh daemon on pcA, listening for connections on port 2222, running in debug (verbose) mode. On pcB we are attempting to connect to pcA as an ssh client on port 2222, in verbose mode.

  • Both pcA and pcB will output text indicating the flow of the connection process as they see it.

  • Typically the results are sufficient to make the resolution obvious e.g. permissions on your ~/.ssh directory.

    A couple tips:

    If the server sees absolutely no connection attempt from pcB, then you have a firewall or networking routing issue of some sort. In this case, try a network scan on the same port from pcB using nmap: nmap -p 2222 [ip address pcA]

    You can also call nmap with syntax nmap -A [ip address pcA] to do a general scan (including the std sshd port (22) and traceroute info. This might indicate where things are getting dropped (router firewall?)

  • If it isn't obvious post the results from both the client and server in your question.

Update

Run the command netstat -tulpn on pcA to see what is listening on what ports on that machine. It will give you an output like this:

Proto Recv-Q  Send-Q   Local Address       Foreign Address      State    PID/Program name
tcp     0       0      0.0.0.0:22            0.0.0.0:*          LISTEN     1133/sshd
tcp6    0       0      :::22                 :::*               LISTEN     1133/sshd
udp     0       0      0.0.0.0:68            0.0.0.0:*                     722/dhclient

If you run it and sshd is running normally on port 22. Post what you get in response to this command on pcA.

2nd Update Saw your response - what was ListenAddress set to before? Usually it defaults to 0.0.0.0 (which is ANY address), and there aren't issues with it.

Related Question