What to do if SSH key authentication fails? From configuration errors to log analysis to resolve remote login issues. Even after generating and uploading the public key, the connection still shows "Permission denied (publickey)"—this error is almost a "must-learn" for users new to Hong Kong servers. This article will systematically break down the root causes of SSH key authentication failures, from configuration troubleshooting to log analysis, to help you quickly restore access.

SSH key authentication uses an asymmetric encryption mechanism. The client holds the private key, and the server stores the public key. The basic authentication process is as follows:

The user generates a key pair (public key + private key) on the client. The private key is stored on the client, and the public key is uploaded to the server.

The client sends an authentication request to the server, providing the client's private key for signature verification.

The server uses the stored public key to verify if the signature matches.

If verification is successful, a connection is established; otherwise, `Permission denied (publickey)` is returned.

Understanding this process provides a clear path for troubleshooting—the problem lies either on the client (private key not loaded correctly), on the server (public key not configured correctly), or in the communication path (configuration or permission blocking).

Preparation before troubleshooting: First, confirm basic connectivity

Before delving into key configuration, it's recommended to first confirm basic network connectivity and SSH service status to avoid wasting troubleshooting time at the network layer.

Step 1: Test host and port connectivity

Test host reachability

ping server IP

Test SSH port open (default 22)

telnet server IP 22

or

nc -zv server IP 22

If `telnet` displays `Connection refused`, it usually indicates the SSH service is not running, the port is not listening, or the firewall/security group has not allowed it. If it displays `Connection timed out`, it's highly likely that the firewall or security group rules have dropped the connection. It's recommended to log in to your cloud service provider's console to check if the inbound rules have allowed the source IP and SSH port.

Troubleshoot SSH key authentication "minefields" one by one

The following six dimensions cover more than 90% of key authentication failure scenarios. It's recommended to check them one by one in order:

File permissions: The most easily overlooked hidden killer

OpenSSH has extremely strict checks on permissions for key-related files and directories. Overly lenient permissions will directly reject authentication.

Server-side checks: The user's home directory cannot be written to by other users (Note: home directory permissions cannot be 775 or 777).

chmod 755 /home/username

The `.ssh` directory must have permissions of 700.

chmod 700 ~/.ssh

The `authorized_keys` file must have permissions of 600.

chmod 600 ~/.ssh/authorized_keys

Client-side checks (Linux/Mac example):

The private key file permissions must be 600.

chmod 600 ~/.ssh/id_rsa

The public key file permissions can be 644.

chmod 644 ~/.ssh/id_rsa.pub

The permissions of the user's home directory itself are also checked. In one case, a user checked all files but still failed, ultimately finding that the `/root` directory permissions were 755. Execute `ls -ld ~` to check the home directory permissions; if they are not 755, correct them immediately.

Check the server-side public key configuration. Manual operation can easily introduce invisible characters or line break errors, causing the authorized_keys format to be abnormal.

Correct methods for adding a public key (recommended):

Method 1: Automatic deployment using ssh-copy-id (recommended)

ssh-copy-id -i ~/.ssh/id_rsa.pub user@serverIP

Method 2: Manual appending (ensure the public key is a complete line, starting with ssh-rsa/ssh-ed25519)

echo "ssh-rsa AAAAB3NzaC1yc2E... (complete public key content)">> ~/.ssh/authorized_keys`

If manual appending still fails, it is recommended to compare the public key fingerprint in the server's authorized_keys with the client's local public key:

View public key fingerprint on the client:

ssh-keygen -lf ~/.ssh/id_rsa.pub

View public key fingerprint stored in authorized_keys on the server:

ssh-keygen -lf ~/.ssh/authorized_key

If the fingerprints do not match, it means the public key content is different, and it is recommended to copy it again.

SSH Server Configuration Check

Log in to the server and check the key configuration items in `/etc/ssh/sshd_config` for correctness:

Ensure public key authentication is enabled

PubkeyAuthentication yes

Confirm the public key file path is correct (default)

AuthorizedKeysFile .ssh/authorized_keys

If logging in as root, check the following configuration (common scenario for Hong Kong servers):

`PermitRootLogin prohibit-password` Recommended: Only allow key-based login for root

After modifying the configuration, be sure to perform syntax validation before restarting the service:

Validate the `sshd_config` syntax

sudo sshd -t

If the syntax is correct, restart the service

sudo systemctl restart sshd

Client Key Loading Check

Explicitly specify the private key file using the `-i` parameter and view the detailed connection process using `-v` (or `-vvv`):

ssh -vvv -i ~/.ssh/id_rsa user@serverIP

Pay close attention to the following in the debug output:

- `Offering public key:` → Confirms that the client did indeed send a public key request

- `Server accepts key:` → Confirms the server has accepted the key.

If the above message does not appear, the private key file may not have been loaded correctly, or the client may be using an incorrect key file.

Check the ssh-agent status (especially crucial when using multiple keys):

View the keys loaded in the agent: `ssh-add -l`

If the private key is not listed, add it manually: `ssh-add ~/.ssh/id_rsa`

3.5 Key Algorithm Compatibility Check

Newer versions of OpenSSH disable the `ssh-rsa` algorithm by default. If an RSA-SHA1 key is generated, the connection will fail.

Solution: It is recommended to regenerate the key using the more secure `ed25519` algorithm: `ssh-keygen -t ed25519 -C "your_email@example.com"`

If RSA keys must be used for historical reasons, compatibility can be enabled in `/etc/ssh/sshd_config` on the server: `PubkeyAcceptedKeyTypes +ssh-rsa`

Enable DEBUG logging for precise fault location.

When the above routine troubleshooting is ineffective, enabling detailed SSH server logging is the most efficient method for troubleshooting.

Configure server-side DEBUG logging: Edit `sshd_config` and add the following configuration:

sudo vim /etc/ssh/sshd_config
LogLevel AUTH DEBUG2 (DEBUG2 is recommended, as it includes key fingerprints and authentication decision details)
SyslogFacility AUTH

After modification, restart and monitor the logs:

sudo systemctl restart sshd

Ubuntu/Debian systems:

sudo tail -f /var/log/auth.log | grep sshd

CentOS/RHEL systems:

sudo tail -f /var/log/secure | grep sshd

Hong Kong servers are usually provided by cloud service providers. The primary reason for connection failures is that the security group inbound rules do not allow the source IP address. Please ensure the following configurations are confirmed in the cloud console: SSH port (default 22) is open in the inbound rules. The source IP range includes your local IP (setting it to `0.0.0.0/0` is not recommended; allow access only as needed). SSH key authentication involves timestamp verification. Significant time differences between the server and client may cause authentication failure. For Hong Kong servers, ensure the server timezone is correct: Check the current time: `date` Enable and start NTP synchronization: `sudo timedatectl set-ntp yes` `sudo systemctl restart systemd-timesyncd` 5.3 Data Compliance When deploying a Hong Kong server, pay attention to data security compliance requirements and ensure encrypted communication between the server and client. Regular key rotation is recommended.

For users who have purchased a Hong Kong server but cannot log in due to SSH key authentication failure, if you cannot resolve the issue yourself, please contact Jtti for technical support. We have years of experience in Hong Kong server operation and maintenance and can quickly assist in troubleshooting access link problems and optimizing connection stability to ensure your business remains online.