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
nftables directly instead of high-level
SSH server running?
Check if the SSH server is actually running.
/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
can simply mean the SSH server is not running.
Network + Firewall
- check port SSH server is supposed to be on in
/etc/ssh/sshd_config. Look for
Port 22or 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.
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.
You should see attmempts to connect showing in
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