Public Key Authentication Problems

Connection Problems | Operating System Problems | Agent Test

These notes cover debugging common problems encountered when setting up public key authentication for Secure Shell (SSH) using OpenSSH. Note that operating systems may prevent access even if public key authentication is setup correctly, so be sure to check the user account and access rights independent of public key authentication. Unix Debugging Tips illustrates how to investigate a Unix system.

Definition of terms used in this documentation:

Never allow root-to-root trust between systems. If required by poorly engineered legacy scripts, limit the from access of the public keys, and if possible only allow specific public keys to run specific commands. Instead, setup named accounts for users or roles, and grant as little root access as possible via sudo.

For more information, see also SSH, The Secure Shell: The Definitive Guide.

Connection Problems

If the connection does not work, try again with the -v -v -v flags specified for verbose output, which may indicate where the problem is. Common sources of problems include:

If ancient versions of OpenSSH below version 3.0 are still in use, a link will need to be created. Otherwise, the authorized_keys2 should not be used, as support for it may be removed in a future version of OpenSSH.

server$ cd ~/.ssh
server$ cat authorized_keys2 >> authorized_keys
server$ ln -sf authorized_keys authorized_keys2

Operating System Problems

Operating system configuration may block user access, though this topic is specific to the system in question. A new user on Solaris might be marked as disabled, or the user’s shell not exist in /etc/shells, or the password entry be wrong somehow (space after the shell name or other invisible problems), or on Linux PAM mis-configured or pam_tally blocking the account… and so on. Consult the vendor documentation on user accounts and access rights. Try testing both a newly created account and an existing one for differences: do both fail? Only one? Check the logs, though be aware that for “security reasons” the required debugging information may not be shown.

Agent Test

To test the agent, invoke a shell via the agent. Next, add the key into memory with the ssh-add(1) command and test a connection to the server.

client$ ssh-agent $SHELL
client$ ssh-add -l
The agent has no identities.
client$ ssh-add
Enter passphrase for /…/.ssh/id_rsa: …
Identity added: /…/.ssh/id_rsa (/…/.ssh/id_rsa)
client$ ssh-add -l
1024 48:65:6c:6c:6f:2c:20:77:6f:72:6c:64:21:20:3a:29 /…/.ssh/id_rsa (RSA)
client$ ssh

server$ exit
client$ exit