blog.6admin.io
guest@6admin.io:~$
security, ssh

SSH: restricting a connection via private/public keys

What is more natural when running automated tasks between multiple servers than using an SSH key pair without a passphrase?

Yes, but how do you confine this unprotected key to executing one specific task?

You just need to prefix the public key you want to limit in the file:

.ssh/authorized_keys

With the options detailed in the sshd manual, section AUTHORIZED_KEYS FILE FORMAT:

command="/usr/bin/rsync --server --daemon .",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA...

Each option blocks an escape path:

  • command="..." : the key can ONLY execute this command (rsync), no shell
  • no-port-forwarding : no SSH tunnel via this key
  • no-X11-forwarding : no remote X11 display
  • no-agent-forwarding : no relayed SSH agent (the “I steal the user’s agent” attack)
  • no-pty : no interactive terminal (no shell even if command is empty)

The combination of these five options transforms a “no passphrase = open door” key into a “no passphrase = single use, encrypted, limited” key. This is the pattern for automated backups between servers: the backup machine has a key that can only do one thing.

[edit: 2026] This mechanism is still the standard pattern for automated SSH tasks. The modern version adds restrict (which replaces the five no-* options) and principals= (for certificates). The companion article SSH in 2021 documents the rest: certificates, FIDO2 and the ProxyJump that killed administrative tunnels.

[edit: 2026] The Ansible implementation of all this: the ssh role .