Troubleshooting Common SSH 'Permission Denied' Errors and Connection Issues

An SSH Permission denied error usually means the server was reachable, but it refused to authenticate you. That is different from Connection timed out, Connection refused, or No route to host. Treating all of those as "SSH is broken" wastes time, so start by separating authentication failures from network failures.

Run the failing command with verbose logging:

ssh -vvv user@remote_host

You are looking for plain clues: which username the client used, which key files it offered, whether the server accepted any key, and which authentication methods remain. Most fixes below come from matching those clues to the server-side state.

Understanding SSH Authentication Flow

When you attempt to connect, the server allows only the authentication methods enabled in its configuration. A typical server tries public-key authentication first and may allow password authentication after that, depending on policy:

Public Key Authentication: The client presents a public key, and the server checks if the corresponding private key is valid and matches an authorized key (authorized_keys file).
Password Authentication: If key authentication fails or is disabled, the server prompts for a password.

When you receive Permission denied, the TCP connection worked. The server simply did not accept the credential you presented for that user.

Diagnosing Connection Issues: The Power of Verbose Mode

The single most effective tool for diagnosing SSH problems is running the client in verbose mode. By adding the -v, -vv, or -vvv flags, the client outputs detailed debugging information about the negotiation process.

Using Verbose Flags

Use the following command structure:

ssh -vvv user@remote_host

What to look for in the output:

Username: Look for Authenticating to ... as 'user'. A wrong Linux username is one of the easiest mistakes to miss.
Offered keys: Look for Offering public key. If the expected key never appears, fix the client configuration.
Server response: If every offered key is followed by Authentications that can continue, the server rejected those keys.
Authentication methods: If publickey is not listed, the server may not allow key authentication for that account or host block.

Resolving `Permission denied (publickey)`

This error explicitly states that the server rejected the provided public key credential. The fix usually lies in permissions or key pairing.

1. Check Key File Permissions (Client Side)

For security, SSH clients are very strict about the permissions on your private key file (e.g., ~/.ssh/id_rsa). If these files are too open, the client will refuse to use them.

Ensure your private key is only readable by you:

chmod 600 ~/.ssh/id_rsa

2. Verify Key Existence and Correct Key Use

Ensure you are connecting with the correct identity file, especially if you use non-standard keys or multiple key pairs.

Specify the correct private key using the -i flag:

ssh -i /path/to/your/specific_private_key user@remote_host

If your agent has many keys loaded, add IdentitiesOnly=yes for this test:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod user@remote_host

3. Server-Side Permissions and Ownership

This is the most common source of key-auth failure. SSH enforces strict directory and file permissions on the server for the user you are trying to log in as.

Path on Server	Required Permissions	Owner
`~/.ssh` directory	`700` (rwx------)	User
`~/.ssh/authorized_keys` file	`600` (rw-------)	User

Log in via console, cloud serial console, password authentication, or another admin account and run these commands as the target user or with the right path:

# Set directory permissions
chmod 700 ~/.ssh

# Set authorized_keys permissions
chmod 600 ~/.ssh/authorized_keys

# Verify ownership (replace 'myuser' with the actual username)
chown -R myuser:myuser ~/.ssh

If the user's home directory is writable by group or others, OpenSSH may also reject the key when StrictModes is enabled. Check with:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

For most normal user homes, 755 or stricter is fine.

4. Confirm Key is Actually Added

Ensure the public key on the client matches what is pasted into the server's ~/.ssh/authorized_keys file. A missing character, wrapped line, or copied private key will cause authentication failure.

When adding a key, use ssh-copy-id if password access is still available:

ssh-copy-id user@remote_host

Troubleshooting Configuration File Issues (`sshd_config`)

If keys and permissions are correct, the issue often lies within the SSH daemon configuration file, typically located at /etc/ssh/sshd_config on the server.

1. Check Authentication Methods

Ensure that public key authentication is explicitly allowed.

Configuration Check: Look for the following lines and ensure they are uncommented (#) and set correctly:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Also check for Match blocks near the bottom of the file. A global setting may allow public keys, while a later Match User, Match Group, or Match Address block disables them for the exact login you are testing.

2. Password Authentication Status

If you are relying on password login temporarily, verify that it is enabled. If it is set to no, you must use keys.

PasswordAuthentication yes

3. PermitRootLogin

If you are attempting to log in as root, ensure this is permitted. Best practice is generally to log in as a standard user and use sudo, but for troubleshooting, you can check this setting:

PermitRootLogin prohibit-password

For root login, many systems default to key-only root access or disable root login completely. Prefer a normal user with sudo. If you must change SSH daemon settings, validate syntax before reloading:

sudo sshd -t
sudo systemctl reload sshd  # Some systems use: sudo systemctl reload ssh

Other Common Connection Errors

While key issues are primary, other errors can block access:

A. Connection Timed Out

This usually means the client could not reach the server at all, indicating a networking issue, not an authentication issue.

Possible Causes:

The server is down or unreachable.
A firewall (local or network) is blocking the connection on port 22 (or custom SSH port).
Incorrect IP address or hostname.

Use ping for a basic reachability hint and nc to check the SSH port:

nc -vz remote_host 22

B. No Route to Host

Similar to timeout, this is a network infrastructure problem. The client cannot find a path to the server's IP address. Check routing tables, VPN status, or ensure the remote server has a valid network interface active.

C. Server Refused Our Key

If the verbose output shows the server is actively rejecting keys but you've verified the authorized_keys file, check the SELinux or AppArmor security contexts on the server. These security modules can override file permissions and block SSH access if contexts are incorrect.

A Practical Order That Usually Works

Check the username first. Then force the key you expect with ssh -o IdentitiesOnly=yes -i .... If the client offers the right key and the server rejects it, inspect authorized_keys, ownership, and permissions on the server. If the key is never offered, fix your local ~/.ssh/config, agent, or key path. If the connection never reaches authentication, switch to network troubleshooting instead of changing key files.