Find out why SSH won’t connect or log in. Paste the output of ssh -v, or the server’s sshd log, and SSH Doctor walks through each step of the connection, shows where it stopped and gives the fix. It also checks ~/.ssh permissions and sshd_config.

RUNS ENTIRELY IN YOUR BROWSER · WHAT YOU PASTE NEVER LEAVES IT

1 · Diagnose a connection

How to get the output

On your computer (Linux, macOS or Windows), run your usual command with -v. Use -vvv for even more detail.

ssh -v user@host

On the server, the sshd log says why it refused you. With systemd:

sudo journalctl -u ssh -u sshd --since "15 min ago"

Or the log files:

sudo tail -n 50 /var/log/auth.log      # Debian, Ubuntu
sudo tail -n 50 /var/log/secure        # RHEL, Rocky, Alma, older Fedora

Still stuck? Run a second sshd in debug mode on a spare port (open it in the firewall first). It prints every decision, then exits after one connection.

sudo /usr/sbin/sshd -d -p 2222
# then, from your computer:  ssh -v -p 2222 user@host

PuTTY’s Event Log isn’t understood here. Windows 10 and 11 include OpenSSH, so run ssh -v user@host in PowerShell instead, or paste the server’s log.

Examples:

2 · Check ~/.ssh permissions

SSH silently ignores keys when files are too open. Run this as the user, on the server for login problems or on your computer for key problems, and paste the output:

ls -la ~ ~/.ssh

On RHEL, Fedora, Rocky or Alma use ls -laZ ~ ~/.ssh to check the SELinux labels too. The output of namei -l ~/.ssh/authorized_keys works as well.

User

What the permissions should be

Path	Mode	Why
Home folder `~`	`755 or 750 (or 700)`	Must not be writable by group or others, or sshd ignores your keys.
`~/.ssh`	`700`	Only you.
`~/.ssh/authorized_keys`	`600`	sshd refuses it if others can write to it. 644 also works.
Private keys (`id_ed25519`, `id_rsa`)	`600`	ssh ignores a private key others can read.
Public keys (`*.pub`)	`644`	Safe for anyone to read.
`~/.ssh/config`	`600`	ssh stops if others can write to it.
`~/.ssh/known_hosts`	`644`	Must be yours, so ssh can add new hosts.

Set them all at once

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys ~/.ssh/id_* ~/.ssh/config 2>/dev/null
chmod 644 ~/.ssh/*.pub ~/.ssh/known_hosts 2>/dev/null
restorecon -Rv ~/.ssh 2>/dev/null   # SELinux systems only

3 · Check sshd_config or ~/.ssh/config

Paste the server’s /etc/ssh/sshd_config (better still, the output of sudo sshd -T, which shows the settings sshd really uses), or your own ~/.ssh/config. It tells which one it is from the content.

Before you restart sshd

A mistake in sshd_config can lock everyone out. Keep your current session open until a new login works.

Test the file. No output means it’s valid.

sudo sshd -t

Apply it. Reload keeps existing sessions.

sudo systemctl reload ssh      # Debian, Ubuntu
sudo systemctl reload sshd     # RHEL, Fedora, Arch, SUSE

Ubuntu 22.10 and later, after changing Port or ListenAddress (sshd is started by ssh.socket there)

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

4 · Check authorized_keys

When the server log says Failed publickey, the key isn’t in the file, or its line is broken. Paste the file from the server. It holds public keys only, so it’s safe to paste.

cat ~/.ssh/authorized_keys

Fingerprints of keys from section 1 (offered by ssh, or named in the server log) are looked up here automatically.

For a single error line, the Error Message Decoder explains 12 SSH errors and 109 others.