Putty: Getting Server refused our key Error

Troubleshooting 'Server refused our key' Error in PuTTY

Learn how to diagnose and resolve the common 'Server refused our key' error when connecting to SSH servers using PuTTY, ensuring successful authentication.

The 'Server refused our key' error is a common frustration for users attempting to connect to an SSH server using PuTTY. This error indicates that the SSH server did not accept the public key provided by your PuTTY client for authentication. It's a security mechanism, but it can be challenging to troubleshoot without understanding the underlying causes. This article will guide you through the typical reasons for this error and provide step-by-step solutions to get your SSH connection working.

Understanding SSH Key-Based Authentication

SSH (Secure Shell) key-based authentication offers a more secure alternative to password-based authentication. It involves a pair of cryptographic keys: a private key and a public key. The private key is kept secret on your local machine (the PuTTY client), while the public key is stored on the remote server you wish to access. When you attempt to connect, the server challenges your client, which then uses its private key to prove its identity without ever sending the private key over the network.

sequenceDiagram
    participant Client as PuTTY Client
    participant Server as SSH Server

    Client->>Server: Connection Request
    Server->>Client: Send Public Key Challenge
    Client->>Client: Sign Challenge with Private Key
    Client->>Server: Send Signed Challenge
    Server->>Server: Verify Signature with Stored Public Key
    alt Signature Valid
        Server->>Client: Authentication Successful
        Client->>Server: Establish Secure Session
    else Signature Invalid or Key Not Found
        Server->>Client: "Server refused our key" Error
    end

SSH Key-Based Authentication Flow

Common Causes and Solutions

Several factors can lead to the 'Server refused our key' error. Identifying the root cause is crucial for a quick resolution. Here are the most common scenarios and their corresponding fixes.

1. Incorrect Public Key on Server

The most frequent cause is that the public key on the server either doesn't exist, is incorrect, or is improperly formatted in the ~/.ssh/authorized_keys file for the user you're trying to log in as. The public key must be exactly as generated by PuTTYgen and placed on a single line.

1. Verify Public Key on Server

Log into your server using an alternative method (e.g., password authentication, if available, or through your hosting provider's console). Navigate to the home directory of the user you're trying to connect as (e.g., /home/youruser/). Check the contents of the ~/.ssh/authorized_keys file. Ensure your public key is present and correctly formatted on a single line. If not, add or correct it.

2. Correct Permissions

SSH is very strict about file permissions. The ~/.ssh directory should have permissions 700 (rwx------), and the ~/.ssh/authorized_keys file should have 600 (rw-------). The user's home directory should not be world-writable (e.g., 755 or 700).

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~/

Correcting SSH directory and file permissions on the server.

2. Incorrect Private Key in PuTTY

Your PuTTY client might be configured to use the wrong private key, or the private key file (.ppk) might be corrupted or not loaded correctly by PuTTY.

1. Load Correct Private Key

In PuTTY, go to 'Connection' -> 'SSH' -> 'Auth'. Click 'Browse...' and select the correct .ppk file that corresponds to the public key on the server. Ensure you're not using an old or incorrect key.

2. Verify Private Key Integrity

If you suspect your private key is corrupted, try regenerating the key pair using PuTTYgen and updating the public key on the server. Make sure to save the new private key securely.

3. PuTTY Agent (Pageant) Issues

If you're using Pageant (PuTTY's authentication agent) to manage your keys, the private key might not be loaded into Pageant, or Pageant might not be running.

1. Check Pageant Status

Ensure Pageant is running in your system tray. Double-click its icon to open the 'Pageant Key List' window. Verify that your private key is loaded. If not, click 'Add Key' and select your .ppk file.

2. Enter Passphrase

If your private key is protected by a passphrase, Pageant will prompt you for it when you add the key. Ensure you enter the correct passphrase.

4. Server-Side SSH Configuration

The SSH server's configuration (sshd_config) might be preventing key-based authentication or has specific restrictions.

1. Review sshd_config

On the server, open the SSH daemon configuration file, typically located at /etc/ssh/sshd_config. Look for directives like PubkeyAuthentication, AuthorizedKeysFile, and PasswordAuthentication.

2. Ensure Key Authentication is Enabled

Make sure PubkeyAuthentication yes is uncommented and set to yes. Also, ensure AuthorizedKeysFile points to the correct location (usually .ssh/authorized_keys). If PasswordAuthentication no is set, you won't be able to fall back to passwords, making key issues critical.

PubkeyAuthentication yes
AuthorizedKeysFile	.ssh/authorized_keys
PasswordAuthentication no # Optional, but common for security

Relevant settings in /etc/ssh/sshd_config.

sudo systemctl restart sshd # For systemd-based systems (e.g., Ubuntu, CentOS 7+)
sudo service ssh restart # For older init systems (e.g., Debian, CentOS 6)

Commands to restart the SSH service.

5. User-Specific Restrictions

Sometimes, specific users might have restrictions that prevent key-based authentication, or their shell environment might be misconfigured.

1. Check User's Shell and Home Directory

Ensure the user's home directory exists and is correctly set in /etc/passwd. Also, verify that the user's login shell is a valid shell (e.g., /bin/bash, /bin/sh) and not /sbin/nologin or similar.

2. SELinux/AppArmor Contexts

On systems with SELinux or AppArmor enabled, incorrect security contexts might prevent SSH from reading the authorized_keys file. This is less common but can be a factor. Check system logs for SELinux/AppArmor denials.