Search guides

Fix SSH that will not connect

We'll check sshd status, firewall, keys and permissions, and host key issues—or tell you when to escalate.

Troubleshooting · Servers & Linux
15–30 min
What you'll need
  • Console or physical access to the server (if SSH is down)
  • sudo on the server
Step 1 of 9

Quick triage — pick your path

Get started

Choose the option that matches what you see. You can jump straight to that section.

Show full guide

Steps

Goal: Check ssh -v output, sshd status, firewall, and keys.

Check ssh -v output

Goal: Identify the failure point.

  • Connection refused: sshd not running or not listening on port 22.
  • Connection timed out: firewall blocking port 22 or network unreachable.
  • Permission denied (publickey): wrong key, bad permissions, or key not in authorized_keys.
  • Host key changed: remove old key from known_hosts.
  • Good: Error identified. Proceed to the matching section.
  • Bad: Run ssh -vv and check the last lines.

Check sshd and firewall

Goal: Confirm sshd is running and port 22 is reachable.

  • On the server: systemctl status sshd (or ssh). Start it if inactive.
  • Run ss -tlnp | grep 22 to confirm port 22 is listening.
  • Add firewall rule: ufw allow 22/tcp or firewall-cmd —add-service=ssh.
  • From the client: nc -zv host 22 to test reachability.
  • Good: sshd is active and port 22 is reachable. Proceed to Fix keys and permissions if still failing.
  • Bad: Start sshd, add firewall rule, or check network.

Fix keys and permissions

Goal: Correct key file permissions and authorized_keys.

  • Client: chmod 700 ~/.ssh, chmod 600 ~/.ssh/id_rsa (or id_ed25519).
  • Server: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys. Confirm the client public key is in authorized_keys.
  • If host key changed: ssh-keygen -R hostname.
  • Good: Permissions fixed and key in place. SSH should connect.
  • Bad: Re-copy the public key to the server; check server logs with journalctl -u sshd.

When to escalate

Escalate if:

  • The server is managed by config management.
  • You cannot access the console to start sshd or change the firewall.
  • The fix requires network or security policy changes.

Provide ssh -v output and systemctl status sshd.

Verification

  • ssh user@host connects without error.
  • No “Connection refused”, “Connection timed out”, or “Permission denied”.
  • Host key is accepted (or already in known_hosts).

Escalation ladder

Work from the device outward. Stop when the problem is fixed.

  1. ssh -v Run ssh -v to identify the error.
  2. sshd and port 22 systemctl status sshd; ss -tlnp | grep 22.
  3. Firewall ufw allow 22/tcp or firewall-cmd --add-service=ssh.
  4. Keys and permissions chmod 700 ~/.ssh, 600 ~/.ssh/id_rsa; check authorized_keys.
  5. Escalate Provide ssh -v output and systemctl status sshd.

What to capture if you need help

Before calling support or posting for help, have these ready. It speeds everything up.

  • ssh -v output
  • systemctl status sshd output
  • ss -tlnp | grep 22
  • Firewall rules (ufw status or firewall-cmd --list-all)
  • Steps already tried

What does ssh -v show?

Run ssh -v user@host. Note the last error.

Run `ssh -v user@host`. Connection refused: sshd not running or wrong port—check systemctl and ss. Connection timed out: firewall or network—check ufw/firewalld. Permission denied: keys or authorized_keys—check permissions and key in authorized_keys.

Yes Unclear

You can change your answer later.

Run ssh -vv

Run `ssh -vv user@host` for more detail. Check the last lines before failure. Confirm you should see connection refused, timeout, or permission denied.

Done

Connection refused or timeout?

Connection refused = sshd not listening. Timeout = firewall or network.

Refused: On server run `systemctl status sshd` and `ss -tlnp | grep 22`. Start sshd if inactive. Timeout: Check firewall: ufw allow 22/tcp or firewall-cmd --add-service=ssh. Confirm you should see sshd active and port 22 open.

Yes No (permission denied)

You can change your answer later.

Is sshd running and listening?

systemctl status sshd; ss -tlnp | grep 22.

On server: `systemctl start sshd` or `systemctl start ssh`. Check `ss -tlnp | grep 22`. Add firewall rule for port 22. Confirm you should see sshd active and port reachable with nc -zv host 22.

Done

Are key permissions correct?

~/.ssh 700, ~/.ssh/id_rsa 600. authorized_keys 600 on server.

Client: `chmod 700 ~/.ssh`, `chmod 600 ~/.ssh/id_rsa`. Server: `chmod 700 ~/.ssh`, `chmod 600 ~/.ssh/authorized_keys`. Confirm the public key is in server authorized_keys. Confirm you should see correct modes.

Yes No

You can change your answer later.

Fix permissions

chmod 700 ~/.ssh; chmod 600 ~/.ssh/id_rsa. On server: chmod 600 ~/.ssh/authorized_keys. Add client public key to server authorized_keys if missing. Confirm you should see SSH connect.

Done

Host key mismatch?

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED.

Run `ssh-keygen -R hostname` to remove the old key. Or edit ~/.ssh/known_hosts and delete the line. Confirm you should see the warning gone and can connect (or get a new prompt to accept the key).

Yes No

You can change your answer later.

Remove old host key

ssh-keygen -R hostname. Reconnect. Accept the new key if prompted. Confirm you should see SSH connect.

Done

Done

SSH connects. If still failing, escalate with ssh -v output and systemctl status sshd.

Done

Reviewed by Blackbox Atlas

Frequently asked questions

Why would SSH not connect?
sshd not running, firewall blocking port 22, wrong key or permissions, host key mismatch, or network unreachable. Run ssh -v to see the error.
Can I fix SSH connection failures myself?
Yes. Start sshd, add firewall rule for port 22, fix key permissions, and remove stale host keys from known_hosts.
When should I escalate SSH connection issues?
If the server is managed by config management, you cannot access the console, or the fix requires network or security policy changes.

Rate this guide

Was this helpful?

Continue to