OpenSSH server

OpenSSH is a powerful collection of tools for remotely controlling networked computers and transferring data between them. Here we’ll describe some of the configuration settings possible with the OpenSSH server application and how to change them on your Ubuntu system.

OpenSSH is a freely available version of the Secure Shell (SSH) protocol family of tools. Traditional tools, such as telnet or rcp, are insecure and transmit the user’s password in cleartext when used. OpenSSH provides a server daemon and client tools to facilitate secure, encrypted, remote control and file transfer operations, effectively replacing the legacy tools.

The OpenSSH server component, sshd, listens continuously for client connections from any of the client tools. When a connection request occurs, sshd sets up the correct connection depending on the type of client tool connecting. For example, if the remote computer is connecting with the SSH client application, the OpenSSH server sets up a remote control session after authentication. If a remote user connects to an OpenSSH server with scp, the OpenSSH server daemon initiates a secure copy of files between the server and client after authentication.

OpenSSH can use many authentication methods, including plain password, public key cryptography, and Kerberos tickets.

Install OpenSSH

To install the OpenSSH client applications on your Ubuntu system, use this command at a terminal prompt:

sudo apt install openssh-client

To install the OpenSSH server application, and related support files, use this command at a terminal prompt:

sudo apt install openssh-server

Configure OpenSSH

To configure the default behavior of the OpenSSH server application, sshd, you can modify the main configuration file at /etc/ssh/sshd_config or add modular configuration snippets to the /etc/ssh/sshd_config.d/ directory.

Important

By default, Ubuntu’s configuration includes the line Include /etc/ssh/sshd_config.d/*.conf at the very top of /etc/ssh/sshd_config. Because OpenSSH uses the first value set for most directives, any settings defined in files within sshd_config.d/ will override those in the main configuration file.

Using snippets in sshd_config.d/ makes updates easier and keeps your custom changes separate from system defaults.

For information about the configuration directives, refer to the online sshd_config(5) manual page or run man sshd_config at a terminal prompt.

Example configuration directive

Let’s take a look at an example of a configuration directive change. To make your OpenSSH server display the contents of the /etc/issue.net file as a pre-login banner, you can add or modify this line in the /etc/ssh/sshd_config or in a snippet file in /etc/ssh/sshd_config.d/:

Banner /etc/issue.net

Since losing an SSH server might mean losing your way to reach a server, check the configuration after changing it and before restarting the server:

sudo sshd -t

After making changes to the configuration, save the file. Then, restart the sshd server application to effect the changes using the following command:

sudo systemctl restart ssh.service

Warning

Many other configuration directives for sshd are available to change the server application’s behavior to fit your needs. Be advised, however, if your only method of access to a server is SSH, and you make a mistake when configuring sshd you may find you are locked out of the server upon restarting it. Additionally, if an incorrect configuration directive is supplied, the sshd server may refuse to start, so be particularly careful when editing the configuration on a remote server.

Tip

You can use etckeeper to track changes in your /etc/ with git.

Alternatively, before editing the configuration file, you should make a copy of the original /etc/ssh/sshd_config file and protect it from writing so you will have the original settings as a reference and to reuse as necessary. You can do this with the following commands:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
sudo chmod a-w /etc/ssh/sshd_config.original

SSH keys

SSH allows authentication between two hosts without the need of a password, using cryptographic keys instead. SSH-key authentication uses a private key and a public key.

We recommend the ed25519 Elliptic Curve algorithm (-t ed25519) due to shorter key size and lower computational requirements. Alternatively, you can create a key using the RSA Algorithm (-t rsa -b 4096, for 4096 bit key size) instead.

To generate a key pair, run the following command:

ssh-keygen -t ed25519

During creation, you will be prompted for a key passphrase, which you would enter to use that key (every time, or instead using an ssh-agent(1).

By default, the public key is saved in the file ~/.ssh/id_<algorithm>.pub, while ~/.ssh/id_<algorithm> is the private key. To allow login for a user via key, append the content of id_ed25519.pub (id_rsa.pub for RSA) to target_machine:~/.ssh/authorized_keys by running:

ssh-copy-id username@target_machine

Finally, double check the permissions on the authorized_keys file – only the authenticated user must have write permissions. If the permissions are not correct then change them by:

chmod go-w .ssh/authorized_keys

You should now be able to SSH to the target_machine without being prompted for a password.

To troubleshoot this, have a look at the target_machine’s live logs of ssh.service:

sudo journalctl -fu ssh.service

Since you can have multiple SSH-keys, you can configure which to use for which target machine in ~/.ssh/config (see ssh_config(5)).

Connection multiplexing

To reduce connection setup times, multiple SSH sessions to the same target_machine can reuse the same TCP connection.

Configuration to activate multiplexing in ~/.ssh/config:

ControlMaster auto
ControlPath %d/.ssh/ssh_mux_%u@%l_%r@%h:%p

Optionally, if you want the session to still be re-usable 1 second after disconnecting, set:

ControlPersist 1

Import keys from public keyservers

These days many users have already SSH keys registered with services like Launchpad or GitHub. Those can be imported with:

ssh-import-id <username-on-remote-service>

The prefix lp: is implied and means fetching from Launchpad. The alternative gh: will make the tool fetch from GitHub instead.

Two factor authentication

You can add an extra layer of security to the default key-based authentication using two factor authentication. You can add two factor authentication using U2F/FIDO hardware authentication devices. Alternatively, in cases U2F/FIDO hardware authentication devices are unavailable or impractical for your use case you can add it using HMAC/Time based One Time Passwords (HOTP/TOTP).

Handling unstable connections

When working on remote systems via SSH, unstable network connections or accidental disconnects can interrupt your work and terminate running processes. Terminal multiplexers solve this problem by allowing sessions to persist even after disconnection.

Using a terminal multiplexer like tmux or screen, you can start a session on the remote machine that continues running independently of your SSH connection. If your connection drops, you can reconnect and reattach to your existing session, resuming your work exactly where you left off without losing any running processes or command output.

Further reading

• Ubuntu Wiki SSH page.

• OpenSSH Website

• Advanced OpenSSH Wiki Page

• 2FA with TOTP/HOTP
  • Background
  • Install required software
  • Configure users
    • Configure users’ key-based authentication
    • Configure users’ TOTP/HOTP 2FA secrets
  • Configure the SSH server
  • Log in using 2FA
  • Special cases
  • Further reading
• 2FA with U2F/FIDO
  • Example with U2F
  • FIDO2 resident keys
  • Further reading