ssh client

Key Pairs

Ssh key pairs are used for key based authentication. The private key must be kept on the client, never to be given to anyone else than the owner. The public key can be published anywhere, and added to authorized keys lists in order to grant ssh accesses.

• Creating a key pair :

ssh-keygen                        # Default to 2048 bits RSA as of RHEL5
ssh-keygen -t dsa                 # Force to DSA, size is and must be 1024 bits
ssh-keygen -t rsa -b 4096         # Double the default size, theoretically stronger to crack
ssh-keygen -f ~/.ssh/id_rsa_work  # Generate a second parallel key pair

• Updating a key's passphrase :

ssh-keygen -p                        # For the default key
ssh-keygen -p -f ~/.ssh/id_rsa_work  # For a non-default key

Note that a key should always have a passphrase set, unless it's used only for automatic ssh connections (such as ones run from cron jobs). The annoyance of having a passphrase goes away when using an ssh agent.

Ssh Agents

And ssh agent is a small program which is typically launched once during a desktop session and stores private ssh keys in memory after asking only once for each key's passphrase. Ssh clients then contact the agent for key based authentication, which avoids to have to re-enter the passphrase for each new connection.

This makes using passphrase protected keys nearly as convenient as passphrase-less keys, while keeping the main advantage of having passphrase protected keys : If the client system is cracked or stolen, it is not possible for the attacker to get the private key if the system had to be rebooted. This is the case with suspended laptops or workstations which are turned off.

Ssh Agent Forwarding

The most typical use of ssh agent forwarding is to allow to forward key based authentication all the way back to the workstation where the initial ssh connection originated from : If you connect from workstation1 to server1, then from server1 to server2, you can have the key based authentication transparently use the private key present on workstation1 only.

• Enable ssh agent forwarding explicitly for a connection : ssh -A server1
• Disable ssh agent forwarding explicitly for a connection : ssh -a server1
• Configure your defaults to enable ssh agent forwarding for some hosts :

$ cat ~/.ssh/config
Host *.lan server1 server2
    ForwardAgent yes

When using ssh agent forwarding, you should make sure you trust anyone with root access to the systems you are connecting to, as although it's not possible to retrieve the private key directly, it's possible to authenticate against it.

Default Options

All ssh client options can be found in man 5 ssh_config and used from the command line, or in the ~/.ssh/config file (though a different file can be specified with the -F option) or even in the system-wide /etc/ssh/ssh_config configuration file :

• Equivalent commands : ssh -b 10.0.0.1 server1 and ssh -o BindAddress=10.0.0.1 server1
• Example ~/.ssh/config file with useful examples :

# Avoid having to type in "-p 2222" for hosts where sshd is on this non-standard port
Host server3 server4
    Port 2222

# Forward agent and X11 to all our own domains
Host *.lan *.mydomain1 *.mydomain2
    ForwardAgent yes
    ForwardX11 yes

# Don't complain when the localhost key changes, useful when using ssh tunnels
Host localhost
    StrictHostKeyChecking no

Ssh Port Forwarding

Forward Port Forwarding

Forward port forwarding is very useful to reach ports which can't be directly reached from the local system, but can be from a remote system accessible through ssh.

Example where the ssh client will listen on localhost port 8080 and forward all connections through the ssh tunnel, out through the other end towards 192.168.0.1:80 :

ssh -L 8080:192.168.0.1:80 remote-system.domain

This is a typical example where remote-system.domain is a home DSL connection, where the ssh port is redirected to a GNU/Linux machine of the local network, from where the DSL router at address 192.168.0.1 is reachable. The DSL router's web interface will be accessible on http://localhost:8080/ transparently, without it being available to the whole Internet.

Note that the local listening port must be 1024 or higher for non root accounts, and mustn't already be used. This is why 8080 is used in the example instead of 80.

Reverse Port Forwarding

Reverse port forwarding is less used than forward port forwarding, but it also has its usefulness. It allows remote access to the local system, using a remote system accessible through ssh.

Example where the ssh client will listen on remote-system.domain port 2222 and forward all connections back through the ssh tunnel, out to localhost port 22 :

ssh -R 0.0.0.0:2222:127.0.0.1:22 remote-system.domain

This is a typical example where anyone connecting to remote-system.domain port 2222 will transparently be connecting to the system where the ssh client was executed. This can be very useful to enable temporary access to a local system behind NAT or a firewall by using one external system.

Note that if the 0.0.0.0: bind address is omitted, the command will listen on the remote localhost only. We use the 2222 port because it's very likely the remote system already has its own ssh server listening on port 22.

X11 Forwarding

A very powerful and useful feature of ssh is X11 forwarding. The advantages are many : You don't have to mess with $DISPLAY, xauth etc. in order to locally display remote graphical applications, it works with simple NAT situations, and you get it all encrypted, suitable to be executed over the Internet.

Example where we run the revelation graphical password management application on a remote desktop system from our local desktop system. :

ssh -Y remote-system.domain revelation myfile.rev

This makes X11 forwarding very useful for situations where your local system does not fulfill the requirements to run an application, but an available remote system does : Architecture specific binaries, binaries requiring some specific OS revision, etc. Note that this will work well on a fast LAN, but might be a bit slow over the Internet, because of both bandwidth and response time values. You can omit the -Y option is you set the ForwardX11 yes option for the connection.