14.8. OpenSSH

Beigetragen von Chern Lee.

OpenSSH stellt Werkzeuge bereit, um sicher auf entfernte Maschinen zuzugreifen. Zusätzlich können TCP/IP-Verbindungen sicher durch SSH weitergeleitet (getunnelt) werden. Mit SSH werden alle Verbindungen verschlüsselt, dadurch wird verhindert, dass die Verbindung zum Beispiel abgehört oder übernommen (Hijacking) werden kann.

OpenSSH wird vom OpenBSD-Projekt gepflegt und wird in der Voreinstellung von FreeBSD installiert. OpenSSH ist mit den SSH-Protokollen der Versionen 1 und 2 kompatibel.

14.8.1. Vorteile von OpenSSH

Wenn Daten unverschlüsselt über das Netzwerk gesendet werden, besteht die Gefahr, das Benutzer/Passwort Kombinationen oder alle Daten an beliebiger Stelle zwischen dem Client und dem Server abgehört werden. Mit OpenSSH stehen eine Reihe von Authentifizierungs- und Verschlüsselungsmethoden zur Verfügung, um das zu verhindern.

14.8.2. Den SSH-Server aktivieren

Um zu überprüfen, ob sshd(8) auf dem System aktiviert ist, suchen Sie in rc.conf nach der folgenden Zeile:

sshd_enable="YES"

Ist diese Zeile vorhanden, wird sshd(8), der OpenSSH-Daemon, beim Systemstart automatisch aktiviert. Alternativ kann OpenSSH auch über service(8) gestartet werden:

# service sshd start

14.8.3. SSH Client

Benutzen Sie ssh(1) um sich mit einem System zu verbinden, auf dem sshd(8) läuft. Verwenden Sie dazu den Benutzernamen und den Namen des Rechners, mit dem Sie sich verbinden möchten:

# ssh user@example.com
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'example.com' added to the list of known hosts.
user@example.com's password: *******

SSH speichert einen Fingerabdruck des Serverschlüssels. Die Aufforderung, yes einzugeben, erscheint nur bei der ersten Verbindung zu einem Server. Weitere Verbindungen zu dem Server werden gegen den gespeicherten Fingerabdruck des Schlüssels geprüft und der Client gibt eine Warnung aus, wenn sich der empfangene Fingerabdruck von dem gespeicherten unterscheidet. Die Fingerabdrücke werden in ~/.ssh/known_hosts gespeichert.

In der Voreinstellung akzeptieren aktuelle Versionen von sshd(8) nur SSH v2 Verbindungen. Wenn möglich, wird der Client versuchen Version 2 zu verwenden, ist dies nicht möglich, fällt er auf Version 1 zurück. Der Client kann gezwungen werden, nur eine der beiden Versionen zu verwenden, indem die Option -1 oder -2 übergeben wird. Die Unterstützung für Version 1 ist nur noch aus Kompatibilitätsgründen zu älteren Versionen enthalten.

14.8.4. Secure Copy

Mit scp(1) lassen sich Dateien in einer sicheren Weise auf entfernte Maschinen übertragen.

#  scp user@example.com:/COPYRIGHT COPYRIGHT
user@example.com's password:
COPYRIGHT            100% |*****************************|  4735
00:00
#

Da der Fingerabdruck schon im vorigen Beispiel abgespeichert wurde, wird er bei der Verwendung von scp in diesem Beispiel überprüft. Da die Fingerabdrücke übereinstimmen, wird keine Warnung ausgegeben.

Die Argumente, die scp(1) übergeben werden, gleichen denen von cp(1) in der Beziehung, dass die ersten Argumente die zu kopierenden Dateien sind und das letzte Argument den Bestimmungsort angibt. Da die Dateien über das Netzwerk kopiert werden, können ein oder mehrere Argumente die Form user@host:<path_to_remote_file> besitzen.

14.8.5. Konfiguration

Die für das ganze System gültigen Konfigurationsdateien des OpenSSH-Daemons und des Clients befinden sich in /etc/ssh.

Die Client-Konfiguration befindet sich in ssh_config, die des Servers befindet sich in sshd_config. Für beide Dateien existieren Manualpages, welche die einzelnen Konfigurationsoptionen beschreiben.

Mit ssh-keygen(1) können DSA- oder RSA-Schlüssel für einen Benutzer erzeugt werden, die anstelle von Passwörtern verwendet werden können:

% ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com

ssh-keygen(1) erzeugt einen öffentlichen und einen privaten Schlüssel für die Authentifizierung. Der private Schlüssel wird in ~/.ssh/id_dsa oder ~/.ssh/id_rsa gespeichert, während sich der öffentliche Schlüssel in ~/.ssh/id_dsa.pub oder ~/.ssh/id_rsa.pub befindet, je nachdem, ob es sich um einen DSA- oder einen RSA-Schlüssel handelt. Der öffentliche Schlüssel muss sowohl für RSA- als auch für DSA-Schlüssel in ~/.ssh/authorized_keys auf dem entfernten Rechner aufgenommen werden, damit der Schlüssel funktioniert.

Damit werden Verbindungen zu der entfernten Maschine über SSH-Schlüsseln anstelle von Passwörtern authentifiziert.

Warnung:

Viele Benutzer denken, dass die Verwendung von Schlüsseln generell sicher ist. Sie verwenden dann einen Schlüssel ohne eine Passphrase. Dies ist jedoch sehr gefährlich. Ein Administrator kann überprüfen, ob ein Schlüsselpaar mit einer Passphrase geschützt ist. Wenn die Datei mit dem privaten Schlüssel den Text ENCRYPTED enthält, dann hat der Benutzer eine Passphrase verwendet. Um die Benutzer zusätzlich zu schützen, kann ein from-Feld in der Datei des öffentlichen Schlüssels hinzugefügt werden. Zum Beispiel würde das Hinzufügen von from="192.168.10.5" vor dem ssh-rsa- oder ssh-dsa-Präfix dafür sorgen, dass sich ein bestimmter Benutzer nur noch von dieser IP-Adresse anmelden darf.

Wenn bei der Erstellung der Schlüssel mit ssh-keygen(1) eine Passphrase angegeben wurde, wird der Benutzer bei jeder Anmeldung zur Eingabe des Passworts aufgefordert. Um den Umgang mit SSH-Schlüsseln zu erleichtern, kann ssh-agent(1) die Verwaltung dieser Schlüssel für Sie übernehmen. Lesen Sie dazu den Abschnitt 14.8.7, „Verwendung von SSH-Agent“.

Warnung:

Die Optionen und Dateinamen sind abhängig von der OpenSSH-Version. Die für das System gültigen Optionen finden Sie in ssh-keygen(1).

14.8.7. Verwendung von SSH-Agent

Mit ssh-agent(1) und ssh-add(1) ist es möglich, SSH-Schlüssel in den Speicher zu laden, damit die Passphrase nicht jedes Mal eingegeben werden muss.

ssh-agent(1) übernimmt die Authentifizierung von ihm geladener privater Schlüssel. ssh-agent(1) sollte nur dazu verwendet werden, ein anderes Programm zu starten, beispielsweise eine Shell oder einen Window-Manager.

Um ssh-agent(1) in einer Shell zu verwenden, muss es mit einer Shell als Argument aufgerufen werden. Zudem muss die zu verwaltende Identität mit ssh-add(1) sowie deren Passphrase für den privaten Schlüssel übergeben werden. Nachdem dies erledigt ist, kann sich ein Benutzer über ssh(1) auf jedem Rechner anmelden, der einen entsprechenden öffentlichen Schlüssel besitzt. Dazu ein Beispiel:

% ssh-agent csh
% ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
%

Um ssh-agent(1) unter Xorg zu verwenden, muss ssh-agent(1) in ~/.xinitrc aufgenommen werden. Dadurch können alle unter Xorg gestarteten Programme die Dienste von ssh-agent(1) nutzen. ~/.xinitrc könnte etwa so aussehen:

exec ssh-agent startxfce4

Dadurch wird bei jedem Start von Xorg zuerst ssh-agent(1) aufgerufen, das wiederum XFCE startet. Nachdem diese Änderung durchgeführt wurde, muss Xorg neu gestartet werden. Danach können Sie mit ssh-add(1) die SSH-Schlüssel laden.

14.8.8. SSH-Tunnel

Mit OpenSSH ist es möglich, einen Tunnel zu erstellen, in dem ein anderes Protokoll verschlüsselt übertragen wird.

Das folgende Kommando erzeugt einen Tunnel für telnet(1):

% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
%

Dieses Beispiel verwendet die folgenden Optionen:

-2

Zwingt ssh(1) dazu, die Version 2 des Protokolls zu verwenden, um sich mit dem Server zu verbinden.

-N

Zeigt an, dass ein Tunnel erstellt werden soll. Ohne diese Option würde ssh(1) eine normale Sitzung öffnen.

-f

Zwingt ssh(1) im Hintergrund zu laufen.

-L

Ein lokaler Tunnel wird in der Form localport:remotehost:remoteport angegeben. Die Verbindung wird dabei von dem lokalen Port localport auf einen entfernten Rechner weitergeleitet.

user@foo.example.com

Gibt den Anmeldenamen auf dem entfernten SSH-Server an.

Ein SSH-Tunnel erzeugt einen Socket auf localhost und dem angegebenen Port. Jede Verbindung, die auf dem angegebenen Socket aufgemacht wird, wird dann auf den spezifizierten entfernten Rechner und Port weitergeleitet.

Im Beispiel wird der Port 5023 auf die entfernte Maschine und dort auf localhost Port 23 weitergeleitet. Da der Port 23 für telnet(1) reserviert ist, erzeugt das eine sichere telnet(1)-Verbindung durch einen SSH-Tunnel.

Diese Vorgehensweise kann genutzt werden, um jedes unsichere TCP-Protokoll wie SMTP, POP3 und FTP weiterzuleiten.

Beispiel 14.1. Mit ssh(1) einen sicheren Tunnel für SMTP erstellen
% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com's password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP

Zusammen mit ssh-keygen(1) und zusätzlichen Benutzer-Accounts können leicht benutzbare SSH-Tunnel aufgebaut werden. Anstelle von Passwörtern können Schlüssel benutzt werden und jeder Tunnel kann unter einem eigenen Benutzer laufen.


14.8.8.1. Praktische Beispiele für SSH-Tunnel

14.8.8.1.1. Sicherer Zugriff auf einen POP3-Server

In diesem Beispiel gibt es einen SSH-Server, der Verbindungen von außen akzeptiert. Im selben Netzwerk befindet sich zudem noch ein Mail-Server, der POP3 spricht. Um E-Mails auf sichere Weise abzurufen, bauen Sie eine SSH-Verbindung zu dem SSH-Server im Netzwerk auf und tunneln von dort zum Mail-Server weiter.

% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
user@ssh-server.example.com's password: ******

Wenn Sie den Tunnel eingerichtet haben, konfigurieren Sie den Mail-Client so, dass er POP3 Anfragen zu localhost auf Port 2110 sendet. Diese Verbindung wird dann über den gesicherten Tunnel zu mail.example.com weitergeleitet.

14.8.8.1.2. Umgehen einer strengen Firewall

Einige Netzwerkadministratoren stellen sehr drakonische Firewall-Regeln auf, die nicht nur einkommende Verbindungen filtern, sondern auch ausgehende. Es kann sein, dass Sie externe Maschinen nur über die Ports 22 und 80 (SSH und Web) erreichen.

Die Lösung hier ist es, eine SSH-Verbindung zu einer Maschine außerhalb der Firewall aufzumachen und durch diese zum gewünschten Dienst zu tunneln.

% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
user@unfirewalled-system.example.org's password: *******

In diesem Beispiel benutzt ein Ogg Vorbis Client localhost und Port 8888. Die Verbindung wird dann zu music.example.com Port 8000 weitergeleitet. Die Firewall wurde somit erfolgreich umgangen.

14.8.9. Die Option AllowUsers

Es ist in der Regel ein gute Idee, festzulegen, welche Benutzer sich von welchem Rechner aus anmelden können. Dies lässt sich beispielsweise über die Option AllowUsers festlegen. Soll sich etwa nur root vom Rechner mit der IP-Adresse 192.168.1.32 aus einwählen dürfen, würden Sie folgenden Eintrag in /etc/ssh/sshd_config aufnehmen:

AllowUsers root@192.168.1.32

Damit sich admin von jedem Rechner aus anmelden kann, geben Sie nur den Benutzernamen an:

AllowUsers admin

Sie können auch mehrere Benutzer in einer Zeile aufführen:

AllowUsers root@192.168.1.32 admin

Anmerkung:

Nur Benutzer, die in dieser Liste aufgeführt ist, dürfen sich auf diesem Rechner anmelden.

Nachdem Sie /etc/ssh/sshd_config angepasst haben, muss sshd(8) seine Konfigurationsdateien neu einlesen. Dazu geben Sie Folgendes ein:

# /etc/rc.d/sshd reload

14.8.10. Weiterführende Informationen

OpenSSH

ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1) ssh_config(5) für Client Optionen.

sshd(8) sftp-server(8) sshd_config(5) für Server Optionen.

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.

Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.