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
[Argument
…]]
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 er auf dem
fernen Rechner statt in einer Anmelde-Shell ausgeführt. Als
Befehl kann eine komplette Befehlszeile
angegeben werden oder er kann zusätzliche Argumente haben. Falls
angegeben, werden die Argumente an den Befehl, durch Leerzeichen getrennt,
angehängt, bevor er an den Server zur Ausführung gesandt wird.
Folgende Optionen stehen zur Verfügung:
- -4
- Erzwingt, dass ssh nur
IPv4-Adressen verwendet.
- -6
- Erzwingt, dass ssh nur
IPv6-Adressen verwendet.
- -A
- Aktiviert die Weiterleitung von Verbindungen von
Authentifizierungsvermittlern wie
ssh-agent(1). Dies kann in einer
Konfigurationsdatei auch pro-Rechner separat festgelegt werden.
Vermittlerweiterleitung 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
- Deaktiviert die Weiterleitung der
Authentifizierungsverbindung des Vermittlers.
-
-B
Anbindeschnittstelle
- Bindet an die Adresse aus
Anbindeschnittstelle an, bevor versucht
wird, sich mit dem Zielrechner zu verbinden. Dies ist nur auf Systemen mit
mehr als einer Adresse nützlich.
-
-b
Anbindeadresse
- Verwendet Anbindeadresse
auf der lokalen Maschine als Quelladresse der Verbindung. Dies ist nur auf
Systemen mit mehr als einer Adresse nützlich.
- -C
- Fordert die Komprimierung sämtlicher Daten
(einschließlich Stdin, Stdout, Stderr und über X11, TCP und
UNIX-domain -Verbindungen weitergeleitete Daten).
Der Kompressionsalgorithmus ist der gleiche, den auch
gzip(1) nutzt. Die Komprimierung eignet sich
für Modemleitungen und andere langsame Anbindungen, wird die
Verbindung aber in schnellen Netzwerken nur ausbremsen. Der Vorgabewert
kann für jeden Rechner separat in den Konfigurationsdateien
eingestellt werden; siehe die Option
Compression in
ssh_config(5).
-
-c
Chiffrespez
- Wählt die Chiffrespezifikation für die
Verschlüsselung der Verbindung aus.
Chiffrespez ist eine durch Kommata
getrennte Liste von Chiffren, in der Reihenfolge der Bevorzugung. Siehe
das Schlüsselwort Ciphers in
ssh_config(5) für weitere
Informationen.
-
-D
[Anbindeadresse:]Port
- Legt eine lokale, “dynamische”,
anwendungsbezogene Port-Weiterleitung fest. Dazu wird ein Socket
bereitgestellt, der auf Port auf der
lokalen Seite auf Anfragen wartet und optional an die angegebene
Anbindeadresse angebunden wird. Immer
wenn eine Verbindung zu diesem Port aufgebaut wird, wird diese Verbindung
über den sicheren Kanal weitergeleitet und das Anwendungsprotokoll
wird dann verwandt, um zu bestimmen, wohin auf der fernen Maschine
verbunden werden soll. Derzeit werden die SOCKS4- und SOCKS5-Protokolle
unterstützt und ssh 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
- Hängt Fehlersuchprotokolle an
Protokolldatei statt an die
Standardfehlerausgabe an.
-
-e
Maskierzeichen
- Setzt das Maskierzeichen für die Sitzung mit einem
PTY (Vorgabe: ‘
~
’). 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
- Legt eine alternative, benutzerbezogene Konfigurationsdatei
fest. Falls eine Konfigurationsdatei auf der Befehlszeile angegeben ist,
wird die systemweite Konfigurationsdatei
(/etc/ssh/ssh_config) ignoriert. Die Vorgabe
für die benutzerbezogene Konfigurationsdatei ist
~/.ssh/config. Wird sie auf
“none” gesetzt, dann wird keine Konfigurationsdatei
eingelesen.
- -f
- Fordert ssh auf, 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.
Schauen Sie in die Beschreibung von
ForkAfterAuthentication in
ssh_config(5) für Details.
- -G
- Führt dazu, dass ssh
nach der Auswertung der Blöcke Host
und Match seine Konfiguration anzeigt und
sich beendet.
- -g
- Erlaubt es fernen Rechnern, sich mit lokal weitergeleiteten
Ports zu verbinden. Wird dies auf einer multiplexten Verbindung verwandt,
dann muss diese Option beim Master-Prozess eingesetzt werden.
-
-I
PKCS11
- Gibt die dynamische PKCS#11-Bibliothek an, die
ssh für die Kommunikation mit einem
PKCS#11-Token verwenden soll, der Schlüssel für die
Benutzerauthentifizierung bereitstellt.
-
-i
Identitätsdatei
- Wählt eine Datei, aus der die Identität (der
private Schlüssel) für asymmetrische Authentifizierung
gelesen wird. Sie können auch festlegen, dass eine
öffentliche Schlüsseldatei den entsprechenden privaten
Schlüssel verwendet, der in
ssh-agent(1) geladen wird, wenn die private
Schlüsseldatei nicht lokal verfügbar ist. Die Vorgabe ist
~/.ssh/id_rsa,
~/.ssh/id_ecdsa,
~/.ssh/id_ecdsa_sk,
~/.ssh/id_ed25519,
~/.ssh/id_ed25519_sk und
~/.ssh/id_dsa. Identitätsdateien
können auch auf einer rechnerbezogenen Basis in der
Konfigurationsdatei festgelegt werden. Es ist auch möglich, mehrere
Optionen -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
Ziel
- Verbindet sich zum Zielrechner, indem
ssh 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
- Aktiviert GSSAPI-basierte Authentifizierung und
Weiterleitung (Delegierung) von GSSAPI-Anmeldedaten an den Server.
- -k
- Deaktiviert Weiterleitung (Delegierung) von
GSSAPI-Anmeldedaten an den Server.
-
-L
[Anbindeadresse:]Port:Rechner:Rechnerport
-
-
-L
[Anbindeadresse:]Port:fernes_Socket
-
-
-L
lokales_Socket:Rechner:Rechnerport
-
-
-L
lokales_Socket:Rechner
- Gibt an, dass Verbindungen zu dem angegebenen TCP-Port oder
Unix-Socket auf dem lokalen (Client-)Rechner an den angegeben Rechner und
Port oder Unix-Socket auf der fernen Seite weitergeleitet werden soll.
Dies funktioniert durch Zuweisung eines Ports, der entweder auf einen TCP-
Port auf der lokalen Seite, optional an
die angegebene Anbindeadresse angebunden,
oder auf einem Unix-Socket auf Anfragen wartet. Immer wenn eine Verbindung
zu dem lokalen Port oder Socket erfolgt, wird die Verbindung über
den sicheren Kanal weitergeleitet und es erfolgt entweder eine Verbindung
zu dem Port des Rechners
Rechnerport oder zum dem Unix-Socket
fernes_Socket auf der fernen Maschine.
Port-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
- Gibt den Benutzernamen an, unter dem die Anmeldung in der
fernen Maschine erfolgen soll. Dies kann auch rechnerbezogen in der
Konfigurationsdatei festgelegt werden.
- -M
- Bringt den ssh -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_Spez
- Eine Kommata-getrennte Liste von MAC-
(Nachrichtenauthentifizierungscodes-)Algorithmen, in der Reihenfolge der
Präferenz angegeben. Siehe das Schlüsselwort
MAC in
ssh_config(5) für weitere
Informationen.
- -N
- Führt keinen Befehl in der Ferne aus. Dies ist
nützlich, wenn nur Ports weitergeleitet werden. Schauen Sie in die
Beschreibung von SessionType in
ssh_config(5) für Details.
- -n
- Leitet Stdin nach /dev/null um
(tätsächlich wird des Lesen von Stdin verhindert). Dies muss
verwandt werden, wenn ssh 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.)
Schauen Sie in die Beschreibung von StdinNull
in ssh_config(5) für Details.
-
-O
Steuerbefehl
- Steuert einen aktiven Master-Prozess für
Verbindungs-Multiplexing. Wird die Option -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
- Kann zur Angabe von Optionen, die wie in der
Konfigurationsdatei formatiert sind, verwandt werden. Dies ist
nützlich, um Optionen anzugeben, für die es keinen separaten
Befehlszeilenschalter gibt. Für vollständige Details
über die nachfolgend aufgeführten Optionen und ihre
möglichen Werte siehe ssh_config(5).
-
-p
Port
- Port, zu dem beim fernen Rechner verbunden werden soll.
Dies kann rechnerbasiert in der Konfigurationsdatei festgelegt werden.
-
-Q
Abfrageoption
- Erfragt die Algorithmen, die von einem der folgenden
Funktionalitäten unterstützt werden:
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
- Stiller Modus. Damit werden die meisten Warnungen und
Diagnosemeldungen unterdrückt.
-
-R
[Anbindeadresse:]Port:Rechner:Rechnerport
-
-
-R
[Anbindeadresse:]Port:lokales_Socket
-
-
-R
fernes_Socket:Rechner:Rechnerport
-
-
-R
fernes_Socket:lokales_Socket
-
-
-R
[Anbindeadresse:]Port
- Gibt an, dass Verbindungen zum dem angegebenen TCP-Port
oder Unix-Socket auf dem fernen Rechner (Server) an die lokale Seite
weitergeleitet werden sollen.
Dazu 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
Rechnerport 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
Steuerpfad
- Gibt den Ort eines Steuer-Sockets für die gemeinsame
Verwendung von Verbindungen oder die Zeichenkette “none” an,
um die gemeinsame Verwendung von Verbindungen zu deaktivieren. Lesen Sie
die Beschreibung von ControlPath und
ControlMaster in
ssh_config(5) für Details.
- -s
- Kann dazu verwandt werden, um das Starten eines Subsystems
auf dem fernen System zu erbitten. Subsysteme ermöglichen die
Verwendung von SSH als sicheren Transport für andere Anwendungen
(z.B. sftp(1)). Das Subsystem wird als der
ferne Befehl angegeben. Schauen Sie in die Beschreibung von
SessionType in
ssh_config(5) für Details.
- -T
- Deaktiviert Pseudo-Terminal-Zuweisung.
- -t
- Erzwingt Pseudo-Terminal-Zuweisung. Dies kann zur
Ausführung mehrerer, auf Screen-basierter Programme auf fernen
Maschinen verwandt werden. Dies kann zur Implementierung von
beispielsweise Menü-Diensten sehr nützlich sein. Mehrere
Optionen -t erzwingen die TTY-Zuweisung,
selbst wenn ssh kein lokales TTY hat.
- -V
- Zeigt die Version an und beendet das Programm.
- -v
- Ausführlicher Modus. Führt dazu, dass
ssh 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
- Fordert, dass die Standardein- und -ausgabe auf dem Client
an Rechner auf
Port über den sicheren Kanal
weitergeleitet wird. Impliziert -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]
- Fordert Tunnelgerät-Weiterleitung mit den
angegebenen tun(4) -Geräten zwischen
dem Client (lokaler_Tun) und dem Server
(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.
- -X
- Aktiviert X11-Weiterleitung. Dies kann auch rechnerbezogen
in der Konfigurationsdatei festgelegt werden.
X11-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. 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
- Deaktiviert X11-Weiterleitung.
- -Y
- Aktiviert vertrauenswürdige X11-Weiterleitung.
Vertrauenswürdige X11-Weiterleitungen unterliegen nicht den
Maßnahmen der X11-SECURITY-Erweiterungen.
(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.)
- -y
- Sendet mittels des Systemmoduls
syslog(3) Protokollinformationen.
Standardmäßig werden diese Informationen auf die Stderr
gesandt.
ssh 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, interaktive Tastatur-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.
Interaktive Tastatur-Authentifizierung funktioniert wie folgt: Der Server sendet
einen beliebigen “Challenge” -Text und erbittet eine Antwort,
möglicherweise mehrfach. Beispiele für interaktive
Tastatur-Authentifizierung 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:
- ~.
- Verbindung trennen.
- ~^Z
-
ssh in den Hintergrund
schieben.
- ~#
- Weitergeleitete Verbindungen auflisten.
- ~&
-
ssh beim Abmelden in den
Hintergrund schieben, wenn auf die Beendigung weitergeleiteter /
X11-Sitzungen gewartet wird.
- ~?
- Eine Liste von Maskierzeichen anzeigen.
- ~B
- Einen BREAK an das ferne System senden (nur
nützlich, wenn die Gegenstelle das unterstützt).
- ~C
- Eine Befehlzeile öffnen. Derzeit erlaubt dies das
Hinzufügen von Port-Weiterleitungen mittels der (oben
beschriebenen) Optionen -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
- Neue Schlüsselaushandlung der Verbindung erbitten
(nur nützlich, wenn die Gegenstelle das unterstützt).
- ~V
- Verringert die Ausführlichkeit von
(LogLevel), wenn Fehler auf die
Standardfehlerausgabe geschrieben werden.
- ~v
- Erhöht die Ausführlichkeit von
(LogLevel), 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 (oder 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_key
Falls 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_hosts
Falls 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.com
Schieß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:
DISPLAY
- Die Variable
DISPLAY
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).
HOME
- Wird auf den Pfad zum Home-Verzeichnis des Benutzers
gesetzt.
LOGNAME
- Synonym für
USER
;
wird zur Kompatibilität mit Systemen, die diese Variable verwenden,
gesetzt.
MAIL
- Wird auf den Pfad zu dem Postfach des Benutzers
gesetzt.
PATH
- Wird auf den Standard-
PATH
gesetzt, wie er bei der
Kompilierung von ssh festgelegt wurde.
SSH_ASKPASS
- Falls ssh 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_REQUIRE
- Erlaubt genauere Kontrolle über die Verwendung eines
Programms zur Abfrage von Passwörtern. Falls diese Variable auf
“never” gesetzt ist, dann wird
ssh 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_SOCK
- Kennzeichnet den Pfad eines zur Kommunikation mit dem
Vermittler verwandten UNIX-domain -Sockets.
SSH_CONNECTION
- Identifiziert die Client- und Server-Enden der Verbindung.
Die Variable enthält vier durch Leerzeichen getrennte Werte:
Client-IP-Adresse, Client-Port-Nummer, Server-IP-Adresse und
Server-Port-Nummer.
SSH_ORIGINAL_COMMAND
- Diese Variable enthält die ursprüngliche
Befehlszeile, falls ein erzwungener Befehl ausgeführt wird. Sie
kann zum Herauslösen der ursprünglichen Argumente verwandt
werden.
SSH_TTY
- Dies ist auf den Namen des TTY (Pfad zu dem Gerät)
gesetzt, das der aktuellen Shell oder dem Befehl zugeordnet ist. Falls die
aktuelle Sitzung über kein TTY verfügt, ist diese Variable
nicht gesetzt.
SSH_TUNNEL
- Optional durch sshd(8)
gesetzt, um den zugewiesenen Schnittstellennamen zu enthalten, falls vom
Client die Weiterleitung von Tunneln erbeten wurde.
SSH_USER_AUTH
- Optional durch sshd(8)
gesetzt. Diese Variable kann einen Pfadnamen zu einer Datei enthalten, die
die Authentifizierungsmethoden enthält, die erfolgreich verwandt
wurden, als die Sitzung etabliert wurde, einschließlich aller
verwandten öffentlichen Schlüssel.
TZ
- Diese Variable wird gesetzt, um die aktuelle Zeitzone
anzuzeigen, falls sie gesetzt war, als der Deamon gestartet wurde (d.h.
der Daemon gibt den Wert an neue Verbindungen weiter).
USER
- Wird auf den Namen des angemeldeten Benutzers gesetzt.
Zusä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).
- ~/.rhosts
- Diese Datei wird für Rechner-basierte
Authentifizierung (siehe oben) verwandt. Auf einigen Maschinen muss diese
Datei für alle schreibbar sein, falls das Home-Verzeichnis des
Benutzers sich auf einer NFS-Partition befindet, da
sshd(8) sie als root einliest.
Zusätzlich muss diese Datei dem Benutzer gehören und darf
für keinen anderen Schreibberechtigung haben. Die empfohlenen
Berechtigungen für die meisten Maschinen ist Lesen/Schreiben
für den Benutzer und kein Zugriff für andere.
- ~/.shosts
- Die Datei wird genau auf die gleiche Art wie
.rhosts verwandt, erlaubt aber
Rechner-basierte Authentifizierung, ohne Anmeldungen mittels Rlogin/Rsh zu
ermöglichen.
- ~/.ssh/
- Das Verzeichnis ist der Standardort für alle
benutzerspezifischen Konfigurations- und Authentifizierungsinformationen.
Es gibt keine allgemeine Anforderung, sämtliche Informationen in
diesem Verzeichnis geheim zu halten, aber die empfohlenen Berechtigungen
sind Lesen/Schreiben/Ausführen für den Benutzer und kein
Zugriff für andere.
- ~/.ssh/authorized_keys
- Listet die öffentlichen Schlüssel (DSA,
ECDSA, Ed25519, RSA) auf, die zur Anmeldung als Benutzer verwandt werden
können. Das Format dieser Datei ist in der Handbuchseite
sshd(8) beschrieben. Diese Datei ist nicht
sehr sensitiv, aber die empfohlenen Berechtigungen sind Lesen/Schreiben
für den Benutzer und kein Zugriff für andere.
- ~/.ssh/config
- Dies ist die benutzerbezogene Konfiguration. Das
Dateiformat und die Konfigurationsoptionen sind in
ssh_config(5) beschrieben. Aufgrund der
Missbrauchsmöglichkeit müssen die Berechtigungen der Datei
sehr streng sein: Lesen/Schreiben für den Benutzer und kein
Schreibzugriff für andere. Sie kann für die Gruppe
schreibbar sein, solange die in Frage stehende Gruppe nur den Benutzer
enthält.
- ~/.ssh/environment
- Enthält zusätzliche Definitionen für
Umgebungsvariablen; siehe
UMGEBUNGSVARIABLEN,
oben.
- ~/.ssh/id_dsa
-
- ~/.ssh/id_ecdsa
-
- ~/.ssh/id_ecdsa_sk
-
- ~/.ssh/id_ed25519
-
- ~/.ssh/id_ed25519_sk
-
- ~/.ssh/id_rsa
- Enthält den privaten Schlüssel für die
Authentifizierung. Diese Datei enthält sensitive Daten und sollte
nur durch den Benutzer lesbar sein, aber andere sollten nicht drauf
zugreifen können (lesen/schreiben/ausführen).
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/id_dsa.pub
-
- ~/.ssh/id_ecdsa.pub
-
- ~/.ssh/id_ecdsa_sk.pub
-
- ~/.ssh/id_ed25519.pub
-
- ~/.ssh/id_ed25519_sk.pub
-
- ~/.ssh/id_rsa.pub
- Enthält den öffentlichen Schlüssel
für die Authentifizierung. Diese Dateien sind nicht sensitiv und
können (müssen aber nicht) von jedem lesbar sein.
- ~/.ssh/known_hosts
- Enthält eine Liste von Rechnerschlüsseln
für alle Rechner, bei denen sich der Benutzer angemeldet hat und
die nicht bereits in der systemweiten Liste der bekannten
Rechnerschlüssel sind. Siehe sshd(8)
für weitere Details über das Format dieser Datei.
- ~/.ssh/rc
- Befehle in dieser Datei werden durch
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.
- /etc/hosts.equiv
- Diese Datei ist für rechnerbasierte
Authentifizierung (siehe oben). Sie sollte nur durch Root beschreibbar
sein.
- /etc/ssh/shosts.equiv
- Die Datei wird genau auf die gleiche Art wie
hosts.equiv verwandt, erlaubt aber
Rechner-basierte Authentifizierung, ohne Anmeldungen mittels Rlogin/Rsh zu
ermöglichen.
- /etc/ssh/ssh_config
- Systemweite Konfigurationsdatei. Das Dateiformat und die
Konfigurationsoptionen werden in
ssh_config(5) beschrieben.
- /etc/ssh/ssh_host_key
-
- /etc/ssh/ssh_host_dsa_key
-
- /etc/ssh/ssh_host_ecdsa_key
-
- /etc/ssh/ssh_host_ed25519_key
-
- /etc/ssh/ssh_host_rsa_key
- Diese Dateien enthalten den privaten Anteil der
Rechnerschlüssel und werden für rechnerbasierte
Authentifizierung verwandt.
- /etc/ssh/ssh_known_hosts
- Systemweite Liste der bekannten Rechnerschlüssel.
Diese Datei sollte vom Systemadministrator erstellt werden, um die
Rechnerschlüssel aller Maschinen der Organisation zu enthalten. Sie
sollte von allen lesbar sein. Siehe sshd(8)
für weitere Details über das Format dieser Datei.
- /etc/ssh/sshrc
- Befehle in dieser Datei werden durch
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-Gruppenaustausch 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
<
[email protected]> 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:
[email protected]