~/.ssh/authorized_keys file on the remote host. This bypasses automatic configuration failures and ensures your SSH client presents the correct credentials for authentication.
Understanding the Permission Denied Error
The error Permission denied (publickey) is one of the most common hurdles when setting up Secure Shell connections between a personal computer and a Linux-based device like a Raspberry Pi running Ubuntu. Unlike password-based authentication, which asks for a secret phrase, public-key authentication relies on a cryptographic pair: a private key that stays on your local machine and a public key that resides on the server. When the SSH daemon rejects your connection with this specific message, it means the server either did not receive your key, could not read it, or determined that the key did not match any entry in its allowed list.
This issue frequently occurs during initial setup phases or when migrating configurations between devices. The SSH service on the Raspberry Pi is likely running correctly and listening on port 22, but the trust relationship has not been established. While many modern tools attempt to automate this via ssh-copy-id, manual intervention is often required when network permissions block automated scripts or when dealing with restricted environments. Understanding the underlying mechanism helps you diagnose why the automatic methods failed and how to fix them directly.
Locating Your Local Public Key
Before modifying any files on the remote system, you must identify the correct public key from your local PC. OpenSSH generates these keys in the .ssh directory within your user's home folder. On Linux and macOS, you can view the contents of your default public key using the cat command. For example, running cat ~/.ssh/id_rsa.pub will display a long string starting with ssh-rsa or ssh-ed25519.
If you are using Windows, the location depends on your version of OpenSSH. Modern versions of Windows 10 and 11 include an OpenSSH client where keys are stored in C:\Users\. You can open this file in any text editor to copy the entire line. It is critical that you copy the key exactly as it appears, including the trailing comment which usually identifies the user and hostname. Do not add extra spaces or newlines at the beginning or end of the key string, as this will cause the authentication to fail silently.
Accessing the Raspberry Pi via Terminal
To manually edit the authorized keys file, you need terminal access to the Raspberry Pi. If you currently have password access enabled, you can connect using the standard SSH command: ssh username@raspberry_pi_ip_address. Replace username with your actual login name and the IP address with the local address of your Pi. Once logged in, you are operating as that user, which is essential because the authorized_keys file is user-specific.
If you do not have password access and cannot use keys due to the error, you may need to access the Raspberry Pi locally through a monitor and keyboard, or use a serial console if available. Alternatively, if you have sudo privileges via another method, you can escalate your session. However, the safest approach is to ensure you are editing the file as the specific user who will be logging in, rather than root, unless you are explicitly configuring root login which is generally discouraged for security reasons.
Appending the Key to Authorized Keys
The core solution involves appending your local public key to the ~/.ssh/authorized_keys file on the Raspberry Pi. First, verify that the .ssh directory exists in your home directory by running ls -la ~/.ssh. If it does not exist, create it using mkdir -p ~/.ssh. Next, navigate into that directory. To append the key safely without overwriting existing keys, use the following command structure:
echo "your_public_key_here" >> ~/.ssh/authorized_keysReplace your_public_key_here with the actual content you copied from your local machine. The >> operator appends the text to the end of the file. If the file does not exist, this command will create it automatically. After executing this command, it is vital to set the correct permissions. The .ssh directory should have permissions 700 (read, write, execute for owner only), and the authorized_keys file should have permissions 600 (read and write for owner only). You can enforce this with:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysIncorrect permissions are a frequent cause of continued "Permission denied" errors. OpenSSH is strict about file ownership and permissions; if other users can read your private key or authorized keys file, the SSH daemon will ignore the configuration entirely to prevent security breaches.
Verifying the Connection
Once the key is added and permissions are corrected, test the connection from your local PC. Run the SSH command again. If successful, you should gain immediate access without being prompted for a password. If the error persists, check the SSH logs on the Raspberry Pi for detailed rejection reasons. You can view these logs by running sudo journalctl -u ssh -f in a separate terminal window while attempting to connect. Look for lines indicating "Authentication refused: bad ownership or modes for file." This confirms that the permission settings are still incorrect.
For more complex networking issues, such as key exchange failures, you might encounter different errors. If you see a kex_exchange_identification error instead, the problem lies in the network handshake rather than authentication, requiring a different troubleshooting path as outlined in our guide on Troubleshooting kex_exchange_identification Error in Linux SSH Connection. Similarly, if you are routing traffic through proxies, ensure your SSH configuration aligns with those settings, as discussed in Setting Up SOCKS5 Proxy with OpenSSH for Traffic Proxying.
Frequently Asked Questions
Why does SSH ignore my authorized_keys file?
SSH ignores the file primarily due to incorrect permissions or ownership. The .ssh directory must be owned by the user and have mode 700, while the authorized_keys file must be mode 600. Any group or world-readable permissions will cause the daemon to reject the file for security reasons.
Can I use this method for root login?
Yes, but it is strongly discouraged. Root login via SSH is often disabled by default in modern Ubuntu distributions for security. If you must enable it, you would append the key to /root/.ssh/authorized_keys, but you must also modify /etc/ssh/sshd_config to set PermitRootLogin yes.
What if I get a "Host key verification failed" error?
This error indicates that the host key fingerprint has changed or is unknown, not an authentication failure. You should remove the old entry from your local ~/.ssh/known_hosts file using ssh-keygen -R [ip_address] and reconnect to accept the new key.
Does this work for multiple users on the same Pi?
Yes, each user must have their own ~/.ssh/authorized_keys file. You must log in as the specific user or use sudo to edit their respective directories. A key added to one user's file will not authenticate another user.
How do I generate a new key pair if I lost mine?
You can generate a new Ed25519 key pair on your local machine using ssh-keygen -t ed25519 -C "[email protected]". This creates a stronger key than RSA and is recommended for new setups. Follow the prompts to save the file and optionally set a passphrase.