authorized_keys: 600 permissions, options and 5 common errors

authorized_keys is the OpenSSH file that lists the public keys allowed to log in to an account. For sshd to accept it, ~/.ssh must be 700 and authorized_keys 600, with no write access for group or others. Each line can carry options such as from=, command= and no-pty that limit where a key connects from and what it may run.

authorized_keys permissions: 700 on ~/.ssh and 600 on the file

sshd ignores authorized_keys when ~/.ssh or the file itself is more open than expected: 700 for ~/.ssh and 600 for authorized_keys and private keys. The check comes from the StrictModes directive in sshd_config, enabled by default, which also verifies that your home directory is not writable by group or others.

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

When something is wrong, the server log says so plainly: look for lines such as Authentication refused: bad ownership or modes. On Debian and Ubuntu you read them with journalctl -u ssh; on other distributions the unit is called sshd. Turning StrictModes off to get unstuck is a bad trade: it hides the problem and lets another user with write access to your home slip in their own key.

authorized_keys options: from=, command= and no-pty by example

Every authorized_keys line follows the format [options] keytype key comment, with options separated by commas, no spaces, placed before the key type. The full list lives in the AUTHORIZED_KEYS section of the official sshd manual page.

from="203.0.113.0/24,198.51.100.7",no-pty,no-port-forwarding ssh-ed25519 AAAAC3Nza... admin@phone
command="/usr/local/bin/backup.sh",restrict ssh-ed25519 AAAAC3Nza... backup@nas
restrict,pty ssh-ed25519 AAAAC3Nza... support@laptop

• from="patterns": the key is accepted only when the client connects from those addresses or hostnames. Wildcards, CIDR notation and negation with ! are allowed.
• command="…": forces that command regardless of what the client asks for. The requested command is kept in SSH_ORIGINAL_COMMAND so a script can validate it.
• no-pty: no terminal is allocated. Useful for rsync, backup or deploy keys.
• no-port-forwarding, no-agent-forwarding, no-X11-forwarding: switch off each kind of forwarding individually.
• restrict: disables all of the above at once; you then re-enable what you need, for example with pty.

Pairing command= with restrict is the standard pattern for backup keys: even if the key leaks, it can only run that one script. from= adds a second barrier, but a phone on mobile data rarely has a fixed source IP. In that case it pays to come in through a private mesh network such as Prialo or Tailscale and pin from= to that network's addresses.

5 common authorized_keys errors and how to spot them

The first diagnostic step is always ssh -v user@server: it shows which keys the client offers and where the server turns them down.

1. Wrong permissions or owner. Copying the file as root leaves it owned by root, and sshd skips it. The chmod and chown block above fixes it.
2. Key split across several lines. Pasting from an editor that wraps text breaks the key. Each key must sit on exactly one line.
3. Options with spaces or unclosed quotes. A space after a comma or a missing closing quote invalidates the whole line, and sshd drops it without telling the client.
4. RSA key rejected by algorithm. Since OpenSSH 8.8, the ssh-rsa signature using SHA-1 is disabled by default, so older clients stop getting in. The fix is moving to Ed25519, supported since OpenSSH 6.5.
5. command= breaking Mosh, SFTP or scp. Mosh starts mosh-server over an initial SSH connection and SFTP requests its subsystem; a fixed command= replaces both. Since OpenSSH 9.0, scp uses SFTP by default, so it fails too. Keep separate keys for interactive sessions and automation.

Managing authorized_keys on iOS and Android versus a desktop

The private key can be generated on the phone itself and stored in the system's secure storage, so the server only needs the public line appended to authorized_keys.

In the termi1 SSH and Mosh terminal, the private key never leaves the device or reaches Sinergia's servers, and termi1 Companion (macOS 14 or later) installs the public key on a Mac with a six-digit code. Ask the AI to "fix my ssh permissions" and it types chmod 600 ~/.ssh/authorized_keys into the prompt without pressing Enter; on connections tagged as production, Production Guard holds back anything that changes state. The terminal is free, works without an account, and is available on the App Store and Google Play.

Frequently asked questions

What permissions should authorized_keys have?

authorized_keys should be 600, readable and writable only by its owner, and the ~/.ssh directory should be 700. With StrictModes enabled, which is the default, sshd ignores the file if group or others can write to it, to ~/.ssh or to the home directory.

What does command= do in authorized_keys?

command= in authorized_keys forces a specific command every time someone authenticates with that key, whatever the client requests. The requested command is stored in the SSH_ORIGINAL_COMMAND variable. It is typically used for backup and deploy keys, combined with restrict or no-pty.

Why does SSH still ask for a password after adding my key?

SSH falls back to a password when sshd accepts no key from authorized_keys. The usual causes are permissions that are too open, the wrong owner, a key split across lines or a mistyped option. Running ssh -v on the client and reading the sshd log on the server pinpoints which one.

Does Mosh work with a restricted key in authorized_keys?

Mosh works with restricted keys as long as they carry no command=, because it launches mosh-server through an initial SSH connection. After that the session runs over UDP, by default on ports 60000-61000, which must be open in the server's firewall.