| SSH(1) | General Commands Manual | SSH(1) |
ssh —
OpenSSH-Client zur Anmeldung in der Ferne
ssh
[-46AaCfGgKkMNnqsTtVvXxYy]
[-B Anbindeschnittstelle]
[-b Anbindeadresse]
[-c Chiffrespez]
[-D
[Anbindeadresse:]Port]
[-E Protokolldatei]
[-e Maskierzeichen]
[-F Konfigurationsdatei]
[-I PKCS11]
[-i Identitätsdatei]
[-J Ziel]
[-L Adresse]
[-l Anmeldename]
[-m MAC_Spez]
[-O Steuerbefehl]
[-o Option]
[-p Port]
[-Q Abfrageoption]
[-R Adresse]
[-S Steuerpfad]
[-W
Rechner:Port]
[-w
lokaler_Tun[:ferner_Tun]]
Ziel [Befehl]
ssh (SSH-Client) ist ein Programm zum
Anmelden an einer fernen Maschine und zur Ausführung von Befehlen auf
fernen Maschinen. Es ist zur Bereitstellung sicherer, verschlüsselter
Kommunikation zwischen zwei nicht vertrauenswürdigen Rechnern
über ein unsicheres Netzwerk gedacht. X11-Verbindungen, beliebige
TCP-Ports und UNIX-domain -Sockets können
auch über den sicheren Kanal weitergeleitet werden.
ssh verbindet sich mit dem angegebenen
Ziel und meldet sich dort an. Das
Ziel kann entweder als [Benutzer@]Rechnername oder
eine URI der Form
ssh://[Benutzer@]Rechnername[:Port] angegeben
werden. Der Benutzer muss seine/ihre Identitität auf der fernen
Maschine mittels einer von mehreren, nachfolgend beschriebenen Methoden
nachweisen.
Falls ein Befehl angegeben ist, wird dieser auf der fernen Maschine statt einer Anmelde-Shell ausgeführt.
Folgende Optionen stehen zur Verfügung:
-4ssh nur IPv4-Adressen verwendet.
-6ssh nur IPv6-Adressen verwendet.
-AVermittlerweiterleitung sollte mit Vorsicht aktiviert werden.
Benutzer, die auf dem fernen Rechner die Dateiberechtigungen umgehen
können (für den UNIX-domain
-Socket des Vermittlers), können auf den lokalen Vermittler
über die weitergeleitete Verbindung zugreifen. Ein Angreifer kann
vom Vermittler kein Schlüsselmaterial erlangen, allerdings kann
er Aktionen unter den Schlüsseln ausführen, die es ihm
ermöglichen, sich unter den im Vermittler geladenen
Identitäten zu authentifizieren. Eine sichere Alternative
könnte die Verwendung eines Sprungrechners sein (siehe
-J).
-a-B
Anbindeschnittstelle-b
Anbindeadresse-CCompression.
-c
ChiffrespezCiphers in
ssh_config(5) für weitere Informationen.
-D
[Anbindeadresse:]Portssh wird
als SOCKS-Server auftreten. Nur root kann privilegierte Ports
weiterleiten. Dynamische Portweiterleitungen können auch in der
Konfigurationsdatei festgelegt werden.
IPv6-Adressen können durch Angabe der Adresse in
eckigen Klammern festgelegt werden. Nur der Systemadministrator kann
privilegierte Ports weiterleiten. Standardmäßig ist der
lokale Port gemäß der Einstellung
GatewayPorts angebunden. Allerdings kann eine
explizite Anbindeadresse verwandt werden, um die
Verbindung an die bestimmte Adresse anzubinden. Die
Anbindeadresse “localhost” zeigt an,
dass dieser Port, auf dem auf Anfragen gewartet werden soll, nur
für die lokale Benutzung angebunden ist, während eine
leere Adresse oder ‘*’ anzeigt, dass der Port an allen
Schnittstellen verfügbar sein soll.
-E
Protokolldatei-e
Maskierzeichen~’). Das Maskierzeichen wird nur am
Anfang einer Zeile erkannt. Das Maskierzeichen, gefolgt von einem Punkt
(‘.’), schließt die
Verbindung; gefolgt von einem Strg-Z, suspendiert es die Verbindung und
gefolgt von sich selbst, sendet es einmalig das Maskierzeichen. Durch
Setzen des Zeichens auf “none” wird Maskierung deaktiviert
und die Sitzung vollkommen transparent.
-F
Konfigurationsdatei-fssh, sich vor der
Befehlsausführung in den Hintergrund zu schieben. Dies ist
nützlich, falls ssh nach Passwörtern
oder Passphrasen fragen wird, der Benutzer es aber im Hintergrund
ausgeführt haben möchte. Dies impliziert
-n. Die empfohlene Art, X11-Programme auf einem
fernen Rechner zu starten, ist etwas der Art nach ssh -f
host xterm.
Falls die Konfigurationsoption
ExitOnForwardFailure auf “yes”
gesetzt ist, dann wird ein Client, der mit -f
gestartet wurde, darauf warten, dass alle fernen Port-Weiterleitungen
erfolgreich etabliert wurden, bevor er sich in den Hintergrund
schiebt.
-Gssh nach der Auswertung
der Blöcke Host und
Match seine Konfiguration anzeigt und sich
beendet.
-g-I
PKCS11ssh
für die Kommunikation mit einem PKCS#11-Token verwenden soll, der
Schlüssel für die Benutzerauthentifizierung bereitstellt.
-i
Identitätsdatei-i (und mehrere in Konfigurationsdateien
festgelegte Identitäten) einzusetzen. Falls keine Zertifikate
explizit durch die Direktive CertificateFile
angegeben sind, wird ssh versuchen, die
Zertifikatsinformationen aus dem Dateinamen zu laden, der durch
Anhängen von -cert.pub an die
Identitätsdateinamen ermittelt wird.
-J
Zielssh zuerst
eine Verbindung zu dem in Ziel angegebenen
Sprungrechner aufbaut und dann dort eine TCP-Weiterleitung zum
endgültigen Ziel etabliert. Mehrere Sprungrechner können
durch Kommata getrennt angegeben werden. Dies ist eine Abkürzung
für die Verwendung der Konfigurationsdirektive
ProxyJump. Beachten Sie, dass auf der Befehlszeile
übergebene Konfigurationsdirektiven sich im Allgemeinen auf den
Zielrechner und nicht den angegebenen Sprungrechner beziehen. Verwenden
Sie ~/.ssh/config, um Konfiguration für den
Sprungrechner anzugeben.
-K-k-L
[Anbindeadresse:]Port:Rechner:Rechnerport-L
[Anbindeadresse:]Port:fernes_Socket-L
lokales_Socket:Rechner:Rechnerport-L
lokales_Socket:RechnerPort-Weiterleitung kann auch in der gesamten Konfigurationsdatei festgelegt werden. Nur der Systemadministrator kann privilegierte Ports weiterleiten. Durch Einschließen der Adresse in eckige Klammern können IPv6-Adressen angegeben werden.
Standardmäßig ist der lokale Port
gemäß der Einstellung GatewayPorts
angebunden. Allerdings kann eine explizite
Anbindeadresse verwandt werden, um die Verbindung
an eine bestimmte Adresse anzubinden. Wird “localhost” als
Anbindeadresse verwandt, zeigt dies an, dass der
Port, an dem auf Anfragen gewartet wird, nur lokal eingesetzt werden
soll, während eine leere Adresse oder ‘*’ anzeigt,
dass der Port von allen Schnittstellen aus verfügbar sein
soll.
-l
Anmeldename-Mssh -Client in den
“master” -Modus für die gemeinsame Benutzung von
Verbindungen. Durch mehrere Optionen -M wird
ssh in den “master” -Modus gebracht,
es wird aber eine Bestätigung mit ssh-askpass(1)
vor jeder Aktion verlangt, die den Multiplexing-Zustand ändert
(z.B. Öffnen einer neuen Sitzung). Lesen Sie die Beschreibung von
ControlMaster in ssh_config(5)
für Details.
-m
MAC_SpezMAC für weitere Informationen.
-N-nssh im Hintergrund
ausgeführt wird. Ein häufiger Trick ist, dies beim Einsatz
von X11-Programmen auf einer fernen Maschine zu verwenden. Beispielsweise
wird ssh -n shadows.cs.hut.fi emacs & einen
Emacs auf shadows.cs.hut.fi starten und die X11-Verbindung wird
automatisch über einen verschlüsselten Kanal weitergeleitet.
Das Programm ssh wird in den Hintergrund
geschoben. (Dies funktioniert nicht, falls ssh
nach einem Passwort oder einer Passphrase fragen muss, siehe auch die
Option -f.)
-O
Steuerbefehl-O angegeben, dann wird das
Argument Steuerbefehl interpretiert und an den
Master-Prozess übergeben. Gültige Befehle sind:
“check” (prüfen, ob der Master-Prozess läuft),
“forward” (Weiterleitungen ohne Befehlsausführung
erbitten), “cancel” (Weiterleitungen abbrechen),
“exit” (den Master zum Beenden auffordern) und
“stop” (den Master bitten, keine weiteren
Multiplexing-Anforderungen zu akzeptieren).
-o
Option-p
Port-Q
Abfrageoptionssh nach den für die festgelegte
Version 2 unterstützten Algorithmen. Die verfügbaren
Funktionalitäten sind: cipher
(unterstützte symmetrische Chiffren),
cipher-auth (unterstützte symmetrische
Chiffren, die authentifizierte Verschlüsselung
unterstützen), help (die für den
Einsatz mit dem Schalter -Q unterstützten
Abfrageausdrücke), mac (unterstützte
Nachrichtenintegritätscodes), kex
(Schlüssel-Austauschalgorithmen), kex-gss
(GSSAPI-Schlüssel-Austauschalgorithmen), key
(Schlüsseltypen), key-cert
(Zertifikatsschlüsseltypen), key-plain
(nicht-Zertifikatsschlüsseltypen), key-sig
(alle Schlüsseltypen und Signaturalgorithmen),
Protokollversion (unterstützte
SSH-Protokollversionen) und sig (unterstützte
Signaturalgorithmen). Alternativ kann jedes Schlüsselwort aus
ssh_config(5) und sshd_config(5), das
eine Algorithmenliste akzeptiert, als ein Alias für die
entsprechende Abfrageoption verwandt werden.
-q-R
[Anbindeadresse:]Port:Rechner:Rechnerport-R
[Anbindeadresse:]Port:lokales_Socket-R
fernes_Socket:Rechner:Rechnerport-R
fernes_Socket:lokales_Socket-R
[Anbindeadresse:]PortDazu wird auf der fernen Seite ein Socket bereitgestellt, das
entweder auf einem TCP- Port oder einem
Unix-Socket auf Anfragen wartet. Immer wenn eine Verbindung zu diesem
Port oder Unix-Socket aufgebaut wird, wird sie über den sicheren
Kanal weitergeleitet und eine weitere Verbindung erstellt, die zu einem
expliziten Ziel führt (angegeben durch den Port auf dem
Rechner oder
lokales_Socket). Falls kein Ziel genannt wurde,
arbeitet ssh als SOCKS4/5-Proxy und leitet die
Verbindungen zu den Zielen weiter, die vom entfernten SOCKS-Client
erbeten werden.
Port-Weiterleitungen können auch in der Konfigurationsdatei festgelegt werden. Privilegierte Ports können nur nach Anmeldung als root auf der fernen Maschine weitergeleitet werden. Durch Einschluss der Adresse in eckige Klammern können IPv6-Adressen angegeben werden.
Standardmäßig werden TCP-Ports auf dem Server,
an denen auf Anfragen gewartet wird, nur an die Loopback-Schnittstelle
gebunden. Dies kann durch Angabe einer
Anbindeadresse außer Kraft gesetzt werden.
Eine leere Anbindeadresse oder die Adresse
‘*’ zeigt an, dass das ferne
Socket auf allen Schnittstellen auf Anfragen warten soll. Die Angabe
einer fernen Anbindeadresse wird nur erfolgreich
sein, falls die Option GatewayPorts des Servers
aktiviert ist (siehe sshd_config(5)).
Falls das Argument Port
‘0’ ist, dann wird der Port, an
dem auf Anfragen gewartet wird, dynamisch auf dem Server zugewiesen und
zur Laufzeit dem Client mitgeteilt. Wird dies zusammen mit
-O forward eingesetzt, dann wird der zugewiesene
Port auf die Standardausgabe geschrieben.
-S
SteuerpfadControlPath und
ControlMaster in ssh_config(5)
für Details.
-s-T-t-t erzwingen die TTY-Zuweisung, selbst wenn
ssh kein lokales TTY hat.
-V-vssh Fehlersuchmeldungen über seinen
Fortschritt ausgibt. Dies ist für die Fehlersuche bei Verbindungs-,
Authentifizierungs- und Konfigurationsproblemen hilfreich. Mehrere
Optionen -v erhöhen die
Ausführlichkeit. Das Maximum ist 3.
-W
Rechner:Port-N, -T,
ExitOnForwardFailure und
ClearAllForwardings, allerdings können
diese in der Konfigurationsdatei oder mittels der Befehlszeilenoptionen
-o außer Kraft gesetzt werden.
-w
lokaler_Tun[:ferner_Tun]Die Geräte können über numerische
Kennungen oder das Schlüsselwort “any”, das das
nächste verfügbare Tunnelgerät verwendet, angegeben
werden. Falls ferner_Tun nicht angegeben ist, ist
die Vorgabe “any”. Siehe auch die Direktiven
Tunnel und TunnelDevice
in ssh_config(5).
Falls die Direktive Tunnel nicht
gesetzt ist, wird sie auf den Standard-Tunnel-Modus (
“point-to-point”) gesetzt. Falls ein anderer
Tunnel -Weiterleitungsmodus gewünscht
ist, kann er vor -w angegeben werden.
-XX11-Weiterleitung sollte mit Vorsicht aktiviert werden. Benutzer, die auf dem fernen Rechner die Dateiberechtigungen umgehen können (für die X-Autorisierungs-Datenbank), können durch die weitergeleitete Verbindung auf das lokale X11-Display zugreifen. Ein Angreifer könnte dann in der Lage sein, Aktivitäten wie die Überwachung der Eingabe durchzuführen.
Aus diesem Grund unterliegt X11-Weiterleitung
standardmäßig den X11-SECURITY-Erweiterungen. Bitte lesen
Sie für weitere Informationen die Beschreibung der Option
ssh -Y und der Direktive
ForwardX11Trusted in
ssh_config(5).
(Debian-spezifisch: X11-Weiterleitung unterliegt derzeit
standardmäßig nicht den Einschränkungen der
X11-SECURITY-Erweiterungen, da derzeit zu viele Programme in diesem
Modus abstürzen. Setzen Sie die Option
ForwardX11Trusted auf “no”, um das
von den Originalautoren beabsichtigte Verhalten wiederherzustellen. Dies
kann sich abhängig von den Verbesserungen bei den Clients in der
Zukunft ändern.)
-x-Y(Debian-spezifisch: In der Standardkonfiguration ist diese
Option zu -X äquivalent, da wie oben
beschrieben ForwardX11Trusted
standardmäßig “yes” ist. Setzen Sie die
Option ForwardX11Trusted auf “no”,
um das von den Originalautoren beabsichtigte Verhalten
wiederherzustellen. Dies kann sich abhängig von den
Verbesserungen bei den Clients in der Zukunft ändern.)
-yssh kann zusätzliche
Konfigurationsdaten aus einer benutzerbezogenen Konfigurationsdatei und der
systemweiten Konfigurationsdatei erhalten. Das Dateiformat und die
Konfigurationsoptionen sind in ssh_config(5)
beschrieben.
Der OpenSSH-SSH-Client unterstützt SSH-Protokoll 2.
Die für die Authentifizierung unterstützten Methoden
sind: GSSAPI-basierte Authentifzierung, Rechner-basierte Authentifizierung,
asymmetrische Authentifizierung, Challenge-Response-Authentifizierung und
Passwort-Authentifzierung. Die Authentifizierungsmethoden werden in der oben
angegebenen Reihenfolge versucht, diese kann aber durch
PreferredAuthentications geändert werden.
Rechner-basierte Authentifizierung arbeitet wie folgt: Falls die Maschine, bei der sich der Benutzer anmeldet, in /etc/hosts.equiv oder /etc/ssh/shosts.equiv auf der fernen Maschine aufgeführt ist, der Benutzer nicht root ist und die Benutzernamen auf beiden Seiten übereinstimmen, oder falls die Dateien ~/.rhosts oder ~/.shosts in dem Home-Verzeichnis des Benutzers auf der fernen Maschine existieren und eine Zeile enthalten, die den Namen der Client-Maschine und den Namen des Benutzers auf dieser Maschine enthält, wird der Benutzer für die Anmeldung in Betracht gezogen. Zusätzlich muss der Server in der Lage sein, den Rechner-Schlüssel des Clients zu überprüfen (siehe die nachfolgende Beschreibung von /etc/ssh/ssh_known_hosts und ~/.ssh/known_hosts), damit die Anmeldung erlaubt wird. Diese Authentifzierungsmethode schließt Sicherheitslücken aufgrund von Fälschungen der IP, des DNS und des Routings. [Hinweis an den Administrator: /etc/hosts.equiv, ~/.rhosts und das Rlogin-/Rsh-Protokoll im Allgemeinen sind von Natur aus unsicher und sollten deaktiviert werden, falls Sicherheit gewünscht ist.]
Asymmetrische Authentifizierung funktioniert wie folgt: Das Schema
basiert auf asymmetrischer Kryptographie unter Verwendung von
Kryptosystemen, bei denen Ver- und Entschlüsselung mittels getrennter
Schlüssel erfolgt und es undurchführbar ist, den
Entschlüsselungsschlüssel aus dem
Verschlüsselungsschlüssel abzuleiten. Die Idee ist, dass jeder
Benutzer ein öffentliches/privates Schlüsselpaar für
Authentifizierungszwecke erstellt. Der Server kennt den öffentlichen
Schlüssel und nur der Benutzer kennt den privaten Schlüssel.
ssh implementiert automatisch ein asymmetrisches
Authentifzierungsprotokoll und verwendet entweder den DSA-, ECDSA-, Ed25519-
oder den RSA-Algorithmus. Der Abschnitt HISTORY von ssl(8)
enthält eine kurze Erörterung der DSA- und RSA-Algorithmen.
Auf nicht-OpenBS-Systemen, siehe:
http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8#HISTORY)
Die Datei ~/.ssh/authorized_keys
führt die öffentlichen Schlüssel auf, die für
die Anmeldung erlaubt sind. Wenn sich der Benutzer anmeldet, teilt das
ssh -Programm dem Server das Schlüsselpaar
mit, das es für die Authentifizierung verwenden möchte. Der
Client weist nach, dass er Zugriff auf den privaten Schlüssel hat und
der Server prüft, dass der entsprechende öffentliche
Schlüssel authorisiert ist, das Konto zu akzeptieren.
Der Server kann den Client über Fehler informieren, die
eine erfolgreiche asymmetrische Authentifizierung verhindern, nachdem die
Authentifizierung mit einer anderen Methode erfolgreich war. Diese Fehler
können durch Erhöhen des LogLevel auf
DEBUG oder höher (z.B. durch die Verwendung
des Schalters -v) eingesehen werden.
Der Benutzer erstellt sein/ihr Schlüsselpaar durch Ausführung von ssh-keygen(1). Dadurch wird der private Schlüssel in ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (Authentifikator-basierende ECDSA), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (Authentifikator-basierende Ed25519) oder ~/.ssh/id_rsa (RSA) und speichert den öffentlichen Schlüssel in ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (Authentifikator-basierende ECDSA), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (Authentifikator-basierende Ed25519) oder ~/.ssh/id_rsa.pub (RSA) im Home-Verzeichnis des Benutzers. Der Benutzer sollte dann seinen öffentlichen Schlüssel nach ~/.ssh/authorized_keys in seinem/ihrem Home-Verzeichnis auf der fernen Maschinen kopieren. Die Datei authorized_keys entspricht der konventionellen Datei ~/.rhosts und enthält einen Schlüssel pro Zeile, die allerdings sehr lang sein kann. Danach kann sich der Benutzer ohne Angabe eines Passworts anmelden.
Eine Variation der asymmetrischen Authentifizierung ist in der Form der Zertifikatsauthentifizierung verfügbar: Statt eines Satzes von öffentlichen/privaten Schlüsseln werden signierte Zertifikate verwandt. Dies hat den Vorteil, das einer einzelnen, vertrauenswürdigen Stelle anstatt vieler Paare von öffentlichen/privaten Schlüsseln vertraut werden kann. Siehe den Abschnitt ZERTIFIKATE in ssh-keygen(1) für weitere Informationen.
Der bequemste Weg, asymmetrische oder
Zertifikats-Authentifizierung zu verwenden, kann über einen
Authentifizierungs-Vermittler sein. Siehe ssh-agent(1) und
(optional) die Direktive AddKeysToAgent in
ssh_config(5) für weitere Informationen.
Challenge-Response-Authentifizierung funktioniert wie folgt: Der Server sendet einen beliebigen "Challenge" -Text und erbittet eine Antwort. Beispiele für Challenge-Response sind BSD -Authentifizierung (siehe login.conf(5)) und PAM (einige nicht-OpenBSD -Systeme).
Am Ende, wenn auch die anderen Authentifizierungsmethoden
fehlgeschlagen sein sollten, bittet ssh den Benutzer
um seinem Passwort. Das Passwort wird an den fernen Rechner zur
Überprüfung gesandt. Da aber sämtliche Kommunikation
verschlüsselt ist, kann das Passwort von jemanden, der am Netzwerk
mitliest, nicht gesehen werden.
ssh verwaltet und überprüft
automatisch eine Datenbank, die Identifikationen für alle Rechner
enthalten, mit denen es bisher verwandt wurde. Rechnerschlüssel
werden in ~/.ssh/known_hosts im Home-Verzeichnis des
Benutzers gespeichert. Zusätzlich wird die Datei
/etc/ssh/ssh_known_hosts auf bekannte Rechner
überprüft. Jeder neue Rechner wird automatisch zu der Datei
des Benutzers hinzugefügt. Falls sich die Identifikation eines
Rechners jemals ändert, warnt ssh und
deaktiviert Passwort-Authentifizierung, um Server-Fälschung oder
man-in-the-middle-Angriffe zu vermeiden, die andernfalls zum Umgehen der
Verschlüsselung verwandt werden könnten. Die Option
StrictHostKeyChecking kann zum Steuern von
Anmeldungen an Maschinen, deren Rechnerschlüssel neu ist oder sich
geändert hat, verwandt werden.
Wenn die Benutzeridentität vom Server akzeptiert wurde, führt der Server entweder die übergebenen Befehle in einer nichtinteraktiven Sitzung aus oder, falls kein Befehl angegeben wurde, meldet er sich bei der Maschine an und übergibt dem Benutzer eine normale Shell als interaktive Sitzung. Sämtliche Kommunikation mit dem fernen Befehl oder der Shell wird automatisch verschlüsselt.
Falls eine interaktive Sitzung erbeten wird, wird
ssh standardmäßig nur dann ein
Pseudo-Terminal (PTY) für die interaktive Sitzung erbitten, wenn der
Client auch eines hat. Die Schalter -T und
-t können dazu verwandt werden, dieses
Verhalten außer Kraft zu setzen.
Falls ein Pseudo-Terminal zugewiesen wurde, kann der Benutzer die nachfolgend dargestellten Maskierungszeichen verwenden.
Falls kein Pseudo-Terminal reserviert wurde, ist die Sitzung transparent und kann zur zuverlässigen Übertragung beliebiger binärer Daten verwandt werden. Auf den meisten Systemen wird die Sitzung auch durch Setzen des Maskierzeichens auf “none” transparent, selbst wenn ein TTY verwandt wird.
Die Sitzung wird beendet, wenn sich der Befehl oder die Shell auf der fernen Maschine beendet und alle X11- und TCP-Sitzungen geschlossen wurden.
Wenn ein Pseudo-Terminal erbeten wurde, unterstützt
ssh eine Reihe von Funktionen durch die Anwendung
eines Maskierzeichens.
Eine einzelne Tilde kann mittels ~~
gesandt werden oder indem der Tilde ein Zeichen folgt, das sich von den im
Folgenden genannten unterscheidet. Das Maskierzeichen muss immer einem
Zeilenumbruch folgen, um als besonders interpretiert zu werden. Das
Maskierzeichen kann in Konfigurationsdateien mittels der
Konfigurationsdirektive EscapeChar oder auf der
Befehlszeile mit der Option -e geändert
werden.
Die unterstützten Maskierungen (es wird die Vorgabe
‘~’ angenommen) sind:
~.~^Zssh in den Hintergrund schieben.~#~&ssh beim Abmelden in den Hintergrund schieben,
wenn auf die Beendigung weitergeleiteter / X11-Sitzungen gewartet
wird.~?~B~C-L, -R und
-D. Es erlaubt auch den Abbruch bestehender
Port-Weiterleitungen mit
-KL[Anbindeadresse:]Port
für lokale,
-KR[Anbindeadresse:]Port
für ferne und
-KD[Anbindeadresse:]Port
für dynamische Port-Weiterleitungen.
!Befehl erlaubt es dem
Benutzer, einen lokalen Befehl auszuführen, falls die Option
PermitLocalCommand in
ssh_config(5) aktiviert ist. Grundlegende Hilfe ist mit
der Option -h verfügbar.~R~VLogLevel), wenn Fehler auf die
Standardfehlerausgabe geschrieben werden.~vLogLevel), wenn Fehler auf die
Standardfehlerausgabe geschrieben werden.Die Weiterleitung von beliebigen TCP-Verbindungen über einen sicheren Kanal kann entweder auf der Befehlszeile angegeben oder in einer Konfigurationsdatei festgelegt werden. Eine mögliche Anwendung der TCP-Weiterleitung ist die sichere Verbindung zu einem E-Mail-Server, eine andere das Durchtunneln von Firewalls.
Im nachfolgenden Beispiel wird eine verschlüsselte
Verbindung für einen IRC-Client betrachtet, obwohl der IRC-Server, zu
dem die Verbindung aufgebaut wird, direkt keine verschlüsselte
Kommunikation unterstützt. Dies funktioniert wie folgt: der Benutzer
verbindet sich mit dem fernen Rechner mittels ssh
und gibt dabei die Ports an, die für das Weiterleiten der Verbindung
verwandt werden sollen. Danach ist es möglich, das Programm lokal zu
starten und ssh wird die Verbindung zum fernen
Server verschlüsseln und weiterleiten.
Das nachfolgende Beispiel tunnelt eine IRC-Sitzung vom Client zu einem IRC-Server auf “server.example.com”, tritt Kanal “#users” bei, verwendet den Nicknamen “pinky” und den Standard-IRC-Port 6667:
$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10 $ irc -c '#users' pinky IRC/127.0.0.1
Die Option -f schiebt
ssh in den Hintergrund und der ferne Befehl
“sleep 10” wird angegeben, um eine bestimmte Zeitspanne (im
Beispiel 10 Sekunden) für das Starten des Programms, das den Tunnel
benutzen wird, zu erlauben. Falls innerhalb der angegebenen Zeit keine
Verbindungen erfolgen, wird sich ssh beenden.
Falls die Variable ForwardX11 auf
“yes” gesetzt ist (siehe oben für die Beschreibung der
Optionen -X, -x und
-Y) und der Benutzer X11 verwendet (die
Umgebungsvariable DISPLAY ist gesetzt), dann wird
die Verbindung zum X11-Display automatisch an die ferne Seite
weitergeleitet. Dies erfolgt dergestalt, dass alle von der Shell (oder dem
Befehl) gestarteten Programme durch den verschlüsselten Kanal
geleitet und die Verbindung zum dem echten X-Server von der lokalen Maschine
ausgeht. Der Benutzer sollte DISPLAY nicht manuell
setzen. Die Weiterleitung von X11-Verbindungen kann auf der Befehlszeile
oder in Konfigurationsdateien konfiguriert werden.
Der durch ssh gesetzte Wert für
DISPLAY wird auf die Server-Maschine zeigen, aber
mit einer Displaynummer, die größer als Null ist. Dies ist
normal und passiert, da ssh einen
“proxy” -X-Server auf der Server-Maschine für die
Weiterleitung der Verbindungen über den verschlüsselten Kanal
erstellt.
ssh wird auch automatisch Xauthority-Daten
auf der Server-Maschine einrichten. Zu diesem Zweck wird es ein
zufälliges Autorisierungs-Cookie erstellen, dies in Xauthority auf
dem Server speichern und überprüfen, dass alle
weitergeleiteten Verbindungen dieses Cookie tragen und dieses dann durch das
echte Cookie ersetzen, wenn die Verbindung geöffnet wird. Das echte
Authentifizierungs-Cookie wird niemals an den Server gesandt (und keine
Cookies werden im Klartext gesandt).
Falls die Variable ForwardAgent auf
“yes” gesetzt ist (siehe die Beschreibung der Optionen
-A und -a weiter oben) und
der Benutzer einen Authentifizierungsvermittler verwendet, wird die
Verbindung zum Vermittler automatisch zur fernen Seite weitergeleitet.
Bei der erstmaligen Verbindung zu einem Server wird dem Benutzer
ein Fingerabdruck des öffentlichen Schlüssels des Servers
angezeigt (außer die Option
StrictHostKeyChecking wurde deaktiviert).
Fingerabdrücke können mittels ssh-keygen(1)
ermittelt werden:
$ ssh-keygen -l -f
/etc/ssh/ssh_host_rsa_keyFalls der Fingerabdruck bereits bekannt ist, kann er verglichen
und der Schlüssel akzeptiert oder zurückgewiesen werden. Falls
nur veraltete (MD5) Fingerabdrücke für den Server
verfügbar sind, kann die Option -E von
ssh-keygen(1) verwandt werden, um den
Fingerabdruck-Algorithmus zum Vergleichen herunterzustufen.
Da es schwierig ist, Rechnerschlüssel nur durch
Anschauen von Fingerabdruck-Zeichenketten zu vergleichen, wird auch der
visuelle Vergleich mittels
Random Art
(ASCII-Visualisierung) unterstützt. Wird die Option
VisualHostKey auf “yes” gesetzt, dann
wird bei jeder Anmeldung an einem Server eine kleine ASCII-Graphik
angezeigt, unabhängig davon, ob die Sitzung selbst interaktiv ist
oder nicht. Indem der Benutzer das vom Rechner verwandte Muster lernt, kann
er leicht herausfinden, wenn sich der Rechnerschlüssel
geändert hat und ein komplett anderes Muster angezeigt wird. Da diese
Muster aber nicht eindeutig sind, wird ein Muster, das einem Muster aus der
Erinnerung ähnlich sieht, nur eine gute Wahrscheinlichkeit
dafür geben, dass der Rechnerschlüssel unverändert ist,
kein garantierter Beweis.
Um zusammen mit der zufälligen Kunst die Fingerabdrücke für alle bekannten Rechner anzuzeigen, kann folgender Befehl verwandt werden:
$ ssh-keygen -lv -f
~/.ssh/known_hostsFalls ein Fingerabdruck unbekannt ist, ist eine alternative Methode zur Überprüfung verfügbar: Durch DNS-bestätigte SSH-Fingerabdrücke. Ein zusätzlicher Ressourcendatensatz (RR), SSHFP, wird zu einer Zonendatei hinzugefügt und der verbindende Client ist in der Lage, den Fingerabdruck mit dem angebotenen zu vergleichen.
In diesem Beispiel findet eine Verbindung eines Clients mit einem Server “host.example.com” statt. Die SSHFP-Ressourcendatensätze sollten zuerst zu der Zonendatei für host.example.com hinzugefügt werden:
$ ssh-keygen -r host.example.com.
Die Ausgabezeilen müssen zur der Zonendatei hinzugefügt werden. So überprüfen Sie, ob die Zone auf Fingerabdruckanfragen antwortet:
$ dig -t SSHFP
host.example.comSchießlich verbindet sich der Client:
$ ssh -o "VerifyHostKeyDNS ask" host.example.com […] Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
Lesen Sie die Option VerifyHostKeyDNS in
ssh_config(5) für weitere Informationen.
ssh unterstützt „Virtual
Private Network“- (VPN-)Tunneln mittels des tun(4)
-Netzwerk-Pseudogerätes. Damit wird es möglich, zwei Netzwerke
sicher zu verbinden. Die Konfigurationsoption
PermitTunnel von sshd_config(5)
steuert, ob und falls ja auf welcher Stufe (Layer 2- oder 3-Verkehr) der
Server dies unterstützt.
Das folgende Beispiel würde das Client-Netzwerk 10.0.50.0/24 mit dem fernen Netzwerk 10.0.99.0/24 unter Verwendung einer Punkt-zu-Punkt-Verbindung von 10.1.1.1 nach 10.1.1.2 verbinden, vorausgesetzt, dass der auf dem Gateway zu dem fernen Netzwerk laufende SSH-Server, auf 192.168.1.15, dies erlauben würde:
Auf dem Client:
# ssh -f -w 0:1 192.168.1.15 true # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 # route add 10.0.99.0/24 10.1.1.2
Auf dem Server:
# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 # route add 10.0.50.0/24 10.1.1.1
Der Client-Zugriff kann mittels der nachfolgend beschriebenen
Datei /root/.ssh/authorized_keys und der
Server-Option PermitRootLogin feiner gesteuert
werden. Der folgende Eintrag würde Verbindungen auf dem
tun(4) -Gerät 1 von Benutzer “jane”
und auf dem Tun-Gerät 2 von Benutzer “john” erlauben,
falls PermitRootLogin auf
“forced-commands-only” gesetzt ist:
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa … jane tunnel="2",command="sh /etc/netstart tun2" ssh-rsa … john
Da eine SSH-basierte-Installation einen ordentlichen Aufwand verursacht, könnte sie mehr für temporäre Installationen, wie für drahtlose VPNs, geeignet sein. Dauerhafte VPNs werden besser durch Werkzeuge wie ipsecctl(8) und isakmpd(8) bereitgestellt.
ssh setzt normalerweise die folgenden
Umgebungsvariablen:
DISPLAYDISPLAY zeigt den Ort des X11-Servers
an. Sie wird von ssh automatisch gesetzt, um auf
einen Wert der Form “Rechnername:n” zu zeigen, wobei
“Rechnername” den Rechnernamen anzeigt, auf dem die Shell
läuft und ‘n’ eine Ganzzahl ≥ 1 ist.
ssh verwendet diesen besonderen Wert, um
X11-Verbindungen über den sicheren Kanal weiterzuleiten. Der
Benutzer sollte normalerweise DISPLAY nicht
explizit setzen, da dies zu einer unsicheren X11-Verbindung führen
wird (und verlangt, dass der Benutzer sämtliche
Autorisierungs-Cookies manuell kopiert).HOMELOGNAMEUSER; wird zur
Kompatibilität mit Systemen, die diese Variable verwenden,
gesetzt.MAILPATHPATH gesetzt, wie er bei
der Kompilierung von ssh festgelegt wurde.SSH_ASKPASSssh eine Passphrase benötigt, so wird
diese aus dem aktuellen Terminal gelesen, falls es von einem Terminal
gestartet wurde. Falls ssh kein Terminal
zugeordnet ist, aber DISPLAY und
SSH_ASKPASS gesetzt sind, dann wird es das durch
SSH_ASKPASS festgelegte Programm ausführen
und ein X11-Fenster öffnen, um die Passphrase einzulesen. Dies ist
insbesondere nützlich, wenn ssh von einer
.xsession oder einem zugehörigen Skript
aufgerufen wird. (Beachten Sie, dass Sie auf einigen Maschinen die Eingabe
von /dev/null umleiten müssen, damit dieses
funktioniert.)SSH_ASKPASS_REQUIREssh
niemals versuchen, ein solches Programm zu verwenden. Falls sie auf
“prefer” gesetzt ist, dann wird ssh
es vorziehen, das Programm zur Abfrage von Passwörtern statt einem
TTY zu verwenden, wenn Passwörter erbeten werden. Falls diese
Variable schließlich auf “force” gesetzt ist, dann
wird das Programm zur Abfrage von Passwörtern für alle
Passphrasen verwandt, unabhängig davon, ob
DISPLAY gesetzt ist.SSH_AUTH_SOCKSSH_CONNECTIONSSH_ORIGINAL_COMMANDSSH_TTYSSH_TUNNELSSH_USER_AUTHTZUSERZusätzlich liest ssh
~/.ssh/environment und fügt Zeilen im Format
“VARIABLENNAME=Wert” zu der Umgebung hinzu, falls die Datei
existiert und Benutzer ihre Umgebung ändern dürfen. Für
weitere Informationen siehe die Option
PermitUserEnvironment in
sshd_config(5).
ssh wird eine Datei mit einem privaten
Schlüssel ignorieren, falls andere darauf zugreifen können.
Es ist bei der Erstellung des Schlüssels möglich, eine
Passphrase festzulegen, die zur Verschlüsselung des sensitiven
Anteils dieser Datei mittels AES-128 verwandt wird.
ssh
ausgeführt, wenn sich der Benutzer anmeldet, genau bevor die Shell
(oder der Befehl) des Benutzers gestartet wird. Lesen Sie die
Handbuchseite sshd(8) für weitere Informationen.
ssh
ausgeführt, wenn sich der Benutzer anmeldet, genau bevor die Shell
(oder der Befehl) des Benutzers gestartet wird. Lesen Sie die
Handbuchseite sshd(8) für weitere
Informationen.ssh beendet sich mit dem Exit-Status des
fernen Befehls oder mit 255, falls ein Fehler aufgetreten ist.
scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)
S. Lehtinen and C. Lonvick, Die zugewiesenen Protokollnummern der Secure Shell (SSH), RFC 4250, Januar 2006.
T. Ylonen and C. Lonvick, Die Architektur des Protokolls der Secure Shell (SSH), RFC 4251, Januar 2006.
T. Ylonen and C. Lonvick, Das Authentifizierungsprotokoll der Secure Shell (SSH), RFC 4252, Januar 2006.
T. Ylonen and C. Lonvick, Das Transportebenenprotokoll der Secure Shell (SSH), RFC 4253, Januar 2006.
T. Ylonen and C. Lonvick, Das Verbindungsprotokoll der Secure Shell (SSH), RFC 4254, Januar 2006.
J. Schlyter and W. Griffin, Verwendung von DNS zur sicheren Veröffentlichung von Fingerabdrücken von Schlüsseln der Secure Shell (SSH), RFC 4255, Januar 2006.
F. Cusack and M. Forssen, Generische Nachrichtenaustausch-Authentifizierung für das Secure-Shell-Protokoll (SSH), RFC 4256, Januar 2006.
J. Galbraith and P. Remaker, Die Sitzungsaufbrech-Erweiterungen der Secure Shell (SSH), RFC 4335, Januar 2006.
M. Bellare, T. Kohno, and C. Namprempre, Die Transportebenen-Verschlüsselungsmodi der Secure Shell (SSH), RFC 4344, Januar 2006.
B. Harris, Verbesserte Arcfour-Modi für das Transportebenen-Protokoll der Secure Shell (SSH), RFC 4345, Januar 2006.
M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Gruppen-Austausch für das Transportebenen-Protokoll der Secure Shell (SSH), RFC 4419, März 2006.
J. Galbraith and R. Thayer, Das Format der öffentlichen Schlüssel der Secure Shell (SSH), RFC 4716, November 2006.
D. Stebila and J. Green, Integration der Elliptische-Kurven-Algorithmen in die Transportebene der Secure Shell, RFC 5656, Dezember 2009.
A. Perrig and D. Song, Hash-Darstellung: eine neue Technik zur Verbesserung von Sicherheit in der realen Welt, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).
OpenSSH ist eine Ableitung der ursprünglichen und freien SSH-1.2.12-Veröffentlichung durch Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt und Dug Song entfernten viele Fehler, fügten neuere Funktionalitäten wieder hinzu und erstellten OpenSSH. Markus Friedl steuerte die Unterstützung für SSH-Protokollversion 1.5 und 2.0 bei.
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer
| $Mdocdate: 15. Juli 2020 $ | Debian |