boosten.org

Securing ssh

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:

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).

This entry was posted on Monday, September 3rd, 2007 at 2:01 pm and is filed under ssh. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.