Ubuntu Manpage: ssh — OpenSSH-Client zur Anmeldung in der Ferne

BEZEICHNUNG

     ssh — OpenSSH-Client zur Anmeldung in der Ferne

ÜBERSICHT

     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 …]]

BESCHREIBUNG

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.

-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 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).

AddKeysToAgent
AddressFamily
BatchMode
BindAddress
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CASignatureAlgorithms
CertificateFile
CheckHostIP
Ciphers
ClearAllForwardings
Compression
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
ControlPersist
DynamicForward
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForkAfterAuthentication
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GatewayPorts
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIKeyExchange
GSSAPIClientIdentity
GSSAPIDelegateCredentials
GSSAPIKexAlgorithms
GSSAPIRenewalForcesRekey
GSSAPIServerIdentity
GSSAPITrustDns
HashKnownHosts
Host
HostbasedAcceptedAlgorithms
HostbasedAuthentication
HostKeyAlgorithms
HostKeyAlias
Hostname
IdentitiesOnly
IdentityAgent
IdentityFile
IPQoS
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LocalCommand
LocalForward
LogLevel
MACs
Match
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PermitLocalCommand
PermitRemoteOpen
PKCS11Provider
Port
PreferredAuthentications
ProxyCommand
ProxyJump
ProxyUseFdpass
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RemoteCommand
RemoteForward
RequestTTY
SendEnv
ServerAliveInterval
ServerAliveCountMax
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation

-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 Versionnummer an und beendet sich.

-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.

AUTHENTIFIZIERUNG

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.

MASKIERZEICHEN

     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.

TCP-WEITERLEITUNG

     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.

X11-WEITERLEITUNG

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.

RECHNERSCHLÜSSEL ÜBERPRÜFEN

     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-BASIERTE VIRTUELLE PRIVATE NETZWERKE

     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.

UMGEBUNGSVARIABLEN

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).

DATEIEN

~/.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.

EXIT-STATUS

     ssh beendet sich mit dem Exit-Status des fernen Befehls oder mit 255, falls ein Fehler
     aufgetreten ist.

SIEHE AUCH

     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)

STANDARDS

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).

AUTOREN

     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.

ÜBERSETZUNG

     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: https://www.gnu.org/licenses/gpl-3.0.html 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: debian-l10n-german@lists.debian.org .