Principles and overview of using ssh

Implications

Note that with ssh in place all local root access can also be performed securely. This greatly reduces the risk of root compromise due to packet sniffing. There are many other aspects of security via ssh which are beyond the scope of this document.

Details of the system management setup of ssh

Of all the ssh programs, only sshd requires root privilege for installation. Users who merely desire access to remote repositories can use ssh with no privilege.

The secure shell daemon (sshd) must be installed and running on any host which wants to admit remote users. For most purposes it is not necessary to use the make-ssh-known-hosts script to gather the RSA public keys of all remote hosts which have or might access code repositories. This would only be relevant if it were likely that a user's initial ssh contact to a remote host might be intercepted by a man-in-the-middle host (the internet is not yet that nasty) or if the remote host were denying all non-ssh traffic (i.e.; it had shut down rlogind, rshd, rexecd, telnetd, etc.).

The details of the user setup below presume that sshd configuration is pretty much as the default (most notably, that it permits RSA authentication).

Details of the user setup

This following details presume some familiarity with RSA-style public/private key encryption as implemented in ssh. See the ssh man page for operational details of cryptographic challenge/response authentication. The man pages on sshd and ssh-keygen are also relevant.

It should be noted that ssh uses RSA keys at two points in the authentication. Each system running sshd has an RSA key pair which is used at the start of every ssh connection to verify that it is the machine it claims to be (or, more precisely, that it is the same machine as it was the last time it was contacted). Each user of ssh may have one or more RSA key pairs which may be used to verify the identity of the user.

Details of the user setup at the originating end

drwx------   2 sla         xxxx mmm dd HH:MM .ssh/

The relevant files within the ~/.ssh directory are as follows:

-rw-------   1 sla         xxxx mmm dd HH:MM config
-rw-------   1 sla         xxxx mmm dd HH:MM identity
-rw-r--r--   1 sla         xxxx mmm dd HH:MM identity.pub
-rw-------   1 sla         xxxx mmm dd HH:MM known_hosts
-rw-------   1 sla         xxxx mmm dd HH:MM random_seed

Again note that most of them are protected against access by others. The file config may be created by hand as described below. The others are created by the various ssh programs when they run, and their protections are set automatically upon creation.

The identity and identity.pub files contain, respectively, the private and public components of my (default) RSA key. These were created by a run of ssh-keygen. (I have other RSA keys in other identity files. They are all protected using passphrases so that those identities can withstand even a root compromise at Lick. If they had no passphrase it would mean that anyone who can become root on the Lick network could steal those identities.)

The identity file contains the (default) private RSA key. It must be protected against access (especially so if the key within it has no passphrase), but the protection should be correctly set by ssh-keygen when it creates the keys. Failure to protect this file would mean that any other user on my system could steal a key which has no passphrase.

The identity.pub file need not be protected because it contains the public RSA key. When the file is created by ssh-keygen it gets the user's default protection. It is the public key from this file which can be inserted (possibly with slight modification) into the authorized_keys file on the remote host (see below for details).

The public RSA key in the identity.pub consists of one line of text which looks something like this:

1024 37 modulus sla@somehost.ucolick.org

1024 is the number of bits in the RSA key, and 37 is the encryption exponent of this key. The modulus is actually a huge decimal integer of some 200 digits; it is the encryption modulus this public RSA key. The e-mail address at the end is purely commentary.

(Note that if home directories are NFS exported it is highly likely that an intruder machine on the local network -- or any machine elsewhere, if the site firewall does not block RPCs -- can read and modify all "dot"files containing personal configurations. This is a risk that many sites take for the sake of convenience. ssh is of little help unless these kinds of physical security are under control.)

The known_hosts file is created by ssh. It contains a record of the system-level RSA public keys of any machines which I have contacted using ssh. It exists so that ssh can advise me if the public key of the other machine changes, because a change in the identity of the remote system might indicate some kind of security compromise. I have not configured ssh to deny access in such case, but the default alert is impressively clear.

The random_seed file contains the most recent seed used during the cryptographic challenge/response of my ssh connections. A new seed is generated at intervals by both ssh and ssh-keygen.

The ~/.ssh/config file contains both generic and host-specific info about how ssh should configure itself when it establishes contact with a remote sshd. It is not created automatically by any ssh program; it must be created by hand. (It need not be protected against access by others, but I have done so.) Almost all of the configuration options of ssh can be set or reset here. See the man page on ssh for more details.

My generic settings are not relevant to this HOWTO, but for contact to some hosts I have inserted the following lines:

Host name.of.host
ForwardX11 no
IdentityFile ~/.ssh/identity

The first line indicates that any lines following apply only to the particular host. The second line indicates that ssh should not attempt to forward X11 connections. The third line indicates which of my identities I wish to use when contacting this host (in this case it is the default identity, which is not always what I use).

By default, ssh is usually configured to set up a proxy X server on the remote machine (e.g.; name.of.host:10) which forwards securely to the X server on my local machine. This means that any X traffic will be encrypted, which is a good thing. However, it also requires that ssh place an X authentication cookie for the proxy X server into the remote .Xauthority file. So long as the ssh session exists, anyone on the remote machine who can read the remote .Xauthority file can contact my X server.

Because X session forwarding is not required for most access there is no reason to do so. (On the other hand, this level of paranoia is probably not justified in most cases. Someone who could read the X authentication cookie could also modify the startup files of the remote user. So I might still be letting a Trojan Horse into my gates.)

Details of the user setup at the remote end

In the remote home directory there may be a .ssh directory. (Again, though not necessary, I protect this against access by other users.)

drwx------   2 remuser     xxxx mmm dd HH:MM .ssh/

This directory need not exist, and it will not be created or modified when this account is remotely accessed from other sites. (It would be created automatically if there were outbound use of ssh.)

No file in this directory is essential to the inbound secure remote access. Nevertheless, the convenience of the following features makes it desirable to have this directory.

Within the remote ~/.ssh directory there is only one file relevant when this account is used from other sites:

-rw-------   1 remuser     xxxx mmm dd HH:MM authorized_keys

(Again, I have protected it against access by other users, which is not operationally necessary.)

The authorized_keys file is not required, but it is a significant convenience. It is used when someone from outside is accessing a host using RSA authentication. It contains lines akin to the following:

from="*.ucolick.org" 1024 37 modulus

The number of bits (1024), encryption exponent (37), and the encryption modulus (actually about 200 decimal digits) are taken directly from my own identity.pub file at Lick. I have removed the comment following the encryption modulus (which originally contained my e-mail address) because the information in it is not necessary. I have also prepended a restriction which indicates that this key may only be used from machines whose names match *.ucolick.org. (Use of this key from anywhere else would imply that someone had got access to my private key at Lick.)

The format of this file is documented in the man page for sshd, but it is effectively just a concatenation of public RSA keys taken from identity.pub files of users who want to use ssh to login as this remote user. This file is created manually, either by editing or by concatenation. (Note that the length of the moduli may confound some editors which have fixed upper line widths.)

This use of the authorized_keys file is the RSA-authenticated ssh equivalent of putting sla@*.ucolick.org (if such syntax were permissible) into the remote ~/.rhosts file. It means that I do not have to type the remote user password. However it is much more secure than the remote ~/.rhosts because the RSA key is a reasonable assurance that the connection is not coming from some host which is spoofing a machine at Lick.

In the absence of an entry in the remote ~/.ssh/authorized_keys, ssh simply demands the remote user password before proceeding. Note that typing the password is not a security problem because ssh and sshd will be encrypting the session. So, again, the remote ~/.ssh/authorized_keys file is merely a convenience, not a required element of the scheme.

Other keys may be added to the remote ~/.ssh/authorized_keys. The only caveat when doing so is to preserve the existing keys unmodified. Modification of the existing lines would disable the convenient access of the key owners in the same fashion as corrupting entries from the remote ~/.rhosts file would do.