With SSH, instead of typing in your password each time you login somewhere, you can authenticate yourself once to an "agent" on the machine that you are sitting at, and then the agent can authenticate itself to other SSH servers when you ssh to other places. This lets you type your password once per session instead of over and over again.

I fetch my email through an "SSH tunnel", which means that my email password is encrypted by SSH instead of being sent unencrypted to the email server. This makes it harder for someone to sniff my password en route. Typing my password each time I check my email is a pain, so I set up the ssh-agent system. See for how to tunnel a POP email connection through SSH.

The general principals of setting up ssh-agent can be found at . But, the specific instructions there didn't quite work for me.

I had lots of trouble setting up ssh-agent. The crux of the problem turned out to be that different computers have different ssh installations which seem similar to the user but which actually require different configuration options (and hwich don't make this clear enough, or easy enough to follow, in the manpage).

I run Debian GNU/Linux. The SSH stuff in Debian is a brand known as OpenSSH?. But I get my email from a server which identifies its SSH program as " SSH Secure Shell (non-commercial)", which is produced by a different organization known as "SSH Communications Security Corp".

There are two phases to setting up ssh-agent;

I. You generate security keys for your agent, and tell the remote server that you authorize your agent to login using its security key (rather than a password). This involves the ssh-keygen program, sending files to the remote server, and in my case also editing a bunch of files.

II. Authenticate yourself locally to your ssh-agent program, and then allow it to handle authentication for everything else.

Phase 1

The webpage describes what the setup has to be in my situation (i.e. when you have OpenSSH? but the server has an SSH Communications Security Corp version). But, in short, here's how I did it (replace "REMOTE.SERVER.COM" with your remote server's address).

ssh-keygen -t dsa # generate the security keys; use the default path # when it asks ssh-keygen -e -f /home/bshanks/.ssh/id_dsa

ssh REMOTE.SERVER.COM 'cat - >> ~/.ssh2/authorized_keys2'
  1. the ssh-keygen -e command converts the key from
  2. OpenSSH? format to a format used by
  3. SSH Communications Security Corp.
  4. The stuff after the pipe sends this
  5. to the remote server, and appends it to the file
  6. ~/.ssh2/authorized_keys2. echo Key authorized_keys2
ssh REMOTE.SERVER.COM 'cat - > ~/.ssh2/authorization'
  1. create a file on the remote server at
  2. ~/.ssh2/authorization, which contains the text
  3. 'Key authorized_keys2'

At this point, you should test your installation;


should log you into the remote server after asking for your passphrase, rather than your password (if you want, you could make your passphrase empty, in which case it won't ask you for anything; but this means that anyone who hacks into your local machine will be able to login as you on the remote machine without any further effort).

why this was confusing

The two types of SSH can interoperate, but there are subtle differences. Unfortunately the methods of configuring each one are similar enough that it took me awhile to figure out that there were any differences at all. In addition, when I logged onto the server and did "man sshd", and also looked in "/etc/ssh/", I got confusing information; the server has man pages and config files for both sshd and sshd2, but the sshd2 ones are the relevant ones, at least in my case. Unfortunately, once I saw the "sshd" stuff, I stopped looking, and never realized that there was also "sshd2" (until after I had fixed the problem).

cat .ssh/

ssh user@server "cat - >> .ssh/authorized_keys"

(thanks to