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).
- Backups with rsync and SSH.
- Concurrent Versions System (CVS) & SSH.
- The Config::OpenSSH::Authkey Perl module offers a programatic interface to the OpenSSH authorized_keys file.
- Running OpenSSH on a custom port. That is, on a port that is not 22.
- Distributing a global ssh_known_hosts file with CFEngine.
- Forwarding Connections with SSH.
- Key Rotation - how and why to periodically rotate SSH public keys.
- module:authkey - OpenSSH public key management module for CFEngine.
- OpenSSH Public Key Authentication Setup and details on the optional public key comment field.
- Using pam_tally to limit brute force SSH attacks.
- [RFC 4716] - “The Secure Shell (SSH) Public Key File Format” - use the -e option to ssh-keygen(1) to convert OpenSSH keys to this format.
- Mac OS X 10.6 calls SSH “Remote Login” under the Sharing PreferencePane, if one is looking to enable SSH access on Mac OS.
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.
- X11 not set to be forwarded.
- Manual DISPLAY setup.
- X11 forwarding disabled in sshd_config.
- Under modern versions of OpenSSH, certain programs may need the -Y argument to ssh or the ForwardX11Trusted option enabled. See ssh_config(5) for details.
OpenSSH may read an unexpected preferences entry for the server in question. Consult the various OpenSSH configuration files. To manually enable forwarding for testing to see whether a local configuration option is disabling X11 forwarding, use the -X option to ssh.
client$ ssh -X server.example.org
The DISPLAY environment variable might have been overwritten by a shell initialization file. This is often the case where sites have used insecure X11 in the past, in which case DISPLAY may contain a specific hostname instead of the special localhost entry created dynamically by OpenSSH.
X11 forwarding may have been disabled in the server configuration. Contact the administrator of the server in question, as they should be able to review or change the setting.
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
