|
While most 'securing ssh' articles are about moving sshd to a non-standard port (port != 22), not allowing root to login and only allowing public-key authentication, all but the first good advises, I like to write something about the authorized_keys file in ~/.ssh/.
Apart from holding the public keys for a connection, each key can have several options.
The basic layout of ~/.ssh/authorized_keys looks like this:
ssh-rsa [a very long key string] user@host
I've seen different things in stead of ssh-rsa , like ssh-dsa, or even some numbers.
The options I was talking about precede this entry, like this:
option[,option]... ssh-rsa [a very long key string] user@host
If using more than one options at once, separate them with commas.
I like to use the following options:
Option
|
meaning
|
| no-port-forwarding |
regardless what the ssh client wants, no port forwarding for this user |
| no-X11-forwarding |
no X11 forwarding allowed for this user |
| no-agent-forwarding |
no agent forwarding |
| no-pty |
no shell for this user |
| from="ipaddress1,ipaddress2,ipaddress3" |
allow only connections from these IP addresses. |
The from= option can be used for IP addresses, host names, but also for IP ranges and domains. IP ranges and domains are defined with wildcards, like "192.168.4.*". I used this for allowing the helpdesk te reboot a machine, but I did not want them to do that while not in the office.
The no-pty option I used for an account whose purpose was to update the cvs repository on an hourly basis.
One other handy option is to specify a command a user can run ( command="/some/command/here" ) .
Since this file is in the users home directory, he (or she) could overwrite or edit the authorized_keys file. To prevent this I flagged the file 'system immutable': it cannot be changed or deleted by the user.
# chflags schg authorized_keys
(this works on OpenBSD/FreeBSD, don't know about other Unixes or Linux).
|
