ssh

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]

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 dieser auf der fernen Maschine statt
     einer Anmelde-Shell ausgeführt.

     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      Erbittet 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      Erbittet von ssh, 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.

     -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. Die Vorgabe ist
             ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk,
             ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk und ~/.ssh/id_rsa.
             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.

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

     -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
                   ChallengeResponseAuthentication
                   CheckHostIP
                   Ciphers
                   ClearAllForwardings
                   Compression
                   ConnectionAttempts
                   ConnectTimeout
                   ControlMaster
                   ControlPath
                   ControlPersist
                   DynamicForward
                   EscapeChar
                   ExitOnForwardFailure
                   FingerprintHash
                   ForwardAgent
                   ForwardX11
                   ForwardX11Timeout
                   ForwardX11Trusted
                   GatewayPorts
                   GlobalKnownHostsFile
                   GSSAPIAuthentication
                   GSSAPIDelegateCredentials
                   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
                   SetEnv
                   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
             Fragt ssh nach den für die festgelegte Version 2 unterstützten
             Algorithmen. Die verfügbaren Funktionalitäten sind: cipher
             (unterstützte symmetrische Chiffren), cipher-auth (unterstützte
             symmetrische Chiffren, die authentifizierte Verschlüsselung
             unterstützen), help (die für den Einsatz mit dem Schalter -Q
             unterstützten Abfrageausdrücke), mac (unterstützte
             Nachrichtenintegritätscodes), kex (Schlüssel-Austauschalgorithmen),
             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 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.

     -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
             Erbittet, 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]
             Erbittet 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. Bitte lesen Sie für weitere
             Informationen die Beschreibung der Option ssh -Y und der Direktive
             ForwardX11Trusted in ssh_config(5).

     -x      Deaktiviert X11-Weiterleitung.

     -Y      Aktiviert vertrauenswürdige X11-Weiterleitung. Vertrauenswürdige
             X11-Weiterleitungen unterliegen nicht den Maßnahmen der
             X11-SECURITY-Erweiterungen.

     -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, Challenge-Response-Authentifizierung und Passwort-
     Authentifzierung. Die Authentifizierungsmethoden werden in der oben
     angegebenen Reihenfolge versucht, diese kann aber durch
     PreferredAuthentications geändert werden.

     Rechner-basierte Authentifizierung arbeitet wie folgt: Falls die Maschine,
     bei der sich der Benutzer anmeldet, in /etc/hosts.equiv oder
     /etc/ssh/shosts.equiv auf der fernen Maschine aufgeführt ist, der Benutzer
     nicht root ist und die Benutzernamen auf beiden Seiten übereinstimmen, oder
     falls die Dateien ~/.rhosts oder ~/.shosts in dem Home-Verzeichnis des
     Benutzers auf der fernen Maschine existieren und eine Zeile enthalten, die
     den Namen der Client-Maschine und den Namen des Benutzers auf dieser
     Maschine enthält, wird der Benutzer für die Anmeldung in Betracht gezogen.
     Zusätzlich muss der Server in der Lage sein, den Rechner-Schlüssel des
     Clients zu überprüfen (siehe die nachfolgende Beschreibung von
     /etc/ssh/ssh_known_hosts und ~/.ssh/known_hosts), damit die Anmeldung
     erlaubt wird. Diese Authentifzierungsmethode schließt Sicherheitslücken
     aufgrund von Fälschungen der IP, des DNS und des Routings. [Hinweis an den
     Administrator: /etc/hosts.equiv, ~/.rhosts und das Rlogin-/Rsh-Protokoll im
     Allgemeinen sind von Natur aus unsicher und sollten deaktiviert werden,
     falls Sicherheit gewünscht ist.]

     Asymmetrische Authentifizierung funktioniert wie folgt: Das Schema basiert
     auf asymmetrischer Kryptographie unter Verwendung von Kryptosystemen, bei
     denen Ver- und Entschlüsselung mittels getrennter Schlüssel erfolgt und es
     undurchführbar ist, den Entschlüsselungsschlüssel aus dem
     Verschlüsselungsschlüssel abzuleiten. Die Idee ist, das 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 Diskussion der DSA- und RSA-Algorithmen.

     Die Datei ~/.ssh/authorized_keys führt die öffentlichen Schlüssel auf, die
     für die Anmeldung erlaubt sind. Wenn sich der Benutzer anmeldet, teilt das
     ssh -Programm dem Server das Schlüsselpaar mit, das es für die
     Authentifizierung verwenden möchte. Der Client weist nach, dass er Zugriff
     auf den privaten Schlüssel hat und der Server prüft, dass der entsprechende
     öffentliche Schlüssel authorisiert ist, das Konto zu akzeptieren.

     Der Server kann den Client über Fehler informieren, die eine erfolgreiche
     asymmetrische Authentifizierung verhindern, nachdem die Authentifizierung
     mit einer anderen Methode erfolgreich war. Diese Fehler können durch
     Erhöhen des LogLevel auf DEBUG oder höher (z.B. durch die Verwendung des
     Schalters -v) eingesehen werden.

     Der Benutzer erstellt sein/ihr Schlüsselpaar durch Ausführung von
     ssh-keygen(1).  Dadurch wird der private Schlüssel in ~/.ssh/id_dsa (DSA),
     ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (Authentifikator-basierende
     ECDSA), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (Authentifikator-
     basierende Ed25519) oder ~/.ssh/id_rsa (RSA) und speichert den öffentlichen
     Schlüssel in ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA),
     ~/.ssh/id_ecdsa_sk.pub (Authentifikator-basierende ECDSA),
     ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (Authentifikator-
     basierende Ed25519) oder ~/.ssh/id_rsa.pub (RSA) im Home-Verzeichnis des
     Benutzers. Der Benutzer sollte dann seinen öffentlichen Schlüssel nach
     ~/.ssh/authorized_keys in seinem/ihrem Home-Verzeichnis auf der fernen
     Maschinen kopieren. Die Datei authorized_keys entspricht der
     konventionellen Datei ~/.rhosts und enthält einen Schlüssel pro Zeile, die
     allerdings sehr lang sein kann. Danach kann sich der Benutzer ohne Angabe
     eines Passworts anmelden.

     Eine Variation der asymmetrischen Authentifizierung ist in der Form der
     Zertifikatsauthentifizierung verfügbar: Statt eines Satzes von
     öffentlichen/privaten Schlüsseln werden signierte Zertifikate verwandt.
     Dies hat den Vorteil, das einer einzelnen, vertrauenswürdigen Stelle
     anstatt vieler Paare von öffentlichen/privaten Schlüsseln vertraut werden
     kann. Siehe den Abschnitt ZERTIFIKATE in ssh-keygen(1) für weitere
     Informationen.

     Der bequemste Weg, asymmetrische oder Zertifikats-Authentifizierung zu
     verwenden, kann über einen Authentifizierungs-Vermittler sein. Siehe
     ssh-agent(1) und (optional) die Direktive AddKeysToAgent in ssh_config(5)
     für weitere Informationen.

     Challenge-Response-Authentifizierung funktioniert wie folgt: Der Server
     sendet einen beliebigen "Challenge" -Text und erbittet eine Antwort.
     Beispiele für Challenge-Response sind BSD -Authentifizierung (siehe
     login.conf(5)) und PAM (einige nicht-OpenBSD -Systeme).

     Am Ende, wenn auch die anderen Authentifizierungsmethoden fehlgeschlagen
     sein sollten, bittet ssh den Benutzer um seinem Passwort. Das Passwort wird
     an den fernen Rechner zur Überprüfung gesandt. Da aber sämtliche
     Kommunikation verschlüsselt ist, kann das Passwort von jemanden, der am
     Netzwerk mitliest, nicht gesehen werden.

     ssh verwaltet und überprüft automatisch eine Datenbank, die
     Identifikationen für alle Rechner enthalten, mit denen es bisher verwandt
     wurde. Rechnerschlüssel werden in ~/.ssh/known_hosts im Home-Verzeichnis
     des Benutzers gespeichert. Zusätzlich wird die Datei
     /etc/ssh/ssh_known_hosts auf bekannte Rechner überprüft. Jeder neue Rechner
     wird automatisch zu der Datei des Benutzers hinzugefügt. Falls sich die
     Identifikation eines Rechners jemals ändert, warnt ssh und deaktiviert
     Passwort-Authentifizierung, um Server-Fälschung oder man-in-the-middle-
     Angriffe zu vermeiden, die andernfalls zum Umgehen der Verschlüsselung
     verwandt werden könnten. Die Option StrictHostKeyChecking kann zum Steuern
     von Anmeldungen an Maschinen, deren Rechnerschlüssel neu ist oder sich
     geändert hat, verwandt werden.

     Wenn die Benutzeridentität vom Server akzeptiert wurde, führt der Server
     entweder die übergebenen Befehle in einer nichtinteraktiven Sitzung aus
     oder, falls kein Befehl angegeben wurde, meldet er sich bei der Maschine an
     und übergibt dem Benutzer eine normale Shell als interaktive Sitzung.
     Sämtliche Kommunikation mit dem fernen Befehl oder der Shell wird
     automatisch verschlüsselt.

     Falls eine interaktive Sitzung erbeten wird, wird ssh standardmäßig nur
     dann ein Pseudo-Terminal (PTY) für die interaktive Sitzung erbitten, wenn
     der Client auch eines hat. Die Schalter -T und -t können dazu verwandt
     werden, dieses Verhalten außer Kraft zu setzen.

     Falls ein Pseudo-Terminal zugewiesen wurde, kann der Benutzer die
     nachfolgend dargestellten Maskierungszeichen verwenden.

     Falls kein Pseudo-Terminal reserviert wurde, ist die Sitzung transparent
     und kann zur zuverlässigen Übertragung beliebiger binärer Daten verwandt
     werden. Auf den meisten Systemen wird die Sitzung auch durch Setzen des
     Maskierzeichens auf “none” transparent, selbst wenn ein TTY verwandt wird.

     Die Sitzung wird beendet, wenn sich der Befehl oder die Shell auf der
     fernen Maschine beendet und alle X11- und TCP-Sitzungen geschlossen wurden.

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

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

     Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
     <debian@helgefjell.de> erstellt.

     Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public
     License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird
     KEINE HAFTUNG übernommen.

     Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken
     Sie bitte eine E-Mail an die Mailingliste der Übersetzer