This is an archive of past FreeBSD releases; it's part of the FreeBSD Documentation Archive.
FreeBSD Handbuch | ||
---|---|---|
Zurück | Kapitel 10. Sicherheit | Nach vorne |
Secure Shell stellt Werkzeuge bereit, um sicher auf entfernte Maschinen zuzugreifen. Die Kommandos rlogin, rsh, rcp und telnet können durch ssh ersetzt werden. Zusätzlich können andere 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 basiert auf SSH v1.2.12 mit allen aktuellen Fixen und Aktualisierungen. OpenSSH ist mit den SSH Protokollen der Versionen 1 und 2 kompatibel. Seit FreeBSD 4.0 ist die OpenSSH Teil des Basissystems.
Mit telnet(1) oder rlogin(1) werden Daten in einer unverschlüsselten Form über das Netzwerk gesendet. Daher 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.
Stellen Sie sicher, dass /etc/rc.conf die folgende Zeile enthält:
sshd_enable="YES"
Der ssh Dæmon wird damit bei dem nächsten Neustart des Systems geladen. Alternativ können Sie den Dæmon auch händisch starten.
ssh(1) arbeitet ähnlich wie rlogin(1):
# 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: *******
Der Anmeldevorgang wird danach, wie von rlogin oder telnet gewohnt, weiterlaufen. 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 der Version 1 werden in ~/.ssh/known_hosts, die der Version 2 in ~/.ssh/known_hosts2 gespeichert.
In der Voreinstellung akzeptieren OpenSSH Server Verbindungen mit SSH v1 und SSH v2. Die Clients können sich aber das Protokoll auswählen, dabei wird das Protokoll der Version 2 als robuster und sicherer als die Vorgängerversion angesehen.
Mit den Optionen -1 oder -2 kann die Protokollversion, die ssh verwendet, erzwungen werden.
Mit scp lassen sich Dateien analog wie mit rcp auf entfernte Maschinen kopieren. Mit scp werden die Dateien allerdings in einer sicheren Weise ü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 übergeben werden, gleichen denen von cp 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.
Die für das ganze System gültigen Konfigurationsdateien des OpenSSH Dæmons und des Clients finden sich in dem Verzeichnis /etc/ssh.
Die Client-Konfiguration befindet sich in ssh_config, die des Servers befindet sich in sshd_config.
Das SSH-System lässt sich weiterhin über die Anweisungen sshd_program (Vorgabe ist /usr/sbin/sshd) und sshd_flags in /etc/rc.conf konfigurieren.
Mit ssh-keygen(1) können RSA-Schlüssel für einen Benutzer erzeugt werden, die anstelle von Passwörtern verwendet werden können.
% ssh-keygen Initializing random number generator... Generating p: .++ (distance 66) Generating q: ..............................++ (distance 498) Computing the keys... Key generation complete. Enter file in which to save the key (/home/user/.ssh/identity): Enter passphrase: Enter the same passphrase again: Your identification has been saved in /home/user/.ssh/identity. ...
ssh-keygen(1) erzeugt einen öffentlichen und einen privaten Schlüssel für die Authentifizierung. Der private Schlüssel wird in ~/.ssh/identity, der öffentliche Schlüssel in ~/.ssh/identity.pub gespeichert. Damit die RSA-Schlüssel zur Authentifizierung verwendet werden können, muss der öffentliche Schlüssel in der Datei ~/.ssh/authorized_keys auf der entfernten Maschine abgelegt werden.
Damit werden Verbindungen zu der entfernten Maschine über den RSA-Mechanismus anstelle von Passwörtern authentifiziert.
Wenn bei der Erstellung der Schlüssel mit ssh-keygen(1) ein Passwort angegeben wurde, wird der Benutzer bei jeder Anmeldung zur Eingabe des Passworts aufgefordert.
Zum gleichen Zweck kann ein DSA-Schlüssel zur Verwendung mit SSH v2 erstellt werden. Dazu rufen Sie das Kommando ssh-keygen -d oder ssh-keygen -t dsa mit FreeBSD FreeBSD-CURRENT auf. Sie erzeugen damit ein DSA-Schlüsselpaar, das nur in SSH v2 Verbindungen genutzt wird. Der öffentliche Schlüssel wird in ~/.ssh/id_dsa.pub, der private Schlüssel in ~/.ssh/id_dsa gespeichert.
Die öffentlichen DSA-Schlüssel werden in ~/.ssh/authorized_keys2 auf der entfernten Maschine abgelegt.
Mit ssh-agent(1) und ssh-add(1) können Sie mehrere durch Passwörter geschützte private Schlüssel verwalten.
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:
% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com %
Dabei wurden die folgenden Optionen von ssh verwendet:
Erzwingt die Version 2 des Protokolls (Benutzen Sie die Option nicht mit langsamen ssh-Servern).
Zeigt an, dass ein Tunnel erstellt werden soll. Ohne diese Option würde ssh eine normale Sitzung öffnen.
Zwingt ssh im Hintergrund zu laufen.
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.
Gibt den entfernten SSH server an.
Ein SSH-Tunnel erzeugt ein 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 reserviert ist, erzeugt das eine sichere Telnet Verbindung durch einen SSH-Tunnel.
Diese Vorgehensweise kann genutzt werden, um jedes unsichere TCP-Protokoll wie SMTP, POP3, FTP, usw. weiterzuleiten.
Beispiel 10-1. Mit SSH 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 Sie leicht benutzbare SSH-Tunnel aufbauen. Anstelle von Passwörtern können Sie Schlüssel benutzen und jeder Tunnel kann unter einem eigenen Benutzer laufen.
Nehmen wir an, an Ihrer Arbeitsstelle gibt es einen SSH-Server, der Verbindungen von außen akzeptiert. Auf dem Netzwerk Ihrer Arbeitsstelle soll sich zudem noch ein Mail-Server befinden, der POP3 spricht. Das Netzwerk oder die Verbindung von Ihrem Haus zu Ihrer Arbeitsstelle ist unsicher und daher müssen Sie Ihre E-Mail über eine gesicherte Verbindung abholen können. Die Lösung zu diesem Problem besteht darin, eine SSH-Verbindung von Ihrem Haus zu dem SSH-Server an Ihrer Arbeitsstelle aufzubauen, und von dort weiter zum Mail-Server zu tunneln.
% 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 Ihren Mail-Client so, dass er POP3 Anfragen zu localhost Port 2110 sendet. Die Verbindung wird dann sicher zu mail.example.com weitergeleitet.
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.
Sie wollen auf einen Dienst, der vielleicht nichts mit Ihrer Arbeit zu tun hat, wie einen Ogg Vorbis Musik-Server, zugreifen. Wenn der Ogg Vorbis Server nicht auf den Ports 22 oder 80 läuft, können Sie aber nicht auf ihn zugreifen.
Die Lösung hier ist es, eine SSH-Verbindung zu einer Maschine außerhalb der Firewall aufzumachen und durch diese zum Ogg Vorbis Server zu tunneln.
% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled.myserver.com user@unfirewalled.myserver.com's password: *******
Konfigurieren Sie Ihren Client so, dass er localhost und Port 8888 benutzt. Die Verbindung wird dann zu music.example.com Port 8000 weitergeleitet und Sie haben die Firewall erfolgreich umgangen.
Zurück | Zum Anfang | Nach vorne |
IPsec | Nach oben | Vorgeschriebene Zugriffskontrolle (MAC) |
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>.