OpenSSH stellt Werkzeuge bereit, um sicher auf entfernte Maschinen zuzugreifen. Zusätzlich können TCP/IP-Verbindungen sicher durch SSH getunnelt oder weitergeleitet werden. OpenSSH verschlüsselt alle Verbindungen. Dadurch wird beispielsweise verhindert, dass die Verbindung abgehört oder übernommen (Hijacking) werden kann. Weitere Informationen zu OpenSSH finden Sie auf http://www.openssh.com/.
Dieser Abschnitt enthält einen Überblick über die integrierten Client-Werkzeuge, mit denen Sie sicher auf entfernte Systeme zugreifen können, oder mit denen Sie sicher Dateien austauschen können. Der Abschnitt beschreibt auch die Konfiguration eines SSH-Servers auf einem FreeBSD-System. Weitere Informationen finden Sie in den hier erwähnten Manualpages.
Benutzen Sie ssh
zusammen mit einem
Benutzernamen und einer IP-Adresse oder dem
Hostnamen, um sich an einem SSH-Server
anzumelden. Ist dies das erste Mal, dass eine Verbindung mit
dem angegebenen Server hergestellt wird, wird der Benutzer
aufgefordert, zuerst den Fingerabdruck des Servers zu
prüfen:
#
ssh
The authenticity of host 'example.com (10.0.0.1)' can't be established. ECDSA key fingerprint is 25:cc:73:b5:b3:96:75:3d:56:19:49:d2:5c:1f:91:3b. Are you sure you want to continue connecting (yes/no)?user@example.com
yes
Permanently added 'example.com' (ECDSA) to the list of known hosts. Password for user@example.com:
user_password
SSH speichert einen Fingerabdruck des
Serverschlüssels um die Echtheit des Servers zu überprüfen,
wenn der Client eine Verbindung herstellt. Wenn der Benutzer
den Fingerabdruck mit yes
bestätigt, wird
eine Kopie des Schlüssels in
.ssh/known_hosts
im Heimatverzeichnis des
Benutzers gespeichert. Zukünftige 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.
Wenn dies passiert, sollte zunächst geprüft werden, ob sich
der Schlüssel geändert hat, bevor die Verbindung hergestellt
wird.
In der Voreinstellung akzeptieren aktuelle Versionen von
OpenSSH nur
SSHv2 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. Weitere Optionen sind in ssh(1)
beschrieben.
Mit scp(1) lassen sich Dateien in einer sicheren
Weise auf entfernte Maschinen übertragen. Dieses Beispiel
kopiert die Datei COPYRIGHT
von einem
entfernten System in eine Datei mit dem gleichen Namen auf
das lokale System:
#
scp
Password for user@example.com:user@example.com:/COPYRIGHT COPYRIGHT
COPYRIGHT 100% |*****************************| 4735 00:00
*******
#
Da der Fingerabdruck für diesen Rechner bereits bestätigt wurde, wird er automatisch überprüft, bevor der Benutzer zur Eingabe des Passworts aufgefordert wird.
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. Beachten Sie, das scp
die
Option -r
verwendet um Dateien rekursiv
zu kopieren, während cp
-R
benutzt.
Mit sftp
können Dateien über eine
interaktive Sitzung kopiert werden. sftp(1) beschreibt
die verfügbaren Befehle, die während einer
sftp
-Sitzung zur Verfügung stehen.
Ein Client kann bei der Verbindung auch Schlüssel
anstelle von Passwörtern verwenden. Benutzen Sie
ssh-keygen
um
RSA-Schlüssel erzeugen. Geben
Sie das entsprechende Protokoll an, wenn Sie einen
öffentlichen und einen privaten Schlüssel erzeugen. Folgen
Sie anschließend den Anweisungen des Programms. Es wird
empfohlen, die Schlüssel mit einer einprägsamen, aber schwer
zu erratenen Passphrase zu schützen.
%
ssh-keygen -t rsa
Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase):Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: SHA256:54Xm9Uvtv6H4NOo6yjP/YCfODryvUU7yWHzMqeXwhq8 user@host.example.com The key's randomart image is: +---[RSA 2048]----+ | | | | | | | . o.. | | .S*+*o | | . O=Oo . . | | = Oo= oo..| | .oB.* +.oo.| | =OE**.o..=| +----[SHA256]-----+
Geben Sie hier die Passphrase ein. Diese darf auch Leer- und Sonderzeichen enthalten. | |
Geben Sie die Passphrase zur Überprüfung erneut ein. |
Der private Schlüssel wird in
~/.ssh/id_rsa
und der öffentliche
Schlüssel in ~/.ssh/id_rsa.pub
gespeichert. Der öffentliche Schlüssel
muss zuerst auf den entfernten Rechner nach
~/.ssh/authorized_keys
kopiert werden,
damit die schlüsselbasierte Authentifizierung
funktioniert.
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
-Präfix dafür sorgen, dass
sich ein bestimmter Benutzer nur noch von dieser
IP-Adresse anmelden darf.
Die Optionen und Dateinamen sind abhängig von der eingesetzten Version von OpenSSH. Die für das System gültigen Optionen finden Sie in ssh-keygen(1).
Wenn bei der Erzeugung des Schlüssels eine Passphrase angegeben wurde, wird der Benutzer bei jeder Anmeldung am Server zur Eingabe der Passphrase aufgefordert. 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
übernimmt die
Authentifizierung mit den geladenen privaten Schlüsseln.
ssh-agent
kann dazu verwendet
werden, ein anderes Programm zu starten, beispielsweise eine
Shell oder einen Window-Manager.
Um ssh-agent
in einer Shell zu
verwenden, muss es mit einer Shell als Argument aufgerufen
werden. Die zu verwaltende Identität muss mit
ssh-add
sowie der Passphrase für den
privaten Schlüssel übergeben werden. Danach kann sich der
Benutzer mit ssh
auf
jedem Rechner anmelden, der einen entsprechenden
öffentlichen Schlüssel besitzt. Dazu ein Beispiel:
%
ssh-agent
csh
%
ssh-add
Enter passphrase for /usr/home/user/.ssh/id_rsa:Identity added: /usr/home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
%
Um ssh-agent
unter
Xorg zu verwenden, muss ein
Eintrag für das Programm in ~/.xinitrc
aufgenommen werden. Dadurch können alle unter
Xorg gestarteten Programme die
Dienste von ssh-agent
nutzen.
~/.xinitrc
könnte etwa so
aussehen:
exec ssh-agent startxfce4
Dadurch wird bei jedem Start von
Xorg zuerst
ssh-agent
aufgerufen, das wiederum
XFCE startet. Nachdem diese
Änderung durchgeführt wurde, muss
Xorg neu gestartet werden.
Danach können Sie mit ssh-add
die
SSH-Schlüssel laden.
Mit OpenSSH ist es möglich, einen Tunnel zu erstellen, in dem ein anderes Protokoll verschlüsselt übertragen wird.
Im folgenden Kommando erzeugt ssh
einen Tunnel für telnet
:
%
ssh -2 -N -f -L
5023:localhost:23 user@foo.example.com
%
Dieses Beispiel verwendet die folgenden Optionen:
-2
Zwingt ssh
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
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 Anmeldenamen auf dem entfernten SSH-Server an.
Ein SSH-Tunnel erzeugt einen Socket
auf localhost
und dem angegebenen
lokalen Port. Jede Verbindung, die auf dem angegebenen
Socket aufgemacht wird, wird dann auf den spezifizierten
entfernten Rechner und Port weitergeleitet. Im Beispiel
wird der lokale Port 5023
an die
entfernte Maschine auf Port 23
weitergeleitet. Da der Port 23 für
telnet
reserviert ist, erzeugt das eine
sichere telnet(1)-Verbindung durch einen
SSH-Tunnel.
Wie in den folgenden Beispielen zu sehen ist, kann diese Vorgehensweise genutzt werden, um jedes unsichere TCP-Protokoll, wie SMTP, POP3 und FTP, weiterzuleiten.
%
ssh -2 -N -f -L
user@mailserver.example.com's password:5025:localhost:25 user@mailserver.example.com
*****
%
telnet localhost 5025
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP
Zusammen mit ssh-keygen
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.
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
user@ssh-server.example.com's password:2110:mail.example.com:110 user@ssh-server.example.com
******
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.
Einige Firewalls filtern sowohl eingehende als auch ausgehende Verbindungen. Zum Beispiel könnte eine Firewall den Zugriff auf entfernte Rechner auf die Ports 22 und 80 beschränken, um lediglich SSH und Web-Inhalte zu erlauben. Dies würde den Zugriff auf Dienste verhindern, die nicht die Ports 22 oder 80 benutzen.
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
user@unfirewalled-system.example.org's password:8888:music.example.com:8000 user@unfirewalled-system.example.org
*******
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.
Neben den integrierten SSH Client-Werkzeugen, die zur Verfügung stehen, kann ein FreeBSD-System auch als SSH-Server konfiguriert werden, um Verbindungen von anderen SSH-Clients zu akzeptieren.
Benutzen Sie den Kommando service(8), um zu prüfen ob der sshd ausgeführt wird:
#
service sshd status
Wenn der Dienst nicht ausgeführt wird, fügen Sie folgende
Zeile in /etc/rc.conf
ein:
sshd_enable="YES"
Diese Zeile startet sshd
, den
OpenSSH-Daemon, beim nächsten
Systemstart. Geben Sie folgendes ein, um den Dienst jetzt
zu starten:
#
service sshd start
Wenn sshd
erstmalig gestartet wird,
werden die Host-Schlüssel des Systems erzeugt und der
Fingerabdruck wird auf der Konsole angezeigt. Stellen Sie den
Fingerabdruck den Benutzern zur Verfügung, sodass sie ihn
überprüfen können, wenn sie das erste Mal eine Verbindung mit
dem Server herstellen.
sshd(8) enthält die verfügbaren Optionen für den
Start von sshd
und weitere Informationen
zur Authentifizierung, den Anmeldeprozess und die
verschiedenen Konfigurationsdateien.
Ab jetzt sollte sshd für alle Benutzer mit einem Benutzernamen und Kennwort zur Verfügung stehen.
Obwohl sshd das am weitesten verbreitete Remote-Administrations-Werkzeug ist, sind Brute-Force- und Drive-by-Angriffe auf öffentliche Netzwerke weit verbreitet. Daher stehen mehrere Optionen zur Verfügung, um diese Art von Angriffen zu verhindern. Diese Optionen werden in diesem Abschnitt beschrieben.
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
Nachdem Sie /etc/ssh/sshd_config
angepasst haben, muss sshd
seine
Konfigurationsdateien neu einlesen. Dazu geben Sie Folgendes
ein:
#
/etc/rc.d/sshd reload
Wenn die Option AllowUsers
verwendet
wird, ist es wichtig, jeden Benutzer aufzulisten, der sich
an diesem Rechner anmelden muss. Benutzer, die nicht in
dieser Liste aufgeführt sind, dürfen sich nicht anmelden.
Die Optionen für die Konfigurationsdatei von
OpenSSH unterscheiden zwischen
Groß- und Kleinschreibung. Wenn Sie eine Option falsch
schreiben, so wird sie ingnoriert. Testen Sie immer
die Änderungen, um sicherzustellen, dass sie wie erwartet
funktionieren. Weitere Informationen zu den verfügbaren
Optionen finden Sie in sshd_config(5).
Darüber hinaus können Benutzer gezwungen werden, eine
Zwei-Faktor-Authentifizierung mit einem öffentlichen und einem
privaten Schlüssel zu benutzen. Bei Bedarf kann der Benutzer
ein Schlüsselpaar mit ssh-keygen(1) erzeugen und dem
Administrator den öffentlichen Schlüssel zukommen lassen. Der
Schlüssel wird, wie weiter oben beschrieben, in
authorized_keys
platziert. Um den
Benutzer zu zwingen, ausschließlich Schlüssel zu benutzen,
kann die folgende Option konfiguriert werden:
AuthenticationMethods publickey
Verwechseln Sie nicht
/etc/ssh/sshd_config
mit
/etc/ssh/ssh_config
(beachten Sie das
zusätzliche d
im ersten Dateinamen). Die
erste Datei konfiguriert den Server und die zweite Datei
konfiguriert den Client. ssh_config(5) enthält eine
Auflistung der verfügbaren Client-Einstellungen.
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>.