PuTTY SSH Key Authentication Failure: Server Refused Our Key Error Analysis and Solutions

Abstract: This article provides an in-depth analysis of the 'server refused our key' error in PuTTY SSH key authentication. Through practical case studies, it demonstrates how to locate issues using debug logs and offers a comprehensive troubleshooting workflow. The content covers key technical aspects including key format validation, permission settings, and log configuration to help users completely resolve SSH public key authentication failures.

Problem Background and Symptom Description

When using PuTTY for SSH key authentication, users frequently encounter the "server refused our key" error. Typical scenarios include: generating RSA key pairs using puttygen.exe on Windows clients, correctly placing public keys in the ~/.ssh/authorized_keys file on Ubuntu servers, setting directory permissions to 700 and file permissions to 600, yet authentication still fails with the server requesting password input instead of using key-based login.

Root Cause Analysis

By enabling SSH debug logging, we identified that key format errors are the primary cause of authentication failures. Specifically, incorrect key identifiers in public key files frequently occur. During copy-paste operations, the first character often gets truncated—for example, the correct ssh-rsa identifier becomes sh-rsa—preventing the SSH daemon from properly recognizing the key type.

Solution Implementation

First, edit the SSH configuration file on the server side:

sudo nano /etc/ssh/sshd_config

Add or modify the log level configuration:

LogLevel DEBUG3

Restart the SSH service to apply configuration changes:

sudo service ssh restart

By examining /var/log/auth.log or /var/log/secure log files, detailed authentication process information can be obtained to accurately identify the specific reason for key rejection.

Permission Configuration Verification

Correct filesystem permissions are crucial for SSH key authentication. Ensure:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod g-w ~

These permission settings guarantee that only the key owner can access relevant files while preventing other users from modifying authentication configurations.

Key Format Specifications

The correct public key format should be a single line of text starting with the key type identifier, followed by Base64-encoded key data and optional comments:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231

Avoid introducing additional line breaks or special characters during copy-paste operations to ensure key content integrity.

Troubleshooting Workflow

Systematic troubleshooting should follow these steps: verify key format integrity, check file permission configurations, enable debug log analysis, confirm SSH service settings. Through step-by-step investigation, authentication issues can be quickly identified and resolved.

Best Practice Recommendations

It is recommended to verify key format correctness immediately after generation using the ssh-keygen -l -f command to check key fingerprints. Before deploying to production environments, validate the entire authentication process in testing environments. Regularly review SSH logs to promptly identify potential configuration issues.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.