OpenSSH stellt Werkzeuge bereit,
um sicher auf entfernte
Maschinen zuzugreifen. Die Kommandos rlogin
,
rsh
, rcp
und
telnet
können durch
OpenSSH ersetzt werden.
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 basiert auf SSH v1.2.12 mit allen aktuellen Fixen und Aktualisierungen. OpenSSH ist mit den SSH-Protokollen der Versionen 1 und 2 kompatibel.
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.
Unter FreeBSD entscheidet der
Anwender bei einer Standard
-Installation, ob
der sshd-Daemon aktiviert werden soll.
Um zu überprüfen, ob sshd
auf Ihrem System aktiviert ist, suchen Sie in
rc.conf
nach der folgenden Zeile:
Ist diese Zeile vorhanden, wird sshd(8), der
OpenSSH-Dæmon, beim
Systemstart automatisch aktiviert. Alternativ können Sie
OpenSSH auch über das
rc(8)-Skript /etc/rc.d/sshd
starten:
#
/etc/rc.d/sshd start
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 aktuelle
OpenSSH-Server nur SSH v2
Verbindungen. Wenn möglich, wird Version 2 verwendet,
ist dies nicht möglich, fällt der Server auf
Version 1 zurück. Der Client kann gezwungen werden,
nur eine der beiden Versionen zu verwenden, indem die Option
-1
(für die Version 1) oder
-2
(für die Version 2) übergeben
wird. Die Unterstützung für Version 1 ist nur
noch aus Kompatibilitätsgründen zu älteren
Versionen enthalten.
Mit scp(1) lassen sich Dateien analog wie mit
rcp(1) 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 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.comssh-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 die Datei
~/.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.
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. 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 15.10.7, „ssh-agent und ssh-add“ weiter unten.
Die Kommandozeilenoptionen und Dateinamen sind abhängig von der OpenSSH-Version. Die für Ihr System gültigen Optionen finden Sie in der Hilfeseite ssh-keygen(1).
Mit ssh-agent(1) und ssh-add(1) ist es möglich, SSH-Schlüssel in den Speicher zu laden, damit die Passphrase nicht jedesmal 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. Zusätzlich müssen die zu verwaltende Identität (durch 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 X11 zu verwenden, müssen
Sie ssh-agent(1) in Ihre ~/.xinitrc
aufnehmen. Dadurch können alle unter X11 gestarteten
Programme die Dienste von ssh-agent(1) nutzen. Ihre
~/.xinitrc
könnte dazu etwas so
aussehen:
startxfce4
Dadurch wird bei jedem Start von X11 zuerst ssh-agent(1) aufgerufen, das wiederum XFCE startet. Nachdem Sie diese Änderung durchgeführt haben, müssen Sie X11 neu starten. Danach können Sie mit ssh-add(1) Ihre SSH-Schlüssel laden.
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:
-2
Erzwingt die Version 2 des Protokolls (Benutzen Sie die Option nicht mit langsamen SSH-Servern).
-N
Zeigt an, dass ein Tunnel erstellt werden soll.
Ohne diese Option würde ssh
eine
normale Sitzung öffnen.
-f
Zwingt ssh
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 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.
%
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 ESMTPZusammen 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-system.example.org
user@unfirewalled-system.example.org'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.
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:
Damit sich admin
von jedem Rechner aus
anmelden kann, geben Sie nur den Benutzernamen an:
Sie können auch mehrere Benutzer in einer Zeile aufführen:
Nur ein Benutzer, der in dieser Liste aufgeführt ist, darf 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
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>.