Using SSH With Unix

Ssh is a secure shell program. It is actually a family of programs (ssh, scp, sftp) that replaces the older and now deprecated rsh, rcp and ftp. In essence, the only difference between the ssh programs and the ones they replace is in how they handle passwords. Ssh never transmits passwords in the clear. There is a man page for ssh on most machines. However, like many man pages, it's mostly inscrutable and primarily useful for figuring out what to do if you already know what it says. This web page tries to make things a bit easier to understand by talking about how to use ssh, rather than how it works.

You might also want to check out this pdf file for a great high level overview of how ssh works, and some of its features.

Options for using SSH

There are two ways to uses ssh. You can enter your password every time you want to access a remote machine, or you can enter your password once when you login with an agent who will then field password requests on your behalf by ssh-enabled servers. To use the first option, you need do nothing. Simply use ssh, scp, or sftp.

The second option is much more convenient, but does require a few minutes to setup the very first time. The instructions below explain how to do this.

Preparing to use SSH

Basically, you will establish your public and private keypair, and a passphrase. You will store your public key on any machine to which you would like to securely connect. You will store your private key on the machine from which you would like to connect. You will use your passphrase to "conceal" your private key so that it is more difficult for someone to steal if they have access to your files.

To generate your public/private keypair, type
ssh-keygen -t rsa
The -t rsa option says "use version 2 of the protocol, which is based on rsa and much more secure." You will be asked for the name of the file to store the key (defaults to ~/.ssh/id_rsa). Choose the default. You will be asked for a passphrase. Enter a password that you are unlikely to forget. The program will then show you something called a "key fingerprint" -- don't worry, you don't need this for anything. It will also tell you that it has created two files, "keyfile" and "keyfile.pub" where keyfile is probably ~/.ssh/id_rsa unless you specified a different default.
To push your public key to any target machine to which you would like to connect with ssh, scp or sftp, you will append the keyfile to ~/.ssh/authorized_keys2 on the target. If this is the first time you have set up ssh on the target, type the following:
ssh target mkdir .ssh
where target is the name of the target machine. Enter your password (NOT your passphrase, which you specified with keygen). Then, type
scp target ~/.ssh/id_rsa.pub target:.ssh/authorized_keys2
Again, enter your password.
If you already have a .ssh/authorized_keys2 on the target, type
cat ~/.ssh/id_rsa.pub | ssh target "cat >> ~/.ssh/authorized_keys2"
Enter your password when asked.

Setting up to automatically use your keypair

Now, to use your public/private keypair, you will need to start up an agent on the client who will field authorization requests from the target. The idea is that you start this agent up once when you login, and that your login shell and all child processes "know" where to find the agent (its TCP/IP address), and pass this information on to ssh and friends each time you use it. The tricky part here is that the "parent/child" relationship of UNIX shells may not match your actual model of use, which may not place a UNIX shell at the top of your process hierarchy (for example, on a Mac).

There are two options -- one that uses a native MAC OS X agent, and one that just uses Unix tricks. Read the description below for the Unix approach. If it seems to complex for you, pick up the native agent from here.

The Unix approach will have you use the file system to communicate the location of the agent and explicitly "grab" that information each time we start a shell. Here are the instructions for making this happen in such a way that you only have to enter your passphrase for the first terminal shell you create:

Add the line "source ~/bin/sshlogin.cmds" to your .login file in your home directory.
Make sure you have a ~/bin directory (mkdir ~/bin if you don't)
Download this file to ~/bin/sshlogin.cmds
Download this file to ~/bin/sshstart
Download this file to ~/bin/sshkill
chmod 755 ~/bin/sshstart ~/bin/sshkill

Here's how this works. When you login, you will automatically source the script sshlogin.cmds which will in turn run the program sshstart. This program will check to see whether you are already running a copy of ssh-agent (part of the ssh family). If not, sshstart will start up ssh-agent, which will ask you for your passphrase, and then save the agents TCP/IP address into the file ~/.ssh/sshagent.cmds. This file is sourced in order to set the location into shell variables (SSH_AGENT_PID and SSH_AUTH_SOCK). Once this is done, any ssh program you run from the shell you just started will "know" where to find the ssh-agent. At any time, you can run sshkill to terminate the agent, and sshstart to restart it.

Note that the passphrase you enter to shadd is NOT your local password, which is used to control access to the machine you are running on. The passphrase is used to PROTECT your private key, which is stored in the .ssh directory. There is no reason to make your login password the same as your passphrase, although it makes things easier to remember.

Using SSH with X11

If you only use ssh inside an X terminal, you can get away with something a bit simpler. Instead of doing all that stuff with sshstart, etc, simply start up the ssh-agent inside your ~/.xsession file:

eval `ssh-agent` ssh-agent

before you start up the window manager, and add

eval `ssh-agent -k

at the end.

Put the following line in a file called ~/.ssh/config:

ForwardX11 yes

Now, from within an xterminal, ssh over to the target. On the target, the DISPLAY variable will be set (oddly) to "localhost:11.0" (or some other small number). What's really happening is that the ssh daemon on the target machine (where localhost is implied), will act as an X11 proxy tunnel, forwarding your X11 traffic over an encrypted link back to the original machine.

NOTE that this also makes it possible to run X11 across a NAT or firewall. This is very useful for home use.

Port Forwarding in General

In general, you can tunnel any TCP/IP based protocol over an ssh connection. There are two reasons you might tunnel. The first is that there is some Internet service you would like to access on a remote machine where you have an account, but you want to make sure that nobody snoops on your connection. Standard encryption here. The second reason arises when you are working in an environment that restricts outgoing traffic -- for example, behind a corporate firewall -- but you need to generate that kind of traffic. Think of it as a 'cheap, manual, VPN.'

For example, suppose you have want to use IMAP from the road to connect your mail client to your mail server running on a departmental machine. Your "point of presence" though is blocked from sending traffic to the IMAP and SMTP ports on the mail server. You can set up an SSH tunnel to circumvent the restriction.

On the machine running the mail client, run:

ssh -N -L 9997:yourname.mail.cs.washington.edu:997 -L 9025:yourname.mail.cs.washington.edu:25 targethost&

where "yourname.mail.cs.washington.edu" is your IMAP/SMTP server, and "targethost" is a machine that is not blocked from communicating with the server.

Now, set up your mail client to send mail at localhost port 9025, and to get mail at localhost port 9997.

NOTE: I've not been able to get the IMAP port forwarding to actually work. Possibly due to it being IMAPS??

SSH Agent Forwarding

If you tend to "visit" the Internet from one machine, but indirect through many others, you might find it useful to enable SSH forwarding, which in effect says "when I ssh to another machine, if I ssh from there, please redirect all authentication requests to my original machine where my agent is running." This makes it possible to "log in" to your local machine and then go anywhere.

To enable ssh forwarding, add the line

ForwardAgent yes

to the file ~/.ssh/config

Problems

If after entering your password to the agent, you're still being asked to enter a password for each ssh command, try killing and restarting the agent. Use ~/bin/sshkill to kill the agent. Use ~/bin/sshstart to restart it.

If it's still not working, then the target machine may not be running a compatible version of the ssh daemon. I've never seen this happen in the department, but if you are connecting an unmanaged machine, it's conceivable. At this point, I suggest you consult the man page for ssh for help in resolving this.

Copyright 2003 Brian Bershad