Es ist für einen Administrator wichtig, sich aus der Ferne mit einem Rechner verbinden zu können. Server, die in ihrem eigenen Raum eingeschlossen sind, werden selten dauerhaft mit Tastaturen und Bildschirmen ausgestattet - aber sie sind mit dem Netzwerk verbunden.
9.2.1. Sicheres Remoteanmelden: SSH
Beim SSH-Protokoll (Secure SHell) wurden Sicherheit und Zuverlässigkeit bereits im Entwurf berücksichtigt. Verbindungen auf der Basis von SSH sind sicher: der Partner ist authentifiziert und jeglicher Datenverkehr erfolgt verschlüsselt.
SSH bietet auch zwei Dateiübertragungsdienste an. scp ist ein Befehlszeilenprogramm, das wie cp benutzt werden kann, nur dass jedem Pfad zu einem anderen Rechner der Name dieses Rechners gefolgt von einem Doppelpunkt vorangestellt wird.
$ 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.). Many FTP clients, including filezilla, support it.
Debian verwendet OpenSSH, eine freie Version von SSH, die vom OpenBSD-Projekt betreut wird (einem freien Betriebssystem, das auf dem BSD-Kernel aufbaut und seinen Schwerpunkt auf Sicherheit setzt) und ist ein Fork der ursprünglich vom finnischen Unternehmen SSH Communications Security Corp. entwickelten SSH-Software. Dieses Unternehmen entwickelte SSH ursprünglich als freie Software, entschied sich jedoch schließlich, seine Entwicklung unter einer proprietären Lizenz fortzusetzen. Das OpenBSD-Projekt schuf daraufhin OpenSSH, um eine freie Version von SSH zu bewahren.
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. Schlüsselbasierte Authentifizierung
Jedes Mal, wenn sich jemand über SSH anmeldet, fragt der entfernte Server nach einem Passwort zur Authentifizierung des Benutzers. Dies kann problematisch sein, wenn man eine Verbindung automatisieren möchte, oder wenn man ein Hilfsprogramm verwendet, das häufige Verbindungen über SSH benötigt. Daher bietet SSH ein schlüsselbasiertes Authentifizierungssystem.
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
Abschnitt 10.2.2, „Public-Key-Infrastrultur: 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. Combining authentication methods
Besides the already mentioned password based, key based, and the certificate based authentication, other methods like using a TOTP exist as well. Not only is this an abundance of options. They can also be combined. On the server side, the AuthenticationMethods directive can define an order of authentication methods a user has to successfully pass, before they are allowed to enter the system. It is even possible to define multiple alternative sequences:
AuthenticationMethods publickey,password publickey,keyboard-interactive:pam
This setting, for example, allows users to login after initially completing the public key authentication, followed by either a successful password authentication or entering a valid TOTP set up via PAM. On the user side, the sequence of methods can be defined using the PreferredAuthentications directive.
9.2.1.4. Entfernte X11-Anwendungen benutzen
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 sshd_config(5) or by prepending the public key with the X11-forwarding keyword in the authorized_keys(5) file. Finally, the user must also request it by adding the -X option to the ssh command-line.
9.2.1.5. Verschlüsselte Tunnel mit Port-Weiterleitung einrichten
Die Optionen
-R und
-L des Befehls
ssh ermöglichen es, „verschlüsselte Tunnel“ zwischen zwei Rechnern zu erstellen, und so einen lokalen TCP-Port (siehe
ZURÜCK ZU DEN GRUNDLAGEN TCP/UDP in der Seitenleiste) sicher an einen entfernten Rechner weiterzuleiten und umgekehrt.
ssh -L 8000:server:25 intermediary eröffnet eine SSH-Sitzung mit dem Host
intermediary und nimmt am lokalen Port 8000 Verbindungen an (siehe
Abbildung 9.3, „Einen lokalen Port mit SSH weiterleiten“). Für jede Verbindung, die zu diesem Port hergestellt wird, baut
ssh eine Verbindung vom Rechner
intermediary zum Port 25 des
server auf und verknüpft beide Verbindungen.
ssh -R 8000:server:25 intermediary eröffnet auch eine SSH-Sitzung zum Rechner
intermediary, aber
ssh nimmt dann auf diesem Rechner an Port 8000 Verbindungen an (siehe
Abbildung 9.4, „Einen entfernten Port mit SSH weiterleiten“). Jede Verbindung, die an diesem Port hergestellt wird, veranlasst
ssh, eine Verbindung vom lokalen Rechner zum Port 25 des
server zu öffnen und beide Verbindungen miteinander zu verknüpfen.
In beiden Fällen werden Verbindungen zu Port 25 auf dem Host server hergestellt, die durch den SSH-Tunnel laufen, der zwischen dem lokalen Rechner und dem Rechner intermediary hergestellt wurde. Im ersten Fall ist der Eingang zum Tunnel der lokale Port 8000, und die Daten laufen zum Rechner intermediary, bevor sie zum server im „öffentlichen“ Netzwerk geleitet werden. Im zweiten Fall sind Ein- und Ausgang im Tunnel vertauscht: der Eingang ist Port 8000 auf dem Rechner intermediary, der Ausgang ist auf dem lokalen Host, und die Daten werden dann zum server geleitet. In der Praxis ist der Server normalerweise entweder der lokale Rechner oder der intermediäre. Auf diese Weise sichert SSH die Verbindung von einem Ende zum anderen.
9.2.2. Entfernte grafische Arbeitsflächen benutzen
VNC (Virtual Network Computing) ermöglicht aus der Ferne Zugriff auf grafische Arbeitsflächen.
Dieses Hilfsprogramm wird vor allem zur technischen Unterstützung eingesetzt; der Administrator kann die Fehler sehen, denen ein Benutzer gegenübersteht, und ihm die richtige Vorgehensweise zeigen, ohne vor Ort sein zu müssen.
First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via → (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 → → ). 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.
