Product SiteDocumentation Site

9.2. Remote Login

It is essential for an administrator to be able to connect to a computer remotely. Servers, confined in their own room, are rarely equipped with permanent keyboards and monitors — but they are connected to the network.

9.2.1. Secure Remote Login: SSH

The SSH (Secure SHell) protocol was designed with security and reliability in mind. Connections using SSH are secure: the partner is authenticated and all data exchanges are encrypted.
SSH also offers two file transfer services. scp is a command line tool that can be used like cp, except that any path to another machine is prefixed with the machine's name, followed by a colon.
$ scp file machine:/tmp/
sftp is an interactive command, similar to ftp. In a single session, sftp can transfer several files, and it is possible to manipulate remote files with it (delete, rename, change permissions, etc.).
Debian uses OpenSSH, a free version of SSH maintained by the OpenBSD project (a free operating system based on the BSD kernel, focused on security) and fork of the original SSH software developed by the SSH Communications Security Corp company, of Finland. This company initially developed SSH as free software, but eventually decided to continue its development under a proprietary license. The OpenBSD project then created OpenSSH to maintain a free version of SSH.
OpenSSH is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

9.2.1.1. Key-Based Authentication

Each time someone logs in over SSH, the remote server asks for a password to authenticate the user. This can be problematic if you want to automate a connection, or if you use a tool that requires frequent connections over SSH. This is why SSH offers a key-based authentication system.
The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.
If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Section 10.2.2, “Public Key Infrastructure: easy-rsa) by using the TrustedUserCAKeys and HostCertificate directives in /etc/ssh/sshd_config.
TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).
@cert-authority *.falcot.com ssh-rsa AAAA[..]
Both, public key and certificate authentication, can be used alongside each other.

9.2.1.3. Using Remote X11 Applications

The SSH protocol allows forwarding of graphical data (“X11” session, from the name of the most widespread graphical system in Unix); the server then keeps a dedicated channel for those data. Specifically, a graphical program executed remotely can be displayed on the X.org server of the local screen, and the whole session (input and display) will be secure. Since this feature allows remote applications to interfere with the local system, it is disabled by default. You can enable it by specifying X11Forwarding yes in the server configuration file (/etc/ssh/sshd_config). Finally, the user must also request it by adding the -X option to the ssh command-line.

9.2.1.4. Creating Encrypted Tunnels with Port Forwarding

Its -R and -L options allow ssh to create “encrypted tunnels” between two machines, securely forwarding a local TCP port (see sidebar BACK TO BASICS TCP/UDP) to a remote machine or vice versa.
ssh -L 8000:server:25 intermediary establishes an SSH session with the intermediary host and listens to local port 8000 (see Figure 9.3, “Forwarding a local port with SSH”). For any connection established on this port, ssh will initiate a connection from the intermediary computer to port 25 on the server, and will bind both connections together.
ssh -R 8000:server:25 intermediary also establishes an SSH session to the intermediary computer, but it is on this machine that ssh listens to port 8000 (see Figure 9.4, “Forwarding a remote port with SSH”). Any connection established on this port will cause ssh to open a connection from the local machine on to port 25 of the server, and to bind both connections together.
In both cases, connections are made to port 25 on the server host, which pass through the SSH tunnel established between the local machine and the intermediary machine. In the first case, the entrance to the tunnel is local port 8000, and the data move towards the intermediary machine before being directed to the server on the “public” network. In the second case, the input and output in the tunnel are reversed; the entrance is port 8000 on the intermediary machine, the output is on the local host, and the data are then directed to the server. In practice, the server is usually either the local machine or the intermediary. That way SSH secures the connection from one end to the other.
Forwarding a local port with SSH

Figure 9.3. Forwarding a local port with SSH

Forwarding a remote port with SSH

Figure 9.4. Forwarding a remote port with SSH

9.2.2. Using Remote Graphical Desktops

VNC (Virtual Network Computing) allows remote access to graphical desktops.
This tool is mostly used for technical assistance; the administrator can see the errors that the user is facing, and show them the correct course of action without having to stand by them.
First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via SettingsSharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.
When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at KInternetRemote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.