This checklist helps rapidly diagnose SSH server issues, segmenting the problem into whether it’s network, firewall or SSH server configuration issues.

This checklist is OpenSSH + Debian/Ubuntu centric. Some systems (particularly embedded) may use iptables or nftables directly instead of high-level ufw.

Check if the SSH server is actually running. Errors in /etc/ssh/sshd_config can prevent the SSH server from running.

service ssh status

should show feedback including:

Active: active (running)

If not, try

service ssh restart

If restarting SSH server allows connections, be sure that after rebooting the server, the SSH server still works. This could help avoid a costly trip back to the site later.

From the laptop, error

Connection refused.

can simply mean the SSH server is not running.

Firewall: check port SSH server is supposed to be on in /etc/ssh/sshd_config. Look for Port 22 or whatever you have set SSH server to be on. Although “security through obscurity” is not the goal of changing to a non-default SSH port, it can drastically reduce the amount of log flooding.

Check that firewall is open on the SSH server port.

ufw status

22/tcp ALLOW Anywhere

22/tcp (v6) ALLOW Anywhere (v6)

Check that packets are making it from the SSH client to the SSH server by on the server

tcpdump port 22 -n -Q inout

note that you can specify the desired network interface as revealed by ip a with the tcpdump -i option. When the SSH client attempts to connect, the SSH server tcpdump should show packets coming in on the desired port with the client IP address also shown. If not, see if the network itself has a firewall that’s blocking your packets.

Logs: should see attempts to connect showing in /var/log/auth.log. Try

tail -f /var/log/auth.log

to see if new attempts show up.

Fail2ban might have your laptop IP address in “jail”. Check on the SSH server to see which IP addresses are banned:

fail2ban-client status sshd