How to troubleshoot SSH connectivity

Topic: Networking basics

When SSH connection fails: check that the client can reach the host (ping, port open), that sshd is listening on the expected port, and that authentication succeeds (key or password). Use this to isolate network vs service vs auth failures and to fix 'connection refused,' 'no route to host,' or 'permission denied.'

Intent: Troubleshooting

Quick answer

  • From client: ping SERVER_IP; nc -zv SERVER_IP 22 or telnet SERVER_IP 22. If ping fails, fix routing or firewall; if port 22 is closed, sshd may be down or firewall blocking.
  • On server: systemctl status sshd (or ssh); ss -tlnp | grep 22; ensure sshd is listening on 0.0.0.0:22 (or the port you use). If listening on 127.0.0.1 only, it will not accept external connections.
  • Connection refused: nothing listening or firewall drop. No route to host: routing or server down. Permission denied: wrong key, wrong user, or auth config (PubkeyAuthentication, PermitRootLogin, etc.).

Prerequisites

Steps

  1. Test reachability and port from client

    ping SERVER_IP; nc -zv SERVER_IP 22 (or the SSH port). If ping fails, fix network or firewall; if ping works but port is closed, sshd is not listening or a firewall is blocking the port.

  2. Check server: sshd and listen address

    On server: systemctl status sshd; ss -tlnp | grep 22. Listen on 0.0.0.0:22 (or 0.0.0.0:PORT) so external clients can connect; if 127.0.0.1 only, fix ListenAddress in sshd_config and restart sshd.

  3. Check firewall on server and path

    Server: ufw status or nft list ruleset; allow inbound TCP 22 (or your port). On the path: any middlebox (router, cloud security group) must allow TCP 22 to the server.

  4. Distinguish auth failures

    Permission denied (publickey): key not in authorized_keys, wrong permissions (700 .ssh, 600 authorized_keys), or PubkeyAuthentication no. Permission denied (password): password wrong or PasswordAuthentication no. Fix keys or sshd_config and retry.

Summary

Troubleshoot SSH by checking reachability and port from the client, then on the server that sshd is running and listening on the right address and port, and that the firewall allows the connection. Then separate network failures (refused, no route) from authentication failures (permission denied). Use this when SSH connection fails so you fix the right layer.

Prerequisites

Steps

Step 1: Test reachability and port from client

ping SERVER_IP
nc -zv SERVER_IP 22

If ping fails, fix routing or firewall. If ping works but the port is closed, sshd is not listening or a firewall is blocking.

Step 2: Check server: sshd and listen address

On the server:

systemctl status sshd
ss -tlnp | grep 22

sshd must be listening on 0.0.0.0:22 (or your port) to accept external connections. If it listens only on 127.0.0.1, change ListenAddress in sshd_config and restart sshd.

Step 3: Check firewall on server and path

On the server: ufw status or nft list ruleset; allow inbound TCP 22 (or your port). On the path: ensure routers and cloud security groups allow TCP to the server’s IP and port.

Step 4: Distinguish auth failures

  • Permission denied (publickey): Key not in authorized_keys; wrong permissions on .ssh (700) and authorized_keys (600); or PubkeyAuthentication no in sshd_config.
  • Permission denied (password): Wrong password or PasswordAuthentication no.

Fix keys or sshd_config and retry.

Verification

  • From the client you can open the port (nc) and complete SSH login; or you have identified the failing step (reachability, port, or auth).

Troubleshooting

Connection refused — No process listening on that port on the server (or firewall dropping before the server); start sshd or allow the port.

No route to host — No route to the server from the client or server down; check routing and that the server is up.

Next steps

Continue to