It may be the case that while you’re happy to allow a user or process to have
public key authentication access to your server via the
~/.ssh/authorized_keys file, you don’t necessarily want to give them a full
shell, or you may want to restrict them from doing things like SSH port
forwarding or X11 forwarding.
One method that’s supposed to prevent users from accessing a shell is by
defining their shell in
/bin/false, which does indeed
prevent them from logging in with the usual
ssh command syntax. This
isn’t a good approach because it still allows port forwarding and other
If you want to restrict the use of logins with a public key, you can prepend
option pairs to its line in the
authorized_keys file. Some of the most useful
options here include:
from="*.example.com"to the key line would only allow public-key authenticated login if the connection was coming from some host with a reverse DNS of
example.com. You can also put IP addresses in here. This is particularly useful for setting up automated processes through keys with null passphrases.
command="<command>"— Means that once authenticated, the command specified is run, and the connection is closed. Again, this is useful in automated setups for running only a certain script on successful authentication, and nothing else.
no-agent-forwarding— Prevents the key user from forwarding authentication requests to an SSH agent on their client, using the
no-port-forwarding— Prevents the key user from forwarding ports using
no-X11-forwarding— Prevents the key user from forwarding X11 processes.
no-pty— Prevents the key user from being allocated a
ttydevice at all.
So, for example, a public key that is only used to run a script called
runscript on the server by the client
command="runscript",client="client.example",no-pty,no-agent-forwarding,no-port-forwarding ssh-rsa AAAAB2....19Q firstname.lastname@example.org
A public key for a user whom you were happy to allow to log in from anywhere with a full shell, but did not want to allow agent, port, or X11 forwarding:
no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAD3....19Q email@example.com
Use of these options goes a long way to making your public key authentication
setup harder to exploit, and is very consistent with the principle of least
privilege. To see a complete list of the options available, check out the
man page for