SSH access from Unix systems

SSH is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. It is intended as a replacement for rlogin, rsh, rcp, and telnet.

Additionally, SSH will also forward remote executing X11 applications encrypted to your local display and it even sets $DISPLAY correctly. In a breeze...

If you are running some flavour of UNIX at home, e.g. Linux or FreeBSD, you're sitting in the best seat, betting on the best horse here: SSH is a full-featured, one-shop visit package available for free on all UNIX systems!

This document focuses on the UNIX side because that's the most instructive way to generally describe SSH.

Public key Authentication with SSH

DSA and RSA authentication in ssh are based on public key cryptography. The idea is that there are two encryption keys, one for encryption and another for decryption. It is not possible (on human time scale) to derive the decryption key from the encryption key. The encryption key is called the public key, because it can be given to anyone and it is not secret. The decryption key, on the other hand, is secret, and is called the private key.

Public key authentication is based on the impossibility of deriving the private key from the public key. The public key is stored on the server machine in the user's $HOME/.ssh/authorized_keys file. The private key is only kept on the user's local machine, laptop, or other secure storage. When the user tries to log in, the client tells the server the public key that the user wishes to use for authentication. The server then checks if this public key is admissible. If so, it generates a 256 bit random number, encrypts it with the public key, and sends the value to the client. The client then decrypts the number with its private key, computes a 128 bit MD5 checksum from the resulting data, and sends the checksum back to the server. (Only a checksum is sent to prevent chosen-plaintext attacks) The server computes a checksum from the correct data, and compares the checksums. Authentication is accepted if the checksums match.

The DSA or RSA private key can and should be protected with a passphrase. The passphrase can be any string; it is hashed with MD5 to produce an encryption key for 3DES, which is used to encrypt the private part of the key file. With passphrase, authorization requires access to the key file and the passphrase. Without passphrase, authorization only depends on possession of the key file (that can be stolen without you being aware of that!).

Never make your private key passphrase equal to your UNIX password.

Our shellservers are running ssh protocol version-2. Both DSA and RSA version 2 are supported. 'Old' RSA (from ssh 1.x, usually named 'rsa1') is not supported anymore. RSA or DSA authentication is the most secure form of authentication supported by SSH. It does not rely on the network, routers, domain name servers, or the client machine. The only thing that matters is access to the private key.

Generating and Using DSA Keys

ssh-keygen is used to generate DSA keys: normally each user wishing to use ssh with DSA authentication runs this once to create the authentication key in $HOME/.ssh/id_dsa. The public key is stored in a file with the same name but ".pub" appended. The program also asks for a passphrase. The passphrase can be changed later by using the -p option. There is no way to recover a lost passphrase. If the passphrase is lost or forgotten, you will have to generate a new key and copy the corresponding public key to other machines.

Sample session:

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/users/testman/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /users/testman/.ssh/id_dsa.
Your public key has been saved in /users/testman/.ssh/id_dsa.pub.
The key fingerprint is:
a7:8f:f1:eb:32:81:77:47:10:0b:bd:1a:f3:c9:3d:bd testman@adonis.cs.uu.nl
$

After generating the DSA or RSA keys, your $HOME/.ssh/ directory on your LOCAL system (i.e. your home computer or your notebook) should look similar to this:

$ ls -al .ssh/
drwx------    2 testman  staff         512 Jun  3 16:11 .
drwx--x--x   55 testman  staff        3584 Jun  3 16:11 ..
-rw-------    1 testman  staff         736 Jun  3 16:11 id_dsa
-rw-------    1 testman  staff         613 Jun  3 16:11 id_dsa.pub

If the permissions on the files and/or directory listed above are more liberal than shown here, please correct them using chmod(1). If you don't, SSH will refuse to run.

Now that you have your DSA keys, you should transfer the public key to your account on the machine or network that you want to logon to. For CS.UU.NL this simply implies that you should put your public key in the file $HOME/.ssh/authorized_keys on the CS.UU.NL network (your $HOME at work).

The $HOME/.ssh/authorized_keys file lists the keys that are permitted for authentication. Each line of the file contains one key (empty lines and lines starting with a '#' are ignored as comments). More detailed information on the format of this file is documented in the sshd(8) manual page.

You may transfer your public key across un-secure channels; you may even publish it in a phonebook if you want... Cut-and-paste generally works well for transferring the key.

In addition you may restrict the use of this public key depending on where you come from, e.g. if you always logon from the Casema network in Utrecht, you could limit use of the key to that network only, which is in general a good idea.

  from="*.utr.casema.net"
  1024 35 1349245022957686829259739288933434697361042331776235508125662186
          8073937911344771502350227675835007113074630425420356846082859727
	  2801415927709155276849981908881004082264780592965379766276489813
	  6793681025850247166513553364008543448412848194454968699112454122
	  28246552822500315352219456112627482232212906850736087
	  you@some.where.net

All on a single line, line-breaks inserted here for readability.

Your $HOME/.ssh/ directory at CS.UU.NL now should contain at least this (make sure to check permissions again):

$ chmod 700 $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ ls -al $HOME/.ssh
drwx------  testman staff        512 Nov 23 20:53 .
drwx--x--x  testman staff       2048 Nov 30 07:00 ..
-rw-------  testman staff        357 Nov 23 20:49 authorized_keys

Running SSH for the first time

First time you log on to a 'new' system, ssh will notify you that the public key is unknown. Accept it, otherwise you can't login.. Use -l login when your login name on the CS.UU.NL system differs from the one on your local machine. I use -v verbose here to show all messages from ssh:

$ ssh -v -l testman shell.cs.uu.nl
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /users/you/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to shell.cs.uu.nl [131.211.80.24] port 22.
debug1: Connection established.
debug1: identity file /users/you/.ssh/identity type 0
debug1: identity file /users/you/.ssh/id_rsa type -1
debug1: identity file /users/you/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'shell.cs.uu.nl (131.211.80.24)' can't be established.
RSA key fingerprint is ae:0e:94:01:9f:f3:f7:4b:5d:22:db:0c:65:82:62:f1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'shell.cs.uu.nl,131.211.80.24' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Department of Information and Computing Sciences
Faculty of Science, Utrecht University         [ http://www.cs.uu.nl/ ]

Unauthorized access not allowed.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /users/you/.ssh/id_rsa
debug1: Offering public key: /users/you/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type 
Enter passphrase for key '/users/you/.ssh/id_dsa': Your very secret pass phrase will not show
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting authentication agent forwarding.
Last login: Mon Mar 30 20:28:37 2009 from koos.idefix.net
testman@adonis:~$ 

In non-verbose mode, this looks a lot more quiet:

$ ssh -l testman shell.cs.uu.nl
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Department of Information and Computing Sciences
Faculty of Science, Utrecht University         [ http://www.cs.uu.nl/ ]

Unauthorized access not allowed.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Enter passphrase for key '/home/you/.ssh/id_dsa': Your very secret pass phrase will not show
Last login: Mon Mar 30 20:28:37 2009 from koos.idefix.net
testman@adonis:~$ 

Copying files with SSH

scp copies files between hosts on a network. It uses SSH for data transfer, and uses the same authentication and provides the same security as SSH. The scp command will ask for passphrases or passwords when needed.

$ scp shell.cs.uu.nl:TeX/linux-kernel.tex TeX/backup/
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Department of Information and Computing Sciences
Faculty of Science, Utrecht University         [ http://www.cs.uu.nl/ ]

Unauthorized access not allowed.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Enter passphrase for key '/home/you/.ssh/id_dsa': Your very secret pass phrase will not show
$

Using 'ssh-agent'

ssh-agent is a program to hold authentication private keys. The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as children of the ssh-agent program (the command normally starts X or is the user shell). Programs started under the agent inherit a connection to the agent, and the agent is automatically used for ssh authentication when logging to other machines using ssh.

If you are running the X window system, it is advised to start ssh-agent as the last command in your X startup files (usually ~/.xinitrc or ~/.xsession) on your LOCAL system:

exec ssh-agent fvwm

The agent initially does not have any private keys. Keys are added using ssh-add When executed without arguments, ssh-add adds the keys in the default keyfile(s). If the identity has a passphrase, ssh-add asks for the passphrase (using a small X11 application if running under X11 without tty access, or from the commandline). It then sends the identity to the agent. Several identities can be stored in the agent; the agent can automatically use any of these identities. ssh-add -l displays the identities currently held by the agent.

Ofcourse, this adds a new security risk: keys abused from an unlocked screen. Lock your screen when not in use. And limit the time the keys are added to the ssh-agent using the -t parameter of ssh-add. Sample:

$ ssh-add -t 1800
Enter passphrase for .ssh/id_dsa: This 1 should be HARD to guess!
Identity added: .ssh/id_dsa (.ssh/id_dsa)
Lifetime set to 1800 seconds
$ ssh-add -l
1024 d8:3f:41:f9:1e:e2:04:82:11:1f:df:ad:18:52:59:58 .ssh/id_dsa (DSA)
$ ssh-add -d
Identity removed: /home/you/.ssh/identity (/home/you/.ssh/id_dsa)

Our history

We have been using a one-time passwords scheme with S/Key cards on our gatekeeper system since 1995 to prevent un-authorized access to our infrastructure. One-time passwords have the advantage over re-usable passwords (when you log in, your password goes over the network in plain text) that eavesdropping doesn't give possible attackers much useful information (several incidents over the past couple of years show that eavesdropping really does occur and that at least some of our passwords are widely known!).

However, Internet attacks have become more sophisticated and one-time passwords are simply no longer good enough: nowadays an attacker will eavesdrop on a connection setup and wait for authentication to be completed, then take over the connection (connection hijacking) using IP spoofing techniques that enables him to modify data in both directions and e.g. insert new commands in sessions authenticated by one-time passwords.

Password-guessing attacks over ssh make it also quite dangerous to have passworded logins enabled from the outside Internet.

Related pages

Accounts and passwords
BSCW shared workspace server
General servers
Practicum computers (nederlands)
Remote access to our systems
SSH access
Staff account migration ; mail-client configuration and moving mail
Staff account migration to soliscom accounts
Staff desktop systems
Students account migration to soliscom accounts

---