Adding a public SSH key to authorized_keys is like giving someone a specific, pre-approved key to your house, bypassing the need for them to have a physical key (your private key) or know your house number (your IP address).
Let’s see it in action. Imagine you have a server, my.server.com, and you want to give your laptop, my.laptop, access without a password.
First, on your laptop, you generate a key pair if you don’t have one:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_server
This creates ~/.ssh/id_rsa_server (your private key, keep it secret!) and ~/.ssh/id_rsa_server.pub (your public key, this is what you share).
Now, on my.server.com, you need to add the content of id_rsa_server.pub to the ~/.ssh/authorized_keys file for the user you want to log in as (let’s say deploy).
You can do this manually by SSHing in with a password and running:
# On my.server.com, as the 'deploy' user
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC+..." >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
The ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC+... part is the exact content of your id_rsa_server.pub file. The >> appends it. chmod sets the correct permissions, which are critical.
Alternatively, and more efficiently, you can use ssh-copy-id from your laptop:
# On my.laptop
ssh-copy-id -i ~/.ssh/id_rsa_server.pub deploy@my.server.com
This command handles creating the ~/.ssh directory, setting permissions, and appending the key to authorized_keys on the remote server, all in one go. You’ll be prompted for the deploy user’s password on my.server.com one last time.
After this, on your laptop, you can SSH to the server without a password:
# On my.laptop
ssh deploy@my.server.com
The system works by the SSH client (your laptop) presenting the public key to the SSH server (my.server.com) during the authentication handshake. The server checks if this public key is listed in the authorized_keys file for the target user. If it is, the server then uses the corresponding private key (which only your laptop has) to perform a cryptographic challenge-response, proving that your laptop possesses the matching private key. If successful, access is granted.
The authorized_keys file is essentially a whitelist of public keys that are allowed to authenticate as the user whose .ssh directory it resides in. Each line in authorized_keys represents a single public key. These keys can be generated with different algorithms (RSA, ECDSA, Ed25519) and different key lengths. You can also add options at the beginning of a line to restrict what the key can do, like limiting it to a specific command or disabling port forwarding. For instance, command="/usr/local/bin/backup.sh",no-port-forwarding ssh-rsa AAAAB3NzaC1yc2E... would allow the key to only run backup.sh and nothing else.
The most surprising thing about authorized_keys is how it handles different key types and options. It’s not just a list of keys; it’s a powerful, albeit sometimes obscure, access control mechanism. For example, a single public key can be added multiple times to the authorized_keys file if you want to apply different sets of authorized_keys options to it without modifying the key itself. This is useful if you want to grant one user access with full privileges using their key, but grant another user (or the same user in a different context) access using the same key, but restricted to a single command. You’d simply have two lines in authorized_keys that both contain the same public key string, but one line has command="..." prepended, and the other does not.
The critical permissions for the .ssh directory and the authorized_keys file are 700 for .ssh and 600 for authorized_keys. If these permissions are too open (e.g., world-writable or group-writable), SSH will refuse to use the authorized_keys file for security reasons, and you’ll be prompted for a password. The SSH server checks that only the owner can read and write to these files.
When you encounter issues with SSH keys not working, the first thing to check is always the permissions on .ssh and authorized_keys on the server side. Then, verify the public key content is an exact, unbroken string in the authorized_keys file. Finally, ensure the correct private key is being used on the client side.
The next hurdle after mastering authorized_keys is often managing multiple SSH keys for different servers or services and understanding SSH agent forwarding.