--- myst: html_meta: description: Install and configure OpenSSH server on Ubuntu for secure remote access, encrypted file transfers, and authentication methods. --- (openssh-server)= # 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: ```bash sudo apt install openssh-client ``` To install the OpenSSH server application, and related support files, use this command at a terminal prompt: ```bash 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 {manpage}`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/`: ```text 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: ```bash 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: ```bash 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 {ref}`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: ```bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original sudo chmod a-w /etc/ssh/sshd_config.original ``` ```` (openssh-server-ssh-keys)= ## SSH keys SSH allows authentication between two hosts without the need of a password, using cryptographic keys instead. {term}`SSH-key` authentication uses a **private key** and a **public key**. We recommend the [**ed25519 Elliptic Curve algorithm**](https://ed25519.cr.yp.to/) (`-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: ```bash 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 {manpage}`ssh-agent(1)`. By default, the public key is saved in the file `~/.ssh/id_.pub`, while `~/.ssh/id_` 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: ```bash 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: ```bash 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`: ```bash sudo journalctl -fu ssh.service ``` Since you can have multiple {term}`SSH-key`s, you can configure which to use for which target machine in `~/.ssh/config` (see {manpage}`ssh_config(5)`). ## Connection multiplexing To reduce connection setup times, multiple SSH sessions to the same `target_machine` can reuse the same {term}`TCP` connection. Configuration to activate multiplexing in `~/.ssh/config`: ```text 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: ```text 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: ```bash ssh-import-id ``` 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 {ref}`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 {ref}`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 {ref}`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](https://help.ubuntu.com/community/SSH) page. - [OpenSSH Website](http://www.openssh.org/) - [Advanced OpenSSH Wiki Page](https://wiki.ubuntu.com/AdvancedOpenSSH) ```{toctree} 2FA with TOTP/HOTP 2FA with U2F/FIDO ```