A passphrase is a password that unlocks the generated key. Think of it as a master password. It may be blank, but we suggest only making it blank if you have other security measures (one of those is detailed below).

$> ssh-keygen -t rsa
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): (enter passphrase)
Enter same passphrase again: (enter passphrase)
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
2c:3f:a4:be:46:23:47:19:f7:dc:74:9b:69:24:4a:44 user@mydesktop

$> cat .ssh/id_rsa.pub | ssh user@server "cat - >> .ssh/authorized_keys"

All that does is append your public key to the server's list of authorized keys (for just your account on that server).

You can limit the power of keys torun certain commands, to only connect from certain hosts, and disallow things like port forwarding, X forwarding, etc.

Concrete example:

I use a restricted ssh key to run fetchmail. My mailhome is baobab.cc.gatech.edu, and I've set up a special entry in my .ssh/config for email checking:

Host email
Hostname baobab.cc.gatech.edu
User davidhi
IdentityFile ~/.ssh/mail_check
LogLevel QUIET

The mail_check key is a special password-less key. In my authorized_keys file, I have the following prepended before the public key:

command="/usr/sbin/imapd",no-X11-forwarding,no-port-forwarding, no-agent-forwarding,no-pty ssh-dss A...

This restricts connections made via the key to only running imapd and disallows X11 forwarding, port forwarding, agent forwarding and pty access. This means that the password-less key is locked down (assuming imapd is not compromised) [0].

List of things:

• no-agent-forwarding
• no-port-forwarding
• no-pty
• no-X11-forwarding
• command="command"
• environment="NAME=value"
• from="pattern-list"
• permitopen="host:port"
• tunnel="n"

Notes:

• 'command' sets a command to run. Adding no-pty makes the command 8-bit clean for two way data transfer. In command, one can use $SSH_ORIGINAL_COMMAND to refer to the command the user wants to execute. Using the shell expression "${SSH_ORIGINAL_COMMAND:-}" handles the case in which no command is specified gracefully [1].

• 'environment' modifies the environment variables.

• 'from' restricts based on the remote host (see ssh patterns).

• 'permitopen' allows -L forwarding for specified host/port combinations only.

• 'tunnel' sets up VPN tunnels.

[0] Not sure of the original source of this since I've been using it since at least 2003. This might be it, though:
    http://mah.everybody.org/docs/mail/fetchmail_check
[1] Hint from: http://www.oreilly.com/catalog/sshtdg/chapter/ch11.html

Sometimes your distribution's X server will start up the agent automatically. If it doesn't, you can either start it automatically each time, or better, you can add it yourself to an X startup script. The details of which depends on your environment. For Gnome, I would put this in /etc/X11/gdm/PreSession/Default.

$> eval `ssh-agent -s`

This will start up the agent, and set some environment variables which ssh will later use to connect to this agent.

Before things will start working, you must add your key(s) to the agent. You can do this automatically when you login to Gnome by adding it to your Gnome session (Startup Programs).

$> ssh-add

That's it! By default it will add .ssh/id_rsa and .ssh/id_dsa, which are the most popular key filenames. If you have a custom key, just suffix the name of the key to that command. If your passphrase is not blank, it will prompt you for the passphrase, but this will be the only time you have to enter it (until the agent stops or you manually remove the identity from the agent). Confirm that the agent has the key by running:

$> ssh-add -l

Let's say there is a network you have access to, but services on that network can only be seen while you're on the network. For example, there is an internal website running on webhost . You can't access it from a web browser at home but would like to. This is what ssh port forwarding is for!

$> ssh -L 80:webhost:80 webhost

This will bind the local port 80 (the first 80) to a tunnel, with the other end pointing to port 80 (the 2nd 80) of the webhost. You may then access the website by pointing your browser to http://localhost. However, in the case of websites, apache won't respond to localhost, but (for example) intranet (due to vhosts). You would then need to either edit /etc/hosts and append intranet to the "127.0.0.1 localhost" line or if you manage internal DNS, create an A record.

Both hosts need not be the same. Sometimes you can't directly login to the server -- like a mailserver. You can actually ssh into a server you can login to via a shell instead, as long as that server has access to (on the same network as) the server you're forwarding to.

$> ssh -L 9999:mailserver:110 shellserver -N -f

After that, you can setup your mail app to use localhost:9999 instead.

Also, as illustrated in the last example, you may use -N -f:

• -N tells the client not to execute anything remotely
• -f tells ssh to background

Thanks to SecurityFocus.com .

The classic example of using a Remote Forward goes something like this. You're at work, and the VPN access is going to be down for maintenance for the weekend. However you really have some important work to do, but you'd rather work from the comfort of your desk at home, rather than being stuck at work all weekend. There's no way for you to SSH to your work desktop because it's behind the firewall.

Before you leave for the evening, you SSH from your work desktop back to your home network.

.ssh/config:

Host home-with-tunnel
Hostname benmcmillan.com
RemoteForward 2222:localhost:22
User ben

Then you just ssh to 'home-with-tunnel'! When you get home, ssh into localhost over port 2222 (using the -p option). Take note this also illustrates the ability to setup forwards using your config file. Even more convenience! Yay!