There’s little more frustrating than trying to log into a remote server via SSH only to be met with the error message: Permission denied (publickey) or a similar variant. SSH login issues are common but often avoidable if you understand how the Secure Shell (SSH) protocol works and the usual culprits behind such problems. In this article, we’ll explore the most common reasons for SSH permission denials and how you can fix them with confidence.
1. Key-Based Authentication Issues
One of the most frequent causes of SSH errors is a missing or misconfigured SSH key. When using key-based authentication, your SSH client uses a private key to authenticate with the server’s stored public key. If this process fails for any reason, access will be denied.
- Missing Private Key: Ensure that your private key exists and is located at the expected path (usually ~/.ssh/id_rsa or ~/.ssh/id_ed25519).
- Incorrect Permissions: SSH refuses to use private keys that have overly permissive permissions. Adjust it by running:
chmod 600 ~/.ssh/id_rsa - Mismatched Keys: If your public key wasn’t added to the server’s ~/.ssh/authorized_keys file, access won’t be granted.
2. Wrong Username or Hostname
Always verify that you are connecting with the correct username and hostname. SSH does not always use your local machine’s username when connecting to a server. If the username is incorrect or the hostname is mistyped, the server won’t recognize your login request.
- Use the
-lflag or directly specify the username when connecting:
ssh user@hostname - Check your ~/.ssh/config file for any hardcoded incorrect values.
3. Incorrect or Missing authorized_keys File
The remote server verifies your public key against those stored in the ~/.ssh/authorized_keys file under the target user’s account. If your public key is not correctly placed there, or if the file doesn’t have the right permissions, SSH will deny access.
- Ensure the authorized_keys file contains your correct public key.
- Set proper file permissions:
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh
4. Server Configuration Restrictions
The SSH daemon (sshd) could be configured to allow only certain users or key types. You should examine the server’s /etc/ssh/sshd_config file for restrictive entries such as:
AllowUsersorDenyUsersPasswordAuthentication noPubkeyAuthentication no
Any of these could prevent a connection. After adjusting the sshd_config file, don’t forget to restart the SSH service:
sudo systemctl restart sshd
5. Firewall or Port Blocking
An often-overlooked issue is the network itself. Firewalls or network policies may block port 22, the default SSH port. If you’ve configured SSH to listen on an alternate port, ensure you’re specifying it during connection with the -p flag:
ssh -p 2222 user@hostnameAlso, check with your system administrator or hosting provider to make sure SSH access is enabled for your account and IP address.
Avoiding Future Problems
Once you identify and resolve your SSH login issue, follow best practices to avoid similar problems in the future:
- Keep your private key secure and backed up.
- Use an SSH agent like
ssh-agentto manage keys more securely. - Always verify server fingerprints when connecting to a new host.
- Periodically audit your authorized_keys and sshd_config files for deprecated keys or restrictive parameters.
Conclusion
SSH permission denied errors are usually not permanent or mysterious. They can often be traced to a handful of common problems—misconfigured key permissions, wrong usernames, or server-side restrictions. By systematically verifying each point outlined above, you can regain access quickly and securely. SSH is a powerful tool, and with a bit of knowledge, you can ensure it’s always available when you need it.