9.2. Remoteanmeldung

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.

WÖRTERVERZEICHNIS Authentifizierung, Verschlüsselung

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

Authentifizierung und Verschlüsselung werden häufig zusammen genannt, weil beide oft gleichzeitig benutzt werden, und weil sie gewöhnlich durch ähnliche mathematische Konzepte umgesetzt werden.

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 ist ein interaktiver Befehl, ähnlich wie ftp. In einer einzigen Sitzung kann sftp mehrere Dateien übertragen, und es ist möglich, mit ihm Dateien auf einem entfernten Rechner zu bearbeiten (löschen, umbenennen, Berechtigungen ändern usw.).

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.

ZURÜCK ZU DEN GRUNDLAGEN Fork

Ein „Fork“ im Softwarebereich ist ein neues Vorhaben, das als Klon eines bestehenden Vorhabens beginnt und mit ihm konkurriert. Von da an entwickeln sich beide Programme, was neue Entwicklungen angeht, gewöhnlich schnell auseinander. Ein Fork ist häufig die Folge von Meinungsverschiedenheiten innerhalb des Entwicklungsteams.

Die Option, ein Vorhaben zu forken, ist eine direkte Folge der Eigenart freier Software; ein Fork ist ein heilsamer Vorgang, wenn sie die Fortführung eines Vorhabens als freie Software ermöglicht (zum Beispiel im Falle von Lizenzänderungen). Dagegen ist ein Fork, der sich aus technischen oder persönlichen Meinungsverschiedenheiten ergibt, häufig eine Verschwendung menschlicher Ressourcen; eine andere Lösung wäre vorzuziehen. Auch der Zusammenschluss zweier Vorhaben, die früher durch einen Fork gegangen sind, ist nicht gänzlich unbekannt.

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).

SICHERHEIT Schutz des privaten Schlüssels

Wer im Besitz des privaten Schlüssels ist, kann sich mit dem entsprechend konfigurierten Konto anmelden. Daher ist der Zugriff auf den privaten Schlüssel durch eine „Passphrase“ geschützt. Selbst wenn jemand in den Besitz eines privaten Schlüssels gelangt (zum Beispiel die Datei ~/.ssh/id_rsa), muss er zusätzlich noch diese Phrase kennen, um ihn verwenden zu können. Dieser zusätzliche Schutz ist jedoch nicht unüberwindlich, und wenn Sie denken, dass die Sicherheit dieser Datei nicht mehr gewährleistet ist, sollten Sie diesen Schlüssel auf den Rechnern, auf denen er installiert wurde, deaktivieren (indem Sie ihn aus authorized_keys entfernen) und durch einen neu erzeugten Schlüssel ersetzen.

KULTUR OpenSSL-Schwachstelle in Debian Etch

Die OpenSSL-Bibliothek, die ursprünglich mit Debian Etch bereitgestellt wurde, hatte ein gravierendes Problem in ihrem Zufallszahlengenerator (RNG). In der Tat hatte der zuständige Debian-Betreuer eine Änderung vorgenommen, damit Anwendungen, die ihn verwenden, keine Warnmeldungen mehr verursachen, wenn sie von Werkzeugen für das Memory Management wie zum Beispiel valgrind analysiert werden. Leider hatte diese Änderung auch zur Folge, dass der Zufallszahlengenerator nur eine Entropie-Quelle in Abhängigkeit von der Prozesskennung (PID) benutzte, deren 32.000 mögliche Werte keinen ausreichenden Grad an Zufälligkeit boten.

→ https://www.debian.org/security/2008/dsa-1571

Insbesondere, wenn OpenSSL benutzt wurde, um einen Schlüssel zu erzeugen, wurde dieser immer aus einem Satz einiger hunderttausend Schlüssel erstellt (32.000 multipliziert mit einer kleinen Zahl von Schlüssellängen). Hiervon waren SSH-Schlüssel, SSL-Schlüssel und von zahlreichen Anwendungen, wie zum Beispiel OpenVPN, verwendete X.509-Zertifikate betroffen. Ein Eindringling brauchte nur alle Schlüssel auszuprobieren, um unberechtigten Zugriff zu erlangen. Um die Auswirkung des Problems einzuschränken, wurde der SSH-Daemon dahingehend verändert, dass er zweifelhafte Schlüssel, die in den Paketen openssh-blacklist und openssh-blacklist-extra aufgelistet sind, zurückweist. Darüber hinaus ermöglicht es der Befehl ssh-vulnkey, möglicherweise gefährdete Schlüssel im System zu identifizieren.

Eine gründlichere Analyse dieses Vorfalls zeigt, dass er das Ergebnis mehrerer (kleiner) Probleme ist, sowohl innerhalb des OpenSSL-Projekts als auch mit dem Debian-Paketbetreuer. Eine weit verbreitete Bibliothek wie OpenSSL sollte - ohne Änderungen - keine Warnungen erzeugen, wenn sie mit valgrind getestet wird. Außerdem sollte der Code (insbesondere die so empfindlichen Teile wie der RNG) besser kommentiert werden, um solche Fehler zu vermeiden. Auf Debians Seite wollte der Betreuer die Änderungen mit den OpenSSL-Entwicklern validieren, erklärte aber einfach die Änderungen, ohne den entsprechenden Patch zur Verfügung zu stellen, und versäumte es, seine Rolle in Debian zu erwähnen. Schließlich waren die Wartungsoptionen suboptimal: die Änderungen am Originalcode wurden nicht eindeutig dokumentiert; alle Änderungen wurden effektiv in einem Subversion-Repository gespeichert, aber sie endeten alle in einem einzigen Patch während der Erstellung des Quellpakets.

Es ist unter diesen Umständen schwierig, Korrekturmaßnahmen zu finden, die solche Vorfälle in Zukunft verhindern. Die Lehre, die hieraus gezogen werden kann, ist, dass jede Abweichung, die Debian in Ursprungssoftware einführt, begründet, dokumentiert, möglichst dem Ursprungsprojekt vorgelegt und verbreitet veröffentlicht werden muss. Unter diesem Gesichtspunkt wurden das neue Quellpaket-Format („3.0 (quilt)“) und die Debian Quellen Webseite entwickelt.

→ https://sources.debian.org

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. Entfernte X11-Anwendungen benutzen

Das SSH-Protokoll ermöglicht die Weiterleitung grafischer Daten („X11“-Sitzung, nach dem Namen des am weitesten verbreiteten grafischen Systems in Unix); der Server stellt hierbei einen besonderen Kanal für diese Daten bereit. Konkret bedeutet dies, dass ein aus der Ferne ausgeführtes, grafisches Programm vom X.org-Server auf dem lokalen Bildschirm dargestellt werden kann, und dass die gesamte Sitzung (Eingabe und Anzeige) abgesichert ist. Da entfernte Anwendungen durch diese Funktion das lokale System beeinträchtigen können, ist sie standardmäßig deaktiviert. Sie kann aktiviert werden, indem man in der Serverkonfigurationsdatei (/etc/ssh/sshd_config) die Option X11Forwarding yes einstellt. Schließlich muss der Benutzer diese Funktion anfordern, indem er die Option -X zur Befehlszeile ssh hinzufügt.

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

9.2.1.4. 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.

WÖRTERVERZEICHNIS Tunnel

Das Internet und die meisten mit ihm verbundenen LANs arbeiten im Paket-Modus und nicht in einem fest geschalteten Modus. Das heißt, dass ein Paket, das von einem Rechner zu einem anderen verschickt wird, auf dem Weg zu seinem Ziel an mehreren dazwischenliegenden Routern angehalten wird. Dennoch kann man einen fest geschalteten Betrieb nachahmen, indem der Datenstrom in normale IP-Pakete eingeschlossen wird. Diese Pakete laufen über ihren üblichen Weg, jedoch wird der Datenstrom am Ziel dann unverändert rekonstruiert. Man nennt dies einen „Tunnel“ in Analogie zu einem Straßentunnel, bei dem Fahrzeuge direkt vom Eingang (Eingabe) zum Ausgang (Ausgabe) fahren, ohne auf irgendwelche Kreuzungen zu stoßen, im Gegensatz zu einem Weg an der Oberfläche, bei dem es Kreuzungen und Richtungswechsel gibt.

Man kann bei dieser Gelegenheit den Tunnel verschlüsseln: der Datenstrom, der durch ihn hindurchläuft, ist dann von außen unkenntlich, wird aber am Tunnelausgang wieder in eine unverschlüsselte Form zurückgeführt.

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.

Abbildung 9.3. Einen lokalen Port mit SSH weiterleiten

Abbildung 9.4. Einen entfernten Port mit SSH weiterleiten

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 Settings → Sharing (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 K → Internet → Remote 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.

SICHERHEIT VNC über SSH

Falls Sie über VNC eine Verbindung herstellen, Ihre Daten aber nicht im Klartext über das Netzwerk schicken wollen, können Sie sie in einem SSH-Tunnel verbergen (siehe Abschnitt 9.2.1.4, „Verschlüsselte Tunnel mit Port-Weiterleitung einrichten“). Sie müssen nur wissen, dass VNC standardmäßig den Port 5900 für den ersten Bildschirm („localhost:0“ genannt), 5901 für den zweiten („localhost:1“ genannt) usw. verwendet.

Der Befehl ssh -L localhost:5901:localhost:5900 -N -T rechner erstellt einen Tunnel zwischen dem lokalen Port 5901 in der localhost-Schnittstelle und Port 5900 auf dem Host rechner. Das erste „localhost“ beschränkt SSH darauf, nur an dieser Schnittstelle des lokalen Rechners auf Anfragen zu warten. Das zweite „localhost“ bezeichnet die Schnittstelle des entfernten Rechners, die den Netzverkehr entgegennehmen wird, der in „localhost:5901“ eintritt. Auf diese Weise verbindet vncviewer localhost:1 den VNC-Client mit dem entfernten Bildschirm, obwohl Sie den Namen des lokalen Rechners angeben.

Wenn die VNC-Sitzung beendet ist, vergessen Sie nicht, den Tunnel zu schließen, indem Sie auch die entsprechende SSH-Sitzung beenden.