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
       Markierung] [-p Port] [-R Adresse] [-S Steuerpfad] [-W Rechner:Port] [-w  lokaler_Tun[:ferner_Tun]]  Ziel
       [Befehl [Argument …]] ssh [-Q Abfrageoption]

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 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 und ~/.ssh/id_ed25519_sk. 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. IPv6-Adressen können
angegeben werden, indem sie in eckige Klammern eingeschlossen 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), »proxy« (zu einem laufenden
Multiplexing-Master im Proxy-Modus verbinden), »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
EnableEscapeCommandline
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
RequiredRSASize
SendEnv
ServerAliveInterval
ServerAliveCountMax
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation

-P Markierung
Gibt einen Markierungsnamen an, der zur Auswahl der Konfiguration in ssh_config(5) verwandt
werden kann. Für weitere Informationen siehe die Schlüsselwörter Tag und Match in 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-ca-sign (gültige CA-Signaturealgorithmen für Zertifikate), 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.

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 ECDSA-, Ed25519- oder den RSA-Algorithmus.

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

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 .

Debian                                           18. Juli, 2024                                           SSH(1)