~/.rhostsfiles which can be spoofed by foreign machines that might be on our network. The entire transaction content is encrypted as it travels over the long haul network. This removes security risks from the process of remote operations.
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.
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).
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.
~/.sshdirectory. If it does not already exist it is created when ssh is first used. (I have protected my directory against access by others, although this protection is not required for operational purposes. I have also obscured details of the directory listings which are not essential for this HOWTO.)
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.
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
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.
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 firstname.lastname@example.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.)
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
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.
~/.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.)
In the remote home directory there may be a
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.)
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
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
~/.rhosts file. It means that I do not have
to type the remote user password. However it is much more secure than
~/.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
~/.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.