kill $SSH_AGENT_PID

Don’t do this if you’re using keychain, because the whole point of using keychain is to be able to log in and out without having to re-enter your passphrases.

If you don’t have a ~/.bash_logout file, create one. There should be a system-wide default logout file at /etc/skel/.bash_logout to use as a model.

Download and install keychain from the usual sources; it comes in RPMs, .debs, and sources. Then edit your local ~/.bash_profile, adding these lines:

keychain id_dsa
. ~/.keychain/$HOSTNAME-sh

Use the real name of your private key: id_rsa, my_own_groovy_key, whatever. Be sure to use the leading dot on the second line; this tells Bash to read the file named on the line.

That’s all you have to do. Now when you log in to your local workstation, a keychain prompt will appear, asking for the passphrase of your key. keychain will handle authentications until the system reboots.

You can name as many keys as you wish to use, like this:

keychain id_dsa apache_key ftp_key

You’ll enter the passphrase for each one at system login. Then keychain will handle authentications as long as the system stays up, even if you log out and log back in a few times. When you restart the system, you start over.

A lot of documentation tells you to use null passphrases on keys generated for servers, to enable unattended reboots. The risk is that anyone who gets a copy of the private key will be able to easily misuse it. As always, you’ll have to decide for yourself what balance of convenience and security is going to serve your needs.

Enable X forwarding on the SSH server, in /etc/ssh/sshd_config. Then use the -X flag when you start your SSH session.

Put this line in /etc/ssh/sshd_config on the SSH server:

X11Forwarding yes

Then connect to the server with the -X flag:

$ ssh -X saturn.test.net

Run this command to test that X forwarding is working:

$ echo $DISPLAY
localhost:10.0

If it weren’t, it would return a blank line. Now you can run any X program installed on the server as though it were local. Try this for a simple test:

$ xeyes

Or run glxgears, or any X program that is installed on the server.

Using SSH for remote X sessions is both simpler and more secure than running a plain-vanilla X session without SSH, which is not secure at all. However, it still carries some risks. Use this to connect only to trusted hosts, because a snoopy admin can easily capture your keystrokes or logins, or even connect to your local desktop and snoop even more. Make sure your local ~/.Xauthority file is mode 600, to prevent unprivileged users on the remote host from also joining in the snooping.

Be sure that these entries are in your local /etc/ssh/ssh_config file and any ~/ ssh/ssh_config files on your system:

Host *
ForwardX11 no
ForwardAgent no

It’s important to ensure that X forwarding is turned off, except when you absolutely need it.

Depending on your physical distance from the remote server and the speed of your network connection, you may notice some lag in your keystrokes or mouse movements, as the X protocol is a bit of a network hog.

Use ssh-keygen to create a new key pair. This must be done as root, and you have to specify the name of the new key pair. You only need one key pair. Always specify a passphrase:

# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
6c:24:75:54:d3:21:17:c9:11:db:41:dd:95:3f:d0:ac root@windbag

This example uses the default key names, but you can call the keys anything you like. If you use different names, be sure to enter them in /etc/ssh/sshd_config:

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key

Starting and stopping sshd on most rpm-based systems is done like this:

# /etc/init.d/sshd start
# /etc/init.d/sshd stop

On Debian, it’s slightly different:

# /etc/init.d/ssh start
# /etc/init.d/ssh stop

Always check your init filenames, as they vary on different distributions.

Copying the remote host’s public key to your local ~/.ssh/known_hosts file is as simple as connecting to the remote host:

carla@windbag carla$ ssh stinkpad
The authenticity of host ’stinkpad (192.168.1.100)’ can’t be established.
RSA key fingerprint is a2:c6:70:3e:73:00:b3:ed:90:b1:9a:bc:e7:d5:32:ba.
Are you sure you want to continue connecting (yes/no)?

Type yes, and it will respond:

Warning: Permanently added ’stinkpad,192.168.1.100′ (RSA) to the list of known hosts.
carla@stinkpad’s password:
Linux stinkpad 2.4.21 #1 Sun Aug 3 20:15:59 PDT 2003 i686 GNU/Linux
Libranet GNU/Linux
Last login: Sat June 3 22:16:24 2004 from :0.0
carla@stinkpad:~$

Using the simple ssh login connects you to another host on your LAN, using the same login. You can connect as a different user with the -l flag:

carla@windbag ~$ ssh -l wilmaf stinkpad

To make an SSH connection over the Internet, you must use the full domain name:

carla@windbag ~$ ssh stinkpad.test.net

Making that initial connection, and copying the host’s RSA key, is the riskiest part of setting up SSH. If an intruder managed to compromise your nameserver, she could possibly hijack your SSH session and capture your login. It’s a pretty small risk, though, and you can verify the IP address before logging in the first time. To close off this hole, you can manually copy the host’s public key to your local ~/.ssh/known_hosts file first. You must edit it slightly; see the examples below.

Host keys are stored in /etc/ssh. These are used to validate the identity of the remote host. This is all you need to allow users to access this machine. All they need is a copy of the public host key in their ~/.ssh/known_hosts files and an account to log into. Some Linux distributions create two key pairs when you install OpenSSH—one RSA key pair and one DSA key pair:

$ ls /etc/ssh
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub