Understanding OpenSSH

The following article will go through some of these features, controlled by the authorized_keys file or whatever file the "AuthorizedKeysFile" keyword in sshd_config points to. The examples used in this article have been tested on OpenSSH 3.9 and OpenBSD 3.6. However, they should work just about the same with the portable version of OpenSSH available on other Unix-like and Linux operating systems.

The authorized_keys file

ttypa:foo@eek> cat /home/foo/.ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAAEBAObMKlu5Clf6wvUzCglaXB\
wcrfSoVGUZAMK54xDx95T7reXsmq18wZbmCPWB5VXWP3d9v2FG\
BNwMotSrrbjwWq+tDBExiQI/osgIKnMcwRsU04ZW1tLNPD57vg\
oI8EbDU95m7tUbyCSHA9LXZhNX4kEMDbDaZiiTwj9oTE0+UMl/\
H9lj8Rvamrt3uKRMOGsULN3UhV3Bj9o6/Utl25IQGH9128+QBg\
+1sQ1+4HUyeF8g8BkfVhl08l9DWDpKN7vKJxae+AaSLqPRCwM8\
JUYArfvu1thbuRpmVV0AhGdHxmOLY8GbdSAQ3A7L+d0Dm+ZVug\
9bVkHwZY7W4e9Immdw9fUAAAAVALNB86qZCuZ5ZiRXprjYsDIh\
xRhfAAABAE8E+BNm/ocwtXBbv36omT3Ae79wSAq4VctZQ3wLQV\
+fWdsD0z6S2qVbKMStSfcf8/qAPa43WCgT3VnzbX7iNM5gMyrw\
py/GY71uZS/4DHDb7xXhsislyqCMWqM8tF5E0+oGCtd9WoISl0\
NBxeJ8gzWNKipgm/aGiaHA6dkQ+qPBOoVXtPPJJVpetuHwmxWb\
SqdLCxIqi2ecPTli1X7iyseDVoEw+xk7bBrSCDVmvSR4c1oVpx\
4SXxgmFbtrTHP04VCkGjGAjJ65jTV84HJBnFw3HJD3KGZd8keu\
NCI1OPYe5j0DQf50XpEPNVHSU6Jexxpea0T1Ne/MflUKsLgviN\
AAAAEBALUTGCm0B4rUWeCRt5qdi3/zxww14LigJxSDonLtBkpY\
+fFeYDePO9zchJ0N8J9be+7yrImwGbclwvAPcfOUTiVJDjyx9Q\
kQt28FprVMktUHMW3Xsgii9adMmPH3OuahPUgvsvYak50qCoyy\
QzqF+z7qPHmuUIA1BRIMpmHgYpBCBZN3YMnkgGNfve1mGoFrmE\
zDg+sKbdVOmOrXYym+RU89yJqXM22vmMKuIvXATXm1oepzjLYr\
NvXsnI9hil1k2QWfhtpxStcegJl8gJEmeSJqJ3o+6MJTwHDO2U\
z78+KtTEDZvhr9zC3K8wcWl80KBVfA7NcYdEbjkMj47sOBzNc=\
 DSA 2048 key

Options associated with a given key are packed in at the beginning of the line corresponding to the key. From now on, we will show this as follows: ssh-dss AAAAB3NzaC... DSA 2048 key

In the above example, a user can access machine "eek" as user "foo" if he/she has the private key associated with the DSA public key shown above.

Once a user authenticates using the right key, he/she can (among other things):

OpenSSH supports a number of options that enforce operation and access control. These per-key options consists of a comma-separated option specifications list where no white space is permitted, except within double quotes. Each option specification begins with a case-insensitive option keyword.

Let's explore some of these options.

Remote hosts

"pattern-list" is a comma-separated list of canonical names of the remote hosts a specific key may be used from to authenticate. The wildcards "?" and "*" are available. Moreover, remote hosts can be denied access if their canonical names are prefixed with the negation wildcard ("!").

Yes, you guessed correctly, this option improves security by a small amount. If an intruder steals the key, he'll be able to log in from any host, as long as there is a route connecting that host to "eek". This option raises the bar since the intruder will have to compromise name servers and/or routers in order to use the stolen key.

Here is an example:

ttypa:foo@eek> cat /home/foo/.ssh/authorized_keys
from="inka.myisp.com, !badhost.mycompany.com, *.mycompany.com" ssh-dss AAAAB... DSA 2048 Key 

If a user attempts to connect from "badhost.mycompany.com", he is denied access . sshd generates the following log:

Feb  1 09:31:37 eek sshd[3341]: Authentication tried for foo with
correct key but not from a permitted host (host=badhost.mycompany.com,
ip=192.168.1.34).

When using canonical names, sshd will make a DNS query unless a name appears in /etc/hosts and your resolver is instructed to use /etc/hosts before querying DNS.

Commands

Let's assume that user "foo" is an operator of some kind. The only thing she needs to perform on host "eek" is to run a backup script (we'll call it "/usr/local/scripts/eekbackup.sh").

User "foo" can't log in from the local console. The only way he/she can access the system is from a remote machine through SSH using a DSA key pair. If we just paste the public key part to foo's authorized_keys file, he/she may access the system and run whatever command is available on "eek" if permissions allow her to do so. This is against our policy. We need to restrict the commands "foo" is authorized to execute so that the only command he/she can run is "/usr/local/scripts/eekbackup.sh". We do this by appending to her public key the following option specification: command="/usr/local/scripts/eekbackup.sh" ssh-dss AAAAB... DSA 2048 Key

We can also prevent "foo" from getting a tty by adding the "no-pty" option specification: command="/usr/local/scripts/eekbackup.sh",no-pty ssh-dss AAAAB...\ DSA 2048 Key

Three words of caution:

Port Forwarding

If we take the above-mentioned example, our security policy only allows the user authenticating as "foo" to run the backup script. She is not, for example, allowed to open connections to other hosts using port forwarding.

The option "no-port-forwarding" prevents port forwarding such as any TCP/IP port forward request made by the client will return an error. This is often used with the 'command="command"' option. Well, let's put that in use: no-port-forwarding,command="/usr/local/scripts/eekbackup.sh",no-pty ssh-dss AAAAB... DSA 2048 Key

Now, what if you want to allow only some ports to be forwarded? OpenSSH has an option for that too: 'permitopen="host:port"'. For example, you want to allow port forwarding to a remote imap server called "imap.myisp.com": permitopen="imap.myisp.com:143" ssh-dss AAAAB... DSA 2048 Key

You can allow multiple host/port forwardings by using multiple "permitopen" options separated by commas.

Note that no pattern matching is performed on the "host" part of the "permitopen" option specification. The specified hostnames must be known hostnames, domain names or IP addresses.

If you attempt to forward a port that is not authorized, you will get a message like this: ttypa:plop@somehost> ssh foo@eek -L 8080:website:80 [snip] channel 5: open failed: administratively prohibited: open failed [snip]

X11 Forwarding

Of course, if you don't want to allow X11 Forwarding at all and for all users, it is far more simpler to do it in "sshd_config": X11Forwarding no

Last but not least

You must also make sure that the authenticating users can't modify the authorized_keys file's contents. I highly recommend to give the file to "root" and make it only readable for the user. And depending on your environment, you may also want to use the "uchg" and "uappnd" or "sappnd" flags with the "chflags" command on the authorized_keys file. That way, you make it more difficult to change its contents. And if you have used OpenSSH for some time, you'll notice that this file doesn't change often ;-).

About The Author

This document is Copyright (C) 2004 Saad Kadhi. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License (FDL), Version 1.2 or any later version published by the Free Software Foundation; with the invariant sections being ``About the Author''.