Secure Shell in der Praxis

Secure Shell oder SSH bezeichnet sowohl ein Netzwerkprotokoll als auch entsprechende Programme, mit deren Hilfe man auf eine sichere Art und Weise eine verschlüsselte Netzwerkverbindung mit einem entfernten Gerät herstellen kann.

In der Serverkonfiguration ist die public key basierende Validierung zu aktivieren.

Unterverwendung eines OpenSSH Servers wird dazu in der Datei /etc/ssh/sshd_config folgender Eintrag zugefügt oder aktiviert:

Um zu erlauben X11-Verbindungen weiterzuleiten sind zusätzlich serverseitig folgende Optionen zu aktivieren:

Dabei gibt X11DisplayOffset an, um welchen Wert der der X11-Port der ersten Verbindung vom X11-Basisport 6000 entfernt sein soll, hier also 6000 + 10 = 6010.

In einer sensitiven Umgebung empfiehlt sich X11 generell zu unterbinden und (in ~/.ssh/config) nur dezidierte Verbindungen zuzulassen:

Public Key Authentication dient dazu, sich auf einem anderen Rechner anzumelden, ohne sich jedes Mal mit einem Passwort zu authentifizieren. Dazu wird ein Schlüsselpaar erzeugt: ein Private-Key (Client-Rechner) und ein Public-Key (Server). Der Private-Key ist besonders schützenzwerter, der Public-Key kann beliebig verteilt werden.

Das Verzeichnis ~/.ssh oder ~/.ssh2 muss für Dritte schreib- und lesegeschützt sein. Lediglich der Anwender selbst darf darauf zugreifen können.

Auf dem Rechner, von dem aus man sich auf einem anderen Rechner ohne Passwort einloggen will (Client), erzeugt man den privaten und öffentlichen Schlüssel:

oder

Die Schlüssel werden im Verzeichnis ~/.ssh abgelegt, der private Schlüssel beispielsweise in der Datei id_dsa, der öffentliche in der Datei id_dsa.pub.

Bei DSA und RSA handelt es sich um zwei konkurrenzierende Verschlüsselungsverfahren. DSA erstellt per default einen Schlüssel von 2048 Bit, RSA zwingend 1024 Bit.

Die öffentlichen Schlüssel können nun auf den Zielhost kopiert und dort in der Datei ~/.ssh/authorized_keys angehängt werden. Am einfachsten geht das mit

je nachdem, ob die RSA oder DSA Verschlüsselung gewählt wurde; mit den Basis-Systemwerkzeugen anderfalls in der Form

Um das beständige Nachfragen nach der Passphrase zu unterdrücken, ist es möglich, einen ssh-agent beim Login zu starten. Dieser Agent bekommt die Passphrase übergeben, kann den privaten Schlüssel aktivieren und in Zukunft alle Fragen nach diesem Schlüssel stellvertretend beantworten.

Viele Protokolle kennen auch heute noch nativ weder Authentifikation noch Verschlüsselung.

Damit diese Dienste dennoch abgesichert betrieben werden können, bietet sich an, diese durch einen abgesicherten Tunnel kommunizieren zu lassen. VPNs über IPsec sind ein guter und allgemein verwendbarer Ansatz. Für den kleinen Hunger zwischendurch bietet sich ein ssh-Tunnel an. Der Vorteil der zweiten Lösung liegt in der einfachen Konfiguration. Nachteilig ist, dass für jedes Protokoll ein eigener Tunnel erstellt werden muss sowie ein gewisser Protokolloverhead im Vergleich mit IPsec. Zwei Beispiele mögen das Vorgehen verdeutlichen:

• Anbindung einer PostgreSQL Datenbank
• Sichere nfs-Verbindung

Unter Linux ist neu mit OpenSSH ab Version 4.3 ist neben der oben beschriebenen Portweiterleitung auch möglich, über die virtuellen Netzwerktreiber TUN/TAP einen eigentlichen Tunnel auf Layer 2/3 aufzubauen. Dazu muss als erstes auf den Ausgangs- wie dem Zielrechner das entsprechende Kernel-Module geladen werden: modprobe tun.

Danach wird vom Ausgangsrechner auf den Zielrechner der Tunnel aufgebaut:

Voraussetzung ist, dass in der Konfiguration für sshd PermitTunnel yes gesetzt und aktiviert ist.

Zum Schluss sind die nun zur Verfügung stehenden Netzwerkschnittstellen zu konfigurieren. Beispielhaft kann dies so aussehen:

Das Userspace-Dateisystem bindet über das SSH File Transfer Protocol (SFTP) ganze Verzeichnisbäume in ein lokales System ein. Es benötigt einen Linux-Kernel, der FUSE (Filesystem in Userspace) unterstützt. Seit Version 2.6.14 gehört FUSE zum offiziellen Kernel und muss nicht mehr nachträglich eingebaut werden. FUSE kann auch als Kernel-Module kompiliert werden und muss, falls es nicht automatisch geladen wird, mit modprobe fuse durch den Benutzer root nachgeladen werden.

Unter Ubuntu oder Debian installiert man sshfs einfach per apt-get install sshfs. Benutzer, die sshfs aufrufen wollen, müssen der Gruppe fuse angehören. Zumindest unter Ubuntu ist darauf zu achten, dass /usr/bin/fusermount für alle ausführbar ist und dass auf /dev/fuse für lesen und schreiben dürfen Dieser Benutzer kann nun mit

einen SFTP-Zugang an das Verzeichnis mount-point anhängen (siehe man sshfs). Das Programm fragt dabei das Passwort für den SSH-Zugang ab. Mit den Dateien und Verzeichnissen unterhalb von mount-point arbeitet man wie mit lokalen Dateien, einzig einige grafische Dateimanager scheinen mit dem sshfs-Dateisystem nicht umgehen zu können.

Den sshfs-Mount löst man mit dem Befehl: