SSH Public Key Location on Server

An SSH public key goes in the file ~/.ssh/authorized_keys on the server, inside the home directory of the user account you want to log into. Each line of that file holds one public key; when you connect, the server checks whether your private key matches any entry in that file.

Why the authorized_keys File Exists

SSH key authentication works with a pair of files: a private key that stays on your local machine and a public key that you place on the server. The server never sees your private key. Instead, it uses the public key to send you a challenge that only the matching private key can answer. The authorized_keys file is simply the server’s list of accepted public keys for a given user. If your public key is not in that list, the server refuses the login, even if you have the correct private key.

The name comes from the fact that the file lists keys that are authorized to access the account. The location is always relative to the user’s home directory, so for the user alice on a typical Linux server, the full path is /home/alice/.ssh/authorized_keys. For the root user, it is /root/.ssh/authorized_keys.

How to Add Your Public Key Correctly

You can add a key manually or use a built-in tool. The manual method gives you full control and works on any server.

1. Generate a key pair locally if you do not have one: ssh-keygen -t ed25519 (or -t rsa -b 4096 for older systems).
2. Copy the contents of your public key file (usually ~/.ssh/id_ed25519.pub) to your clipboard.
3. Log into the server with your password: ssh alice@server.example.com.
4. Create the .ssh directory if it does not exist: mkdir -p ~/.ssh.
5. Append your public key to the authorized_keys file: echo "your-public-key-contents" >> ~/.ssh/authorized_keys.
6. Set the correct permissions: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys.

If you are using a standard setup, the simpler command ssh-copy-id alice@server.example.com does all of the above automatically. It appends your public key and sets the permissions for you. On Windows, you can use type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh alice@server.example.com "cat >> ~/.ssh/authorized_keys".

What Permissions Must Be Set

SSH is strict about file permissions on the server. If the .ssh directory or the authorized_keys file is writable by other users, the server ignores the file and falls back to password authentication (or fails entirely). The required permissions are:

• ~/.ssh must be owned by the user and have mode 700 (rwx——).
• ~/.ssh/authorized_keys must be owned by the user and have mode 600 (rw——-).
• The user’s home directory itself must not be writable by group or others (mode 755 or stricter).

If you see a message like “Permissions 0644 for ‘authorized_keys’ are too open,” you need to run chmod 600 ~/.ssh/authorized_keys. This is a common mistake after manually copying the file with a text editor.

Multiple Keys and Multiple Users

You can have as many public keys in authorized_keys as you want. Each line is one key. This is useful when you have several devices (laptop, desktop, phone) or when multiple administrators need access to the same account. To revoke access, simply delete the corresponding line from the file.

Each user on the server has their own authorized_keys file. If you want to log in as alice, your key must be in /home/alice/.ssh/authorized_keys. If you want to log in as bob, it must be in /home/bob/.ssh/authorized_keys. You cannot use one key file for all users; the server checks the file belonging to the user you are trying to authenticate as.

Common Problems and How to Fix Them

When key authentication fails, the server usually falls back to password authentication (if enabled) or rejects the connection. The most common causes are:

• Wrong file location: The key is in ~/.ssh/authorized_keys of the wrong user, or the file is named authorized_keys2 (which is used by some legacy configurations but not the default).
• Permissions too open: The .ssh directory or the authorized_keys file is writable by others. Fix with chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys.
• Line breaks or extra characters: The public key must be a single line. If you pasted it into a text editor that wrapped the line, the server will not recognize it. Check with cat ~/.ssh/authorized_keys and ensure each key is one long line.
• Wrong key on the client: You might be trying to use a different private key than the one matching the public key you added. Specify the key with ssh -i /path/to/private_key user@server.
• SSH server configuration: The server might have PubkeyAuthentication no in /etc/ssh/sshd_config. This is rare but possible. Check the server’s SSH configuration.

To debug, run ssh -v user@server and look for lines mentioning “Offering public key” and “Authentication succeeded.” The verbose output will tell you exactly which key is being offered and whether the server accepts it.

Security Considerations for authorized_keys

Treat your authorized_keys file as sensitive. Anyone who can write to it can grant themselves access to the account. Therefore:

• Never leave the file world-writable. Use 600 permissions.
• Do not add keys you do not recognize. Periodically review the file and remove old keys.
• Consider using ssh-agent to manage your private keys locally, but that does not change the server-side file.
• If you use a passphrase on your private key, it protects the key if your local machine is stolen, but it does not protect the server. The server trusts the public key.

You can also restrict what a key can do by adding options at the beginning of the line in authorized_keys. For example, command="/usr/bin/only-backup" ssh-ed25519 AAAA... user@host forces that key to run only a specific command. Other options include from="192.168.1.*" to limit the source IP address and no-pty to disable interactive sessions. These are advanced but useful for automation.

Frequently Asked Questions

What is the difference between authorized_keys and known_hosts?

authorized_keys is on the server and lists the public keys allowed to log in. known_hosts is on the client and stores the server’s host key to verify that you are connecting to the correct server. They serve opposite purposes: one authenticates you to the server, the other authenticates the server to you.

Can I use the same public key on multiple servers?

Yes. A public key is not tied to a specific server. You can add the same public key to authorized_keys on any number of servers. This is common for users who manage several machines. If you lose the private key, you must remove the public key from every server.

What if I accidentally deleted my private key?

If you lose the private key, the corresponding public key on the server is useless. You cannot recover the private key from the public key. You must generate a new key pair and add the new public key to the server (using password authentication or another admin’s key). Remove the old public key from authorized_keys to prevent confusion.

Why does the server say “Permission denied (publickey)” even though I added the key?

This usually means the server did not find a matching public key in authorized_keys. Check the file path, permissions, and that the public key you added is exactly the one matching your private key. Also verify that you are connecting as the correct user. Use ssh -v to see which key is being offered and whether the server accepts it.

Is it safe to put my public key in authorized_keys?

Yes. Public keys are meant to be shared. The security lies in the private key, which never leaves your local machine. Even if someone sees your public key, they cannot derive the private key from it. However, you should still protect the authorized_keys file from unauthorized writes, because an attacker who can modify it can add their own key.

Related

• Budget Headphones with Mic for Calls, Music & Gaming
• IT Blocks File Sync: What It Means & How to Fix It
• Apple Copy Paste Photos? How It Works