SSH logins are part of everyday life for most admins. The continuously developed program offers a lot of possibilities that not everybody knows.
1. public key authentication instead of passwords
In general, it is recommended to use asymmetric key pairs instead of password authentication. The private key is stored securely on the client, while the public key is copied to the server. Additional security is provided by securing the private key with a password or passphrase – this is therefore also the default setting. However, if you want to send commands via SSH using scripts, you will usually use asymmetric keys without a passphrase. A new key is created by calling “ssh-keygen”.
RSA keys with large key lengths (>=2048 bit) are recommended today. DSA keys have fallen into disrepute, not least because of Edward Snowden, and are considered deprecated in new SSH versions. Alternatives are ECDSA (Elliptic Curves) and EdDSA (Ed25519), which are not compatible with older SSH versions. ECDSA is also suspected by paranoiacs to be manipulated by NSA, so Ed25519 is the safe choice in case of doubt.
2. secure SSH and prevent brute force attacks
If password authentication is allowed, attackers can try brute force attacks, i.e. simply try user names and passwords at SSH login. Against this, the first tip or a program like fail2ban or SSHGuard, which monitor the SSH log and block further logins if attempts via firewall fail, helps. A disadvantage of such programs is that you might lock yourself out. But this can usually be prevented by a reasonable configuration.
Another security tip is to disable the root login (“PermitRootLogin no” in “/etc/ssh/sshd_config”). Of course, this is not possible if you need root privileges for backups on the remote computer (and setting up passwordless sudo there does not help with security).
It is also recommended to disable insecure algorithms via configuration (“Ciphers” in “/etc/ssh/sshd_config”) – possibly at the expense of compatibility.
Finally, depending on the application, it is also possible to limit the radius of action of an SSH user. By default, you can do this with the configuration file “authorized_keys” to allow only a certain command (keyword: backup). However, this is not necessarily foolproof if it is a script or a faulty program. Alternatives may be a chroot or jailkit.
In version 5.9 of OpenSSH, a sandbox mechanism was also introduced, but it is unlikely to have been used in practice.
3. copy public keys to server
If you have generated your key pair as described in 1., you first have to copy the public key to the server to log in. This can easily be done with the scp command, but then you have to take care that the key is moved to the correct file on the server (“~/.ssh/authorized_keys”) and that the rights are correct. It is easier to do this with the tool “ssh-copy-id”, which takes over these steps.
4. use SSH-Agent
To avoid having to enter the password repeatedly for a password-protected key pair, you can use the SSH agent. It stores the decrypted key in memory and uses it for all further login processes. The GnuPG agent also masters the SSH protocol and can take over this task (if you are already using it anyway). Various distributions have integrated the agent password management into the desktop. For example, the SSH agent starts the Session Manager and inherits access to all other running processes via the system variables. Systemd can also be used to start an SSH agent for a user.
The connection to the SSH agent can be forwarded to another computer (“ssh -A”) so that the local keys are also available on the remote computer. However, this poses a security risk, since attackers who gain control of the remote machine can also gain access to the forwarded (but not stored) keys.
5. data exchange with scp and sshfs
SSH is suitable not only for remote login to a computer, but also for copying files over a secure channel. For this purpose, the package offers the secure copy program scp. Similar to NFS, whole directories can be mounted locally by using sshfs, which was based on the FUSE module of Linux (filesystem in userspace). There are also sshfs implementations for Mac and Windows.
6. host entries
In the file “~/.ssh/config” you can enter a separate configuration for each host and thus save typing work, for example. For example, the following entry specifies that the alias “www” is expanded to “www.admin-magazin.de”.
Also, ssh uses the username “webmaster” instead of the local username by default. You can also specify certain algorithms and key types there, for example if the remote computer uses old software and does not support all modern implementations:
7. more security with two-factor authentication (F2A)
You can secure the SSH logins even better if you use a second “factor” in addition to the key. This could be a TOTP token, for example, which you generate with your smartphone. The Google Authenticator has proven itself here, and its use in combination with SSH is described in more detail here. If you do not trust Google, you can use FreeOTP instead, which offers the same functionality. Alternatively you can use a hardware security module like the Yubikey.
8. faster login with multiplexing
Relatively much time is spent on handshake and key exchange each time you log in. You can reduce this overhead by using SSH in multiplexing mode. You can read more about this in our ADMIN tip “Log in faster with SSH multiplexing”. The multiplexing feature also allows you to use SSH call in scripts while keeping control over the processes.
9. ssh tunneling
SSH can not only be used to connect to a single other machine, but it can also forward TCP connections. For one thing, local ports can be forwarded to a remote computer (remote port forwarding), for example to make a computer behind a firewall accessible “from outside” (obviously this is a security risk and should always be done with common sense):
ssh -N -R 2222:localhost:22 remote.server.com
This makes the local SSH login port on the computer remote.server.de available under port 2222. By default, it is only bound to the localhost address, which provides at least a bit more security (but this can be changed by configuration).
Local Port Forwarding gets a port from another computer to the local computer. For example, MySQL replication can be set up via SSH, even if the remote MySQL server does not make its port accessible to the outside. The corresponding call is like this:
ssh -L 33061:localhost:3306 remote.server.com
Now you can reach the remote MySQL server on the local port 33061. Other ways to connect over multiple hosts are dynamic port forwarding with SOCKS and bridging hosts with Jump Hosts (from OpenSSH 7.3 on via configuration statement ProxyJump).
10. making connections with AutoSSH more stable
To ensure that SSH connections are maintained even when inactive, you can experiment with some of the parameters the program offers, such as ServerAliveInterval or ServerAliveCountMax. More reliable, however, is the AutoSSH utility, which you use in the same way as SSH (at least with the basic options for normal logins or tunnels) and which reestablishes the connection if necessary.