next up previous contents
Next: using Secure Copy (scp) Up: Appendix A : Using Previous: Installation   Contents

Using RSA keys : advice for every user

It is possible to use 1024 bit dual key encrypted logins - thereby avoiding the problem of bad passwords. The machine generates a unique and completely uncrackable key pair. Just re-run ssh-keygen when you want to change it (e.g if your private key gets stolen). In any case using a secure shell (ssh) and Secure copy (scp) will add strong encryption to any connection. For example anything you type is transmitted over the secure link strongly encrypted - including all X transactions.

To make an RSA keypair run the command:

    ssh-keygen -t rsa -f identity

It will ask you for a passphrase. It is important that you add a secure passphrase. If your private key is stolen (or copied) it will be of no use to anyone without knowledge of the passphrase. Passphases can be as long as you like and contain spaces, punctuation etc - e.g

 M@ry had a little LAM it's fleas were white as snow !!
Having generated your keys, make sure the key directory .ssh in your home directory both on the local machine and the remote server is protected :

chmod 700  ~/.ssh
chmod 600  ~/.ssh/*
You will then find these files in .ssh the first time you generate keys :
drwx------   2 nrcb     users        1024 Feb 21 10:07 ./
drwxr-xr-x  60 nrcb     users        7168 Mar 13 17:35 ../
-rw-------   1 nrcb     users         525 Feb 12 09:44 identity
-rw-------   1 nrcb     users         329 Feb 12 09:44
-rw-------   1 nrcb     users         512 Mar 13 17:35 random_seed
If you don't have a passphrase then anyone who copies your private key will be able to login anywhere that you can.

The file identity is your private key which should be guarded with your life. Give it to nobody (I mean nobody). In fact I would not recommend keeping your private key (.ssh/identity) on any machine unless you have a good passphrase. The file is your public key - which in principle you can post on the Internet without compromising your security. The first thing you should do is copy to the file authorized_keys in the same directory. You can then copy the authorized_keys file to your .ssh directory on all the remote hosts you want to login to. Why not start on the right track and use secure copy ?

cd ~/.ssh
scp  authorized_keys remotehost:.ssh/.
where remotehost is the hostname of the remote server you wish to login to.

You will be asked your usual password on the remote machine. If you have a different username on remotehost then you need to use the syntax:

cd ~/.ssh
scp random_seed authorized_keys user@remotehost:.ssh/.
where user is your remote username. You should now be able to ssh to remotehost. You will be asked for the passphrase when you connect. If you want to avoid having to type in a passphrase each time you login but still want to have a passphrase protected private key, then read the section 10.0.4 on ssh-agent.

Once you are logged through to remotehost you should be able to start an X application and it should display on your local screen without setting the DISPLAY variable.

This is because ssh is doing X forwarding via a strongly encrypted channel. If you set the DISPLAY by hand then you effectively turn off all the security - so don't do it.

If you find that an X application does not start (Cannot open DISPLAY error) - then you probably have a line in one of your shell startup files which has re-set the DISPLAY variable at login.

Look in your .login, .cshrc, .bash_login etc files on the remote machine and locate where the DISPLAY is set and remove these lines.

Note: If you think your private key has been compromised - simply generate a new key pair with ssh-keygen and distribute your new public key (aka authorized_keys) to all the remote hosts you require to access.

next up previous contents
Next: using Secure Copy (scp) Up: Appendix A : Using Previous: Installation   Contents