OpenSSH Documentation & Tips

Usage Tips | Different Login Names | Killing Connections | X11 Forwarding | authorized_keys2 deprecated

Documentation and tips on the OpenSSH implementation of the Secure Shell (SSH) protocol. Never allow root-to-root trust between systems. If required by poorly engineered legacy scripts, limit the from access of the public keys, and if possible only allow specific public keys to run specific commands. Instead, setup named accounts for users or roles, and grant as little root access as possible via sudo.

Also note that while OpenSSH may rely on various cryptographic routines from the OpenSSL library, SSH is a completely different protocol than TLS (SSL).

SSH protocol 1 is now disabled by default in OpenSSH 5.5?huzzah! Migrate away from SSHv1 keys as soon as possible, if they are still in use somewhere!

Usage Tips

Systems connected to frequently should have short names. I use gh to login to my home server, and gw to the most common bastion system at work. These are zsh shell functions:

function gh {
ssh server.example.org $@
if [ -t 1 ]; then
print -Pn "\e]2;\a"
clear
stty sane
fi
}

This allows quick logins (three keystrokes), and also shortens ssh commands involving the home server:

$ gh
server$ exit

$ cat ~/.ssh/*.pub | gh 'cat >> .ssh/authorized_keys'

To aid scp, also use these abbreviations in ~/.ssh/config:

Host server.example.org server gh
Hostname server.example.org
ForwardAgent no
ForwardX11 no
Protocol 2
StrictHostKeyChecking yes

Which allows scp commands to be shortened from server to just gh:

$ scp somefile server:someotherfile
$ scp somefile gh:someotherfile

Different Login Names

If the login name is different on a server, place an entry for the server into the ~/.ssh/config file on the client system to use the proper username on the server. This avoids the need to type the username each time when logging in to the server. If the server has different names, for instance a fully qualified name and a short hostname, list all these variations that might be typed for the Host statement to ensure the proper username on the server is used in all cases.

Host server.example.com server
User username

Killing Connections

To kill an open SSH connection, send the ssh process a HUP signal on the client system.

$ ps | grep ssh
11133 p1 S+ 0:00.41 ssh server.example.org
12140 p5 S+ 0:00.21 ssh server.example.org
$ kill -HUP 11133

X11 Forwarding

If X11 applications need to be run on remote systems, then X11 forwarding will need to be enabled. The change can either be done system-wide for all users in the global ssh_config file (usually found in /etc/ssh or /etc), or on a per-user basis in the ~/.ssh/config file. For more information, see ssh_config(5).

X11 should not be forwarded to untrusted systems. To enable X11 forwarding to only hosts under example.org, add the following to an OpenSSH config file such as ~/.ssh/config.

Host *.example.org
ForwardX11 yes

Host *
ForwardX11 no

To test X11 forwarding, login to the remote server, and see whether the DISPLAY environment variable is set properly to the localhost loopback interface. If set properly, run a X11 application to confirm that things work.

client$ ssh server.example.org

server$ echo $DISPLAY
localhost:10.0
server$ xterm

If the DISPLAY variable is not set, or is set to something else, the problem could come from many different sources, or a combination of things that will need to be fixed.

authorized_keys2 deprecated

The authorized_keys2 file has been deprecated since the OpenSSH 3.0 release (2001). Merge any keys in the authorized_keys2 file into authorized_keys:

$ cd ~/.ssh
$ cat authorized_keys2 >> authorized_keys
$ rm authorized_keys2