Christopher Spry's Web

Guide for setting up 'ssh1' on an Indy running IRIX 6.5.*

'ssh1' from DataFellows provides secure connections between computers. It is free, "provided that you are a student, faculty member, researcher, employee or administrator at university, other accredited non-profit educational or university-affiliated research institution, or charitable organization." (Before July 2000 it was free for anyone to use). It replaces 'telnet' and other connections that do not support encryption and authentication for the connection between two computers. This guide is based on my installation of 'ssh1' on 26 November 1999, on my SGI Indy running IRIX 6.5.5f. Note that 'sshd' version 1 and 'sshd' version 2 are not compatible. I thank Peter Ilieve, Rado Faletic and Justin Meads for their help with compilation and other issues. A related 'open' version of the SSH suite of network connectivity tools called 'OpenSSH' is being developed at the OpenBSD Foundation, but I have no experience of using it. ssh2 is only available for use in the USA and Canada.

Note added on 10 February 2001: ssh v 1.2 and earlier versions have been found to have a security problem. A fix has been committed to the source tree. 'OpenSSH 2.3.0' does not have this security problem and as it is free and supports both ssh v 1 and 2, it has now become preferable to ssh v 1. 'OpenSSH' v 2.9 can be downloaded with installation instructions. Note, however that a local root exploit for OpenSSH versions between 2.0 and 3.0.2 was discovered in March 2002, so a later, or patched version is needed.

Other links:

'SSHD man page'. A detailed description of ssh1.
'Guide to installing ssh1 client software for Windows', to access computers running 'ssh1' from a PC.
'Guide to installing ssh2' on an Indy.

1. Prerequisites
2. Obtaining ssh v 1
3. Compiling ssh
4. Starting sshd
5. Checking that the startup procedure works and setting it to start automatically
6. Making 'RSA authentication' keys, to control access to other computers
7. Testing the connection
8. Man pages
9. ssh version 2

1. Prerequisites

As the free compiler 'gcc' does not compile 'ssh1', I had to install 'cc' on my Indy. The way to do this is described at http://support.sgi.com/lang/73compiler_varsity.html. I had to enter in file '/var/flexlm/license.dat', the license for 'cc', which I obtained from SGI, before I could use 'cc' to compile 'ssh1'.

2. Obtaining ssh v 1

I downloaded 'ssh-1.2.31.tar.gz' from ftp://ftp.ssh.com/pub/ssh/ to /tmp.

3. Compiling ssh

I cd to the '/tmp' directory and, as an ordinary user, I executed 'gzip -dc ssh-1.2.27.tar.gz | tar xvf -'.

I cd to the 'ssh-1.2.27' directory and became 'su'. I ran the commands:

bash

CC=cc ./configure --prefix=/usr/local --with-none

Notes:
1. where CC=cc you can put CC="cc -n32" or whatever options you specifically want for your compiler. Also, if you leave this out, then ssh may try to use gcc, which will not work.
2. Instead of 'bash', you can use the Bourne or Korn shells and the './configure' line above.
3. If you are using 'tcsh', then type "setenv CC cc" or "setenv CC 'cc -n32'" and then leave out the CC=cc part from the configure line.
4. This guide does not use 'RSAREF2' but it is possible to compile ssh v 1.2.27 with RSAREF2, using the option '--with-rsaref'. CERT 99-15 has stated that there are security problems in ssh v 1.2.27: "Some versions of sshd are vulnerable to a buffer overflow that can allow an intruder to influence certain variables internal to the program. This vulnerability alone does not allow an intruder to execute code. However, a vulnerability in RSAREF2, which was discovered and researched by Core SDI, can be used in conjunction with the vulnerability in sshd to allow a remote intruder to execute arbitrary code." For this reason, if you want to compile ssh with RSAREF2, make sure that you use a fixed version.

The command 'CC=cc ./configure --prefix=/usr/local --with-none' output many lines of information. There were no serious errors. (Note, that if you have ssh1 or ssh2 installed previously, new copies of the programs, installation and configuration files will not be generated. In particular, it will not generate '/etc/ssh_host_key', which is required for the daemon to load. Check the output to see if they are made, or not).

I then ran 'make' which told me what is was doing. This took several minutes.

I then executed, as root, '/tmp/ssh-1.2.27/make install'. This installed several 'ssh1' files:

/usr/local/bin/ (ssh1, scp1, ssh-agent1, ssh-keygen1 and ssh-add1)
/usr/local/sbin/ (sshd1)
/usr/local/man/ (man pages for the new programs in /usr/local/bib)

A 1024 bit host key was generated and a 1024-bit dsa key pair.

The private key was saved to /etc/hostkey and the public key was saved to /etc/hostkey.pub. File /etc/ssh_random_seed was also generated.

It installed '/etc/sshd_config' and '/etc/ssh_config'.

I edited '/etc/sshd_config' and changed the PrintMotd to be "no" and the QuietMode to be "yes".

4. Starting sshd

I then set up a daemon to start /usr/local/sbin/sshd. I made an executable script called '/etc/init.d/sshd' with the following entries:

#!/bin/sh
# Startup/shutdown script for sshd
SSHD=/usr/local/sbin/sshd
pid=`/usr/bin/ps -Af | /usr/bin/grep $SSHD | awk '{ if ( $3 == "1" ) print $2 }'`
case $1 in
'start')
        if [ "${pid}" = "" ]
        then
                if [ -x $SSHD ]
                then
                        $SSHD
                fi
        fi
        ;;
'stop')
        if [ "${pid}" != "" ]
        then
                /usr/bin/kill ${pid}
        fi
        ;;
*)
        echo "usage: /etc/init.d/sshd {start|stop}"
        ;;
esac

5. Checking that the startup procedure works and setting it to start automatically

I checked that executing '/etc/rc2.d/sshd start' started a daemon called 'sshd'. Executing '/etc/rc2.d/sshd stop' stopped the daemon running.

I linked the script to enable it to run at startup and shutdown using the following commands:

'ln -s /etc/init.d/sshd /etc/rc2.d/S70sshd' to start it at startup
'ln -s /etc/init.d/sshd /etc/rc0.d/K32sshd' to close it at shutdown

I noted that the configuration files in '/etc/sshd' both ran through port 22.

6. Making 'RSA authentication' keys, to control access to other computers

Although ssh works without needing 'RSA authentication', it is best to set it up, so that the host and client computers can prove that they are 'genuine'. I generated my (cspry's) RSA keys as follows

[[sprysgi] ~ /usr/local/bin/ssh-keygen

This generated the RSA encryption key pairs and I entered a passphrase (password) twice.
Private key saved to /disk6/usr2/people/cspry/.ssh/identity
Public key saved to /disk6/usr2/people/cspry/.ssh/identiry.pub

Directory ~cspry/.ssh then contained the files:

identity                (which contained my secret key)
identity.pub        (which contained my public key)
random_seed    (a file to create the keys)

I generated a similar set of keys on the remote UNIX computer which had 'ssh1' installed. I did this by telnet to the remote computer and running 'ssh-keygen', when logged in as myself. It generated a similar set of files in ~myaccount/.ssh. These keys are used to authenticate the client and host computers running 'ssh'.

Now I made a file called 'authorized_keys' on the host computer in the user's .ssh directory. I added the contents of the client computer's '.ssh/identity.pub' file to the host's '.ssh/authorized_keys' file. There was one line for each client that is authorized to connect to using 'RSA authentication'.

7. Testing the connection

I then tried to connect to the remote computer with ssh:

ssh <remote.computer.name>

cspry's password:
<password>
Last login: Tue Nov 16 1999 14:12:41
..

This showed that I was able to login remotely with a secure 'ssh' connection.

Note that it is possible to 'watch' the connection being made, using the command 'ssh -v <remotecomputer>'. If you do, you may see 'Server refused our key. Doing password authentication.' This refusal is for 'RSA authentication' of the two computers, which has to be setup separately, if it is to be used. 'ssh' connections will take place successfully, even though 'RSA authentication' has not been setup. Follow the suggestions above, for making a file called 'authorized_keys', to enable RSA authentication.

8. Man pages

Finally, I formatted and compressed the 'man' pages ('sshd', 'ssh-keygen', 'ssh-agent', 'ssh-add', 'scp', 'ssh' and 'make-ssh-known-hosts'), that had been copied to '/usr/local/man', when 'ssh1' was installed. I copied the formatted and compressed man pages to the relevant '/usr/local/man/cat1' and '/usr/local/man/cat8' directories, so that they could be accessed easily. An HTML version of ssh was created here, for users who have not yet installed it.

9. ssh version 2

Commercial versions of 'SSH version 2' for UNIX and Windows are available at DataFellows. I have a guide to installing them. These are updated and extended versions of the 'ssh' v 1, as described in this guide.

Return to the 'home page'

Return to the `Computing index page'

Return to the 'Indy administration index '