ssh (secure shell) - installation and administration

This section will be expanded when I have less negative spare time. In the meantime, if you really need assistance with the installation or administration of the ssh package and it is on a machine that is in CUED, then you can try asking jpmg@eng.cam.ac.uk for assistance. No guarantees of useful response times at the moment, however.

Recommendations for ssh installations on unix systems in CUED

Secondly, if you wish to install ssh on an HP-UX machine, contact me (jpmg) first, as there are some problems with HP's management of authentication that require patches that are not yet integrated into the main ssh sources.

Among the sensible places to get the source distribution of ssh if you're downloading to CUED are:

• Imperial College Sunsite archive

There are a number of gotchas to building ssh :

• There are two major different ways of building ssh - one is as a set of separate utilities that people can, if they choose use instead of rsh, rlogin and rcp. This is the way that I've done it and the rest of this page documents.

  The second way is to build them so that they can be used as replacements for rsh, rlogin and rcp. That is, when someone thinks they're running rlogin, they'll actually be running slogin. If you choose to take this more draconian, mandatory approach to security, you're on your own, although some of the points below may still be of use.

• The number of options to the configure program is immense. In practice, the only ones I've had to worry about were --prefix, --with-etcdir, and in some cases --with-path. All the ones to do with feature or package selection (typically whether to compile in a particular crypto algorithm or not) come with very sensible defaults.
  • --prefix determines where the bin, man, and sbin, directories go under. The client executables wind up in bin, and the server executable goes in sbin
    • --prefix=/usr/local/ssh is what I've chosen on most platforms
    • --prefix=/opt/ssh may be more appropriate for HPUX10 or Solaris2
    All of these can be shared between hosts of the same architecture.
  • --with-etcdir determines where the etc directory goes. This is where the per-machine information, such as host public and private keys, lists of known host public keys, server run-time key, client and server configuration files go.
    • --with-etcdir=/etc/ssh is what I've chosen on most platforms
    • --with-etcdir=/opt/ssh/etc is what we've used on the teaching system.
    This directory must be specific to a given machine - it can't be shared. Be careful if you put it in /opt/ssh - this works on the teaching system because it is per-machine, but may well not be on another system.

  • --with-path determines what the default path a user who logs in via slogin or ssh will get in their environment before any initialisation files get run.

    I've only had to set it on Solaris 2 machines (otherwise the default didn't include /usr/sbin! I've used
    --with-path=/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/usr/ucb:/usr/bin/X11:/usr/local/bin
    in this case.

    On all other platforms, leave it as the default (ie don't use this configuration option)

• If you use the same directory hierarchy to build ssh for multiple platforms, you may wind up in trouble. I've had problems where symlinks set up by one make have been left in place inappropriately when I've tried to build for another platform. This may have been carelessness on my part as to which machine I ran make clean on, but I'd recommend doing a make distclean or un-tarring from scratch between architectures.

• Some architectures may have problems with the assembly code bits of the crypto libraries that come with ssh, if you use gcc. In this case, you should make distclean, and then set the environment variables CC and CFLAGS appropriately before running configure again. I would regard this as a better approach that using the --disable-asm option.

• If a user requests "port forwarding" from a centrally installed sshd (ie one running as root), then any ident requests performed by a remote host will be told that the operation was performed by root@host rather than user@host. This is a BAD THING.

  Therefore it is strongly recommended that the file sshd_config in the /etc/ssh (or appropriate) directory, should have the line
  AllowTcpForwarding no
  appended to it.

  This doesn't prevent users from doing port forwarding - it just means that they have to run their own copy of the sshd (running as them rather than as root, and thus generating valid ident responses) in order to do so.

Running an sshd server

The most important things to remember are:

• keep your host private key private. Remember that this is the one private key file (unlike user private keys) that is not encrypted in any way - it depends on the security of the filesystem and the root account to keep it a secret.
• don't regenerate your host key unless you absolutely have to, or you'll have a lot of stressed users thinking that something nasty is happening.
• contrary-wise, if your machine may have had a root compromise, you probably should should change the host key on it. [ So this becomes another of those tedious things you have to do if you ever get hacked, along with root password changes and OS reinstalls ].

Upgrading or reconfiguring sshd servers

• The sshd will re-read its configuration file when sent a HUP

• the make install script in the ssh distribution ought to notice if you already have a host authentication key installed, and not attempt to create one for you. It's probably worth keeping a backup copy of the host authentication key file before doing an upgrade however, to avoid having to tell all your users not to worry about alarming messages should the install procedure not behave as it ought to.

• It is perfectly safe to kill off the parent sshd in order to restart a new instance (perhaps of a newly compiled executable). The sshd instances corresponding to currently running sessions (including perhaps the one you're using to kill off the parent) will continue to work fine - they're entirely independent of it.