Setting up ssh v2

When it came to installing ssh-2.0.11, I had great difficulty finding some simple step-by-step instructions for setting it up. This page details how I set it up.

Getting ssh

Firstly, you should make sure which version of ssh you are allowed to use; ssh version 1 has a much less restrictive licence than version 2.

However, as a university, we were allowed to use version 2 at no charge.

A good place to start is the ssh home pages. This is the distribution point for ssh itself and you can download a trial version of the commercial product as sold by Data Fellows if you don't qualify for the free usage. In addition, the commercial version has more features which you may find useful.

The version 2 licence is online at: You can download the source from the main distribution via anonymous FTP from or one of the mirror sites listed.

Version numbers are of the form: ssh-major.minor.minor2.tar.gz where:

  • major is one of either 1 or 2 (ssh1 or ssh2),
  • minor and minor 2 are a sub-revision numbers.

If you want to get ssh2, download the highest numbering ssh-2.x.x.tar.gz file there is.

Compiling ssh

Once you have the file, unpack it using:

    % gzip -dc ssh-2.x.x.tar.gz | tar -xvf -

replacing the x's with the version number you have. cd to the directory and run the following commands:

    % ./configure
    % make
    % su
    # make install

The installation supports the standard autoconf features, such as --prefix, with ./configure --help supplying a list of options as always. All being well, this should compile the software and install the binaries to their locations (/usr/local/bin by default), create a hostkey in /etc/ssh2 and copy a default configuration file to /etc/ssh2/ssh2_config

Installing ssh on the machine

Although the make install copies the files into their places, it does not start up any processes or modify any system files for ssh to be used. Here you have to decide how to set up sshd to be run; there are two choices:

  1. run from inetd.conf
  2. start up a daemon which listens on a port (22 by default).

The first option requires an edit to inetd.conf and sending a SIGHUP to the daemon. This is fairly simple and allows easy use of tcp-wrappers (although see the tweaks section below). However, it is slow as each connection has to generate a key at startup, causing latency for each connection. If speed is not at a premium and you want to save a small amount of RAM, this may be the best option.

Running it as a daemon (in the same way as sendmail) involves starting sshd, ideally in /etc/rc.local or in /etc/rc3.d. A sample script is shown below:


# Startup/shutdown script for sshd


pid=`/usr/bin/ps -Af | /usr/bin/grep $SSHD | awk '{ if ( $3 == "1" ) print $2 }'`

case $1 in
        if [ "${pid}" = "" ]
                if [ -x $SSHD ]
        if [ "${pid}" != "" ]
                /usr/bin/kill ${pid}
        echo "usage: /etc/init.d/sshd {start|stop}"

Note that the awk is used to specify only the process whose ppid is 1 so that it does not just kill off client process and kills of the main process. Also bear in mind which version of ps is used; the script above runs on a Solaris 2 box and will not work under other implementations of ps (eg, linux). However, it should be possible to use any version of ps by just changing the flags from -Af to whatever is required and changing the column numbers in the awk script.

Place the above script (with whichever modifications you need) in /etc/init.d and call it something meaningful (eg, sshd). Link to it from rc3.d or rc2.d, eg:

     # ln -s /etc/init.d/sshd /etc/rc3.d/S70sshd

The script can be started anytime after network services have been initialised, but should only be used in run levels 2 or 3. You might also wish to make sure of a clean shutdown when changing run levels:

    # ln -s /etc/init.d/sshd /etc/rc1.d/K30sshd
    # ln -s /etc/init.d/sshd /etc/rc0.d/K30sshd

Final note regarding startup/shutdown scripts: not all implementations of unix/linux use the same directories; for example, Red Hat linux places them in /etc/rc.d/init.d and /etc/rc.d/rc[0123].d. However, the principle is sound.

Sharing binaries; installing ssh on multiple machines

If you wish, you can share the ssh binaries and manual pages over NFS (although this may hurt the security of ssh; NFS is not considered to be highly secure) or another file-sharing model. In this case, you will probably not be able to run make install on every machine since the client machines may not have the require write permission to the NFS share. In this case, you will have to run the hostkey generation manually and copy the configuration file as well. To do this, you need to run three commands:

    # /usr/local/bin/ssh-keygen2 -P -b 1024 -t dsa -c "1024-bit dsa hostkey" -o /etc/ssh2/hostkey
    # ./install-sh -c -m 644 ./apps/ssh/ssh2_config /etc/ssh2/ssh2_config
    # ./install-sh -c -m 644 ./apps/ssh/sshd2_config /etc/ssh2/sshd2_config

Note that the second and third commands are run from within your ssh-2.x.x directory; you can set up absolute paths if you wish.

While you are going round the machines installing it, you may wish to copy the /etc/init.d or rc.local files at the same time. My advice is to write a short shell script to do everything; generate a key, copy the config file and set up the startup scripts.

Another problem with this model is that if the clients boot up while the NFS server is unavailable, ssh will not start up, requiring a kickstart. One way to prevent this is to run a cron job which checks to see if sshd is running and to start it if it isn't.

Per user configurations

In order for users to use ssh, they have to have the binaries in their PATH and it is also useful to have the man pages in their MANPATH. If you install to /usr/local, the files are probably already in their path. However, I chose to install in /usr/local/ssh (to keep ssh seperate from other apps). In this case, I had to add the following lines to my .cshrc:

    % set path = ($path /usr/local/ssh/bin)
    % setenv manpath $manpath:/usr/local/ssh/man

The equivalent lines in .profile or .zshrc would be:

    % PATH=$PATH:/usr/local/ssh/bin;export PATH
    % MANPATH=$MANPATH:/usr/local/ssh/man

You may wish to put the MANPATH settings in your .login (or equivalent) as you don't need it set when using shell scripts!

Now the user must set up their own host keys. This is done by simply running ssh-keygen:

    % ssh-keygen
    Generating 1024-bit dsa key pair
    1 oOo.oOo.oOo.
    Key generated.
    1024-bit dsa, created by jr@air Thu Dec  3 09:11:28 1998
    Passphrase : This is my passphrase
    Again      : This is my passphrase
    Private key saved to /home/air/jr/.ssh2/id_dsa_1024_a
    Public key saved to /home/air/jr/.ssh2/

You should choose a passphrase which is easy to remember but difficult to guess. In general, the longer the passphrase the better and having non-alphabetic characters (ie, numbers and symbols) in the phrase is also a good idea. If adding these special characters means you have to write down the passphrase, stick with an easier passphrase unless you can be sure no-one will find it.

The above process will create three files in $HOME/.ssh2

random_seed a seed used for the key generation
id_dsa_1024_a Your private key. DO NOT let others see this! Your public key; this is used on remote systems to allow access.

If you wish to use ssh in an NFS environment where the users share the same directory on all machines, everything is now set up for the user to ssh to a host and use encryption on that session. If you wish to use ssh to another site, you will have to copy the public key (ending in .pub) to another system to allow access. Since the public key is public by definition, you can simply ftp or email it to the other site without any worries about security.

Once the .pub file has been put in place in $HOME on the remote host, it has to be added to the $HOME/.ssh2/authorization. Edit the file and add the following line:


where is whatever you called the public key on the remote machine. On the local machine, you have to set up a file called "identification" in the .ssh2 directory. It should contain a line like the following:

    IdKey         id_dsa_1024_a

using the name of the private key file you use. You should now be able to use ssh2 to connect to the remote host:

    % ssh arthur
    Passphrase for key "/home/air/jr/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa, created by jr@air Tue Dec  1 08:57:56 1998":
    Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
    Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
    You have mail.
    (other output from remote host)

It is possible to log in to remote hosts without having to type your passphrase every time by using the ssh-agent program. This is passed a parameter of the subshell you want to run, usually your shell:

    % ssh-agent $SHELL

or, alternatively:

    % exec ssh-agent $SHELL

which is preferable in some circumstances. This is also more efficient with memory as you do not keep a shell process running in the background.

Once ssh-agent has started, you can use ssh-add to add keys into memory:

    % exec ssh-agent $SHELL
    % ssh-add
    Adding identity: /home/air/jr/.ssh2/
    Need passphrase for /home/air/jr/.ssh2/id_dsa_1024_a (1024-bit dsa, created by jr@air Tue Dec  1 08:57:56 1998).
    Enter passphrase: This is my passphrase

You can now use ssh without a passphrase:

    % ssh
    Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
    You have mail.
    (other output from remote host

Bear in mind that your connection to the remote host does not have any keys in memory; the key is still in the local machine's memory.

To list the keys, use ssh-add -l:

    % ssh-add -l
    Listing identities.
    The authorization agent has one key:
    /home/air/jr/.ssh2/ 1024-bit dsa, created by jr@air Tue Dec  1 08:57:56 1998

ssh-add -d deletes the keys individually, so you don't have to start a new ssh-agent process to remove them from memory.

Security point

I'm not 100% sure how the security model of holding these passphrases in memory works, but in an insecure host, it _may_ be possible to capture parts of the memory and grab the passphrases. A core dump is also another way to grab the keys. If you are being extremely paranoid, do not store the keys in memory. On a properly configured workstation, it is unlikely that you will have any problems.

Some tweaks you can apply

Running ssh-agent under X

It is very convenient to have ssh-agent start automatically under X-windows so that all xterms will have ssh-agent running with the key already loaded. This is how to set it up:

First, create or edit $HOME/.xinitrc to contain the following:

exec $SSH_AGENT $HOME/.xinitrc.wm
Then set up your $HOME/.xinitrc.wm to contain the following:
/usr/local/ssh/bin/ssh-add2 $HOME/.ssh2/id_dsa_1024_a </dev/null > /dev/null 2>&1
# Other programs to be started up:
/usr/dt/bin/dtmail &
/usr/dt/bin/dtterm -C -title "Console" &
/usr/dt/bin/dtterm &
This prompts for the passkey before starting two CDE terminals and the CDE mailer. Finally, it runs WindowMaker as the window manager. If you want to run CDE itself, I think that running /usr/dt/bin/Xsession as the last command in .xinitrc.wm will start CDE.

Compiling in TCP_wrappers

As stated above, you can use inetd to install TCP-wrapper support for ssh, but this has a distinct performance hit. It is possible to compile the support in to the binaries using ./configure --with-libwrap=[PATH].

The PATH you should put in is the full path to a compiled libwrap.a, compiled by TCP wrappers. DO NOT use a relative path, as it will try to find libwrap.a from a different directory and will then fail to find it. I speak from experience on this...

For more info on TCP-wrappers, see Wietse's Tools and papers. Wietse Venema is the author of TCP wrappers as well as some other security tools, such as SATAN.

File last modified: Saturday, 06-Mar-2004 14:12:10 GMT