UoC crest

Passwordless ssh to cvs.tcm

From within TCM, host-based passwordless access works to cvs.tcm. From nowhere does password-based authentication work. From elsewhere, public key authentication is possible, although initial access must be via some other method.

For public key authentication, a public/private key pair are generated, the public key stored on any servers you wish to access, and the private key kept securely on the clients from which you wish to use passwordless access.

This scheme has an obvious weakness: if the private key is copied, it can be used freely and trivially from anywhere by anyone. You won't even know that it has been copied. If the private key is sitting in an NFS mounted home directory on a physically open network, copying it is far too easy.

So, in most cases, it is important to strengthen this scheme in two ways:

A passphrase is not as inconvenient as a password. With careful use of ssh-agent, a passphrase will need to be typed once per login session on a client, not each time the client makes an ssh (scp, sftp, cvs/svn over ssh, etc) connection.

The recipe is as follows.

Generate public/private keys

If you do not already have a public/private key pair, generate same, most simply in your .ssh directory

cd ~/.ssh
ssh-keygen -q -f id_rsa -t rsa

This will prompt for a passphrase, and will create two files, id_rsa and The passphrase is a bit like a password, and should certainly be treated similarly -- at least eight characters, no dictionary words, different from other passwords, etc.

Copy public key to the server

The public key needs to reside on the server(s) to which you want passwordless access. The key will consist of a single line starting "ssh-rsa" and followed by a base-64 encoded number of around 350 characters. It should be placed in a file called ".ssh/authorized_keys", preferably prefixed by from="host.domain,*.domain2" to restrict the key to just one domain, and one other host.

$ cat ~/.ssh/authorized_keys
from="host.domain,*.domain2" ssh-rsa AARTghkuideGHiu....
from="" ssh-rsa AAAFumRY/kIL...

The quick-and-dirty method of getting it there would be:

$ ssh cvs mkdir .ssh \; chmod 755 .ssh
$ scp .ssh/ cvs:.ssh/authorized_keys

N.B. Neither the .ssh directory, nor the authorized_keys file, may be group writable. If they are, sshd will ignore them. By default, cvs makes files group writable. You may need to chmod them a little.

Of course, if the reason you are doing this is because you are a non-TCM person who does not have an account on the server, and you wish to have one, then this is the key you need to email (probably to mjr19) to be placed in your newly-created account.

That's (almost) it!

Now one should get the following response when sshing to cvs from a non-TCM computer:

$ ssh
Enter passphrase for key '/home/spqr1/.ssh/id_rsa': 

Eliminating the passphrase

On most Linux distributions, it is sufficient to type "ssh-add" once after loging in. This will prompt for the passphrase(s) of your key(s), and thereafter ssh will automatically contact the ssh-agent program. The ssh-agent program will have been started when you log in, and stores keys and passphrases.

$ ssh-add
Enter passphrase for key '/home/spqr1/.ssh/id_rsa': 
$ ssh


Don't be tempted to use a blank passphrase. The resulting private key is equivalent to a password: it is all that is needed to access the remote account. If that private key ends up in an NFS-mounted home directory, or on a laptop which goes walkies, or even on an unattended computer, it is very insecure. It does not take much effort to walk up to an unattended computer and take a copy of its private keys. (Of course, if one were to be detected doing same, it would take a lot of effort to explain why some very nasty punishment should not result.)

A private key without its corresponding passphrase is useless, as long as the passphrase cannot be guessed. Of course computerised attacks on passphrases are widely available, so, just as with passwords, dictionary words, trivial variations of same, or things of under eight characters are to be avoided.

Public key access to other TCM computers

Is not currently supported. Whereas we can scan for weak passwords, we cannot scan for weak passphrases for public keys not stored in TCM. Experience suggests that too many people like blank passphrases.