Secure SHell (ssh)

Version: $Id: ssh.html,v 1.5 2001/05/02 09:35:39 hans Exp $

This document describes the Secure SHell (ssh) usage at NaN. SSH is a convenient and more secure replacement for TELNET, RSH, RCP, RLOGIN. It is available for every desktop and server operating system we use at NaN. It is also one of the two methods to access the NaN intranet from the internet (PPTP being the other method).

1. Intro
2. Download
3. SSH 3.1. SSH_CONFIG 3.2. SSH and CVS
4. SSHd 4.1. SSHd_CONFIG
5. Public and Private Keys
6. SSH-AGENT

1. Intro

Security is always in conflict with featurism. This is also true for a SSH setup, but at the end SSH offers nice and useful features not found elsewhere.

First of all SSH is used for remote login. Secondly SCP (Secure CoPy) that comes with SSH is used for file copying between hosts. CVS actions can be done over an SSH 'pipe' to a remote CVS repository. The security mechanism of the SSH suite includes an SSH-AGENT that uses public and private keys and PASS-PHRASES with which one can create their own web of trust, resulting in 'no passwords asked' secure remote logins, remote file copies and remote CVS updates. Furthermore SSH offers X-tunneling, that is one can start an X-windows program on a remote machine and have the graphical output optionally compressed and encrypted and tunnelled through the SSH pipe to the local display.

2. Download

Windows: Putty

Unix: OpenSSH (preferred) or ftp://ftp.ssh.com/pub/ssh/

A note from the ssh.com site:

ssh-2.4.0.tar.gz      - latest non-commercial Unix SSH2 version.
ssh-1.2.31.tar.gz     - latest non-commercial Unix SSH1 version (DEPRECATED!).

We still use ssh-1

3. SSH

Use ssh to connect to server or any of the compile machines (except BeOS and WIN2K). Some examples :

ssh server
ssh server.intra.blender.nl
ssh glibc
ssh 192.168.4.20

3.1. SSH_CONFIG

(at least for Unix) This configuration file defines your SSH client preferences. You can define preferences for a single host, for a subnet, or as default for all hosts. Note that any configuration value is only changed the first time it is set. Thus, host-specific definitions should be at the beginning of the configuration file, and defaults at the end.

Here is a useful NaN intranet example:

Host *
        ForwardAgent yes
        ForwardX11 no
        RhostsAuthentication no
        RhostsRSAAuthentication no
        RSAAuthentication yes
        TISAuthentication no
        PasswordAuthentication yes
        FallBackToRsh no
        UseRsh no
        Cipher 3des
        Compression no
        KeepAlive yes

And here is a useful entry for your host on the internet from which you login to NaN.

Host www.blender.nl
        ForwardAgent yes
        ForwardX11 yes
        RhostsAuthentication no
        RhostsRSAAuthentication no
        RSAAuthentication yes
        TISAuthentication no
        PasswordAuthentication no
        FallBackToRsh no
        UseRsh no
        Cipher 3des
        Compression yes
        KeepAlive yes
        # User your-Unix-username-at-NaN
        Port 1100

3.2. SSH and CVS

By setting

setenv CVS_RSH SSH

and using a CVSROOT environment variable that starts with :ext:, one can connect to the remote CVS repository over an SSH tunnel. See also Remote CVS Access via SSH / RSH

4. SSHd

SSHD is the server program to which you connect with your SSH client. On Unix, sshd can be started from inetd or as a daemon. RTFM SSHD(8).

4.1. SSHd_CONFIG

Much like ssh_config, but overruling wishes set by the client. Typically found in /etc/ssh/ RTFM SSHD(8).

5. Public and Private Keys

For systems you log on to regularly you can better use the public and private key authorization method.

First, generate your keys (do this only once) with

ssh-keygen

This will generate in your ~/.ssh/ directory two files :

identity       (your private key, protected with mode 0600)
identity.pub (your public key)

Only if you plan to use the ssh-agent (next chapter) you should sign your keys with a so-called pass-phrase.

For systems you want easy access to, copy (or concatenate) your public key to :

authorized_keys

With this setup, no passwords are asked when you log in. At NaN you can do this on the NFS server, (bye bye security, but hey ;-) and you can log into every compile machine with no questions asked.

6. SSH-AGENT

The ssh-agent is a little gem in the ssh suite. It deals with pass-phrase forwarding, allowing you to create a web of trust. Using ssh-agent means that you authorize yourself to a trusted machine only once, and from there on you never ever have to type in a password again. Of course this trust relation means that your initial session (where you start ssh-agent and authorize yourself to it) is the vulnerable place for your trust web; you should never leave this session alone without a proper locking mechanism.

A good way to start ssh-agent is right after you log into a machine for the first time, typically automatically from your .login. Because you don't want to start a new ssh-agent every time you login some ppl wrote a script named ssh-attach.sh around it, also attaching you to an already existing ssh-agent. Copy it you your personal ~/bin/ directory and use it from your .login like this:

if ($?SSH_AUTH_SOCK == 0 && -f $HOME/.ssh/identity) then
    echo "Setting ssh-agent environment"
    eval `~/bin/ssh-attach.sh`
endif

After this you need to add your passphrase to your just-started ssh-agent only once for all your new (trusted) connections from now on with :

ssh-add

Note 1: make sure that your ForwardAgent setting in your ssh_config file is how you want it. Also ForwardX11 is useless if you don't have a local X server.

Note 2: test your local ssh-agent key list with :

ssh-add -l

You should see something like :

1024 4c:12:96:c9:90:c0:82:75:29:2a:ae:13:40:45:88:ca your-email-address