SSH authorized_keys: Add, Verify, and Revoke Login Keys

A public key can be valid and still fail to log in if it’s installed in the wrong account, saved in the wrong place, or rejected because of unsafe permissions. The server-side authorized_keys file is where OpenSSH checks which public keys may authenticate as a particular user.

A useful distinction: your private key stays on your client machine. The server receives the matching public key—not the private one.

What authorized_keys controls

By default, OpenSSH looks for this file in the home directory of the account you’re connecting to:

~/.ssh/authorized_keys

For example, if you connect as deploy, the default file is usually in deploy’s home directory on the server. It isn’t a list of servers your laptop trusts; it’s a list of client public keys that the account will accept.

Each key should occupy one complete line. A typical entry has a key type, encoded key data, and an optional comment:

ssh-ed25519 AAAAC3... developer@laptop

The comment helps a person recognize the key later. OpenSSH doesn’t use it to decide whether the key is valid.

Add a key without replacing existing access

If ssh-copy-id is available, run it from your local machine:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

It connects to the server and installs the public key for the specified account. If you’re setting up key-based access for the first time, this walkthrough of ssh-copy-id covers the installation workflow and common options.

You can also append the public key manually over an existing SSH connection:

cat ~/.ssh/id_ed25519.pub | ssh user@remote-host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys"

The >> matters: it appends the key while preserving existing entries. A single > truncates the file, potentially removing keys used by other people or automation. Use it only when you deliberately intend to replace the file’s contents.

If you edit the file directly on the server, paste the public key on its own line. Don’t paste the private key, and don’t let the public-key line wrap into multiple lines in the file.

Check ownership and permissions

OpenSSH checks that the files and directories involved in key authentication aren’t writable by other users. With the default StrictModes setting, unsafe ownership or permissions can cause the server to ignore an otherwise valid key.

These are common settings for the SSH directory and key file:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Both should be owned by the account that’s logging in. The home directory must also have safe ownership and must not be group- or world-writable. It doesn’t have to be mode 700; changing its permissions unnecessarily can interfere with other users or services.

The important requirement is that other users can’t write to these paths—not that the public key itself must be hidden. For more detail on which SSH files need which modes, see this guide to SSH key permissions.

Changes take effect without restarting SSH

Adding, editing, or removing a line in authorized_keys does not require an SSH service restart. The server reads the file during authentication, so the change applies on the next connection attempt.

That’s different from changing server configuration. If you change an sshd_config setting, such as the configured key-file path, you may need to reload or restart SSH for the setting to take effect.

The default path can also be overridden by server configuration. If you’re unsure which file the server uses, check its effective setting on the server:

sudo sshd -T | grep -i authorizedkeysfile

Configuration rules for a particular user or connection can affect the result, so don’t assume the default path is in use on every server.

If the key is still rejected

Check these in order:

1. Right account: Is the key in the home directory of the account in your SSH command?
2. Right file: Does the server use the default ~/.ssh/authorized_keys path, or a configured alternative?
3. Complete line: Is the public key intact and on one line?
4. Safe permissions and ownership: Can only the account or an administrator write to the relevant paths?
5. Right key offered: The client may be offering a different identity than the one you installed. ssh -v user@host can show which key it tries.
6. Server policy: Public-key authentication might be disabled, or the key entry might include restrictions that don’t allow your connection.

Don’t troubleshoot by deleting the whole file or loosening permissions indiscriminately. If access is still failing, check the SSH server logs and its effective configuration before changing settings.

Revoke one key, not everyone’s access

To remove access for a particular key, delete only its line from the account’s authorized_keys file. A descriptive comment such as laptop-2026 or ci-deploy makes the right entry easier to identify later.

Removing a line takes effect on the next authentication attempt; no restart is needed. Deleting the entire file removes every key listed for that account and may break other users or automated jobs.

Keep the mental model simple: authorized_keys is a per-account list of client public keys accepted by the server. Put the public key in the correct account’s file, preserve existing lines, use safe permissions, and remember that edits apply on the next login.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.