SSH(1) General Commands Manual SSH(1) BEZEICHNUNG ssh - OpenSSH-Client zur Anmeldung in der Ferne UBERSICHT ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B Anbindeschnittstelle] [-b Anbindeadresse] [-c Chiffrespez] [-D [Anbindeadresse:]Port] [-E Protokolldatei] [-e Maskierzeichen] [-F Konfigurationsdatei] [-I PKCS11] [-i Identitatsdatei] [-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 Ausfuhrung von Befehlen auf fernen Maschinen. Es ist zur Bereitstellung sicherer, verschlusselter Kommunikation zwischen zwei nicht vertrauenswurdigen Rechnern uber ein unsicheres Netzwerk gedacht. X11-Verbindungen, beliebige TCP-Ports und UNIX-domain -Sockets konnen auch uber 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 Identititat 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 ausgefuhrt. Als Befehl kann eine komplette Befehlszeile angegeben werden oder er kann zusatzliche Argumente haben. Falls angegeben, werden die Argumente an den Befehl, durch Leerzeichen getrennt, angehangt, bevor er an den Server zur Ausfuhrung gesandt wird. Folgende Optionen stehen zur Verfugung: -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 konnen (fur den UNIX-domain -Socket des Vermittlers), konnen auf den lokalen Vermittler uber die weitergeleitete Verbindung zugreifen. Ein Angreifer kann vom Vermittler kein Schlusselmaterial erlangen, allerdings kann er Aktionen unter den Schlusseln ausfuhren, die es ihm ermoglichen, sich unter den im Vermittler geladenen Identitaten zu authentifizieren. Eine sichere Alternative konnte 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 nutzlich. -b Anbindeadresse Verwendet Anbindeadresse auf der lokalen Maschine als Quelladresse der Verbindung. Dies ist nur auf Systemen mit mehr als einer Adresse nutzlich. -C Fordert die Komprimierung samtlicher Daten (einschliesslich Stdin, Stdout, Stderr und uber X11, TCP und UNIX-domain -Verbindungen weitergeleitete Daten). Der Kompressionsalgorithmus ist der gleiche, den auch gzip(1) nutzt. Die Komprimierung eignet sich fur Modemleitungen und andere langsame Anbindungen, wird die Verbindung aber in schnellen Netzwerken nur ausbremsen. Der Vorgabewert kann fur jeden Rechner separat in den Konfigurationsdateien eingestellt werden; siehe die Option Compression in ssh_config(5). -c Chiffrespez Wahlt die Chiffrespezifikation fur die Verschlusselung der Verbindung aus. Chiffrespez ist eine durch Kommata getrennte Liste von Chiffren, in der Reihenfolge der Bevorzugung. Siehe das Schlusselwort Ciphers in ssh_config(5) fur 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 uber 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 unterstutzt und ssh wird als SOCKS- Server auftreten. Nur root kann privilegierte Ports weiterleiten. Dynamische Portweiterleitungen konnen auch in der Konfigurationsdatei festgelegt werden. IPv6-Adressen konnen durch Angabe der Adresse in eckigen Klammern festgelegt werden. Nur der Systemadministrator kann privilegierte Ports weiterleiten. Standardmassig ist der lokale Port gemass 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 fur die lokale Benutzung angebunden ist, wahrend eine leere Adresse oder >>*<< anzeigt, dass der Port an allen Schnittstellen verfugbar sein soll. -E Protokolldatei Hangt Fehlersuchprotokolle an Protokolldatei statt an die Standardfehlerausgabe an. -e Maskierzeichen Setzt das Maskierzeichen fur die Sitzung mit einem PTY (Vorgabe: `~'). Das Maskierzeichen wird nur am Anfang einer Zeile erkannt. Das Maskierzeichen, gefolgt von einem Punkt (`.'), schliesst 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 fur die benutzerbezogene Konfigurationsdatei ist ~/.ssh/config. Wird sie auf "none" gesetzt, dann wird keine Konfigurationsdatei eingelesen. -f Fordert ssh auf, sich vor der Befehlsausfuhrung in den Hintergrund zu schieben. Dies ist nutzlich, falls ssh nach Passwortern oder Passphrasen fragen wird, der Benutzer es aber im Hintergrund ausgefuhrt haben mochte. 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) fur Details. -G Fuhrt dazu, dass ssh nach der Auswertung der Blocke 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 fur die Kommunikation mit einem PKCS#11-Token verwenden soll, der Schlussel fur die Benutzerauthentifizierung bereitstellt. -i Identitatsdatei Wahlt eine Datei, aus der die Identitat (der private Schlussel) fur asymmetrische Authentifizierung gelesen wird. Sie konnen auch festlegen, dass eine offentliche Schlusseldatei den entsprechenden privaten Schlussel verwendet, der in ssh-agent(1) geladen wird, wenn die private Schlusseldatei nicht lokal verfugbar ist. Die Vorgabe ist ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk und ~/.ssh/id_dsa. Identitatsdateien konnen auch auf einer rechnerbezogenen Basis in der Konfigurationsdatei festgelegt werden. Es ist auch moglich, mehrere Optionen -i (und mehrere in Konfigurationsdateien festgelegte Identitaten) einzusetzen. Falls keine Zertifikate explizit durch die Direktive CertificateFile angegeben sind, wird ssh versuchen, die Zertifikatsinformationen aus dem Dateinamen zu laden, der durch Anhangen von -cert.pub an die Identitatsdateinamen 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 endgultigen Ziel etabliert. Mehrere Sprungrechner konnen durch Kommata getrennt angegeben werden. Dies ist eine Abkurzung fur die Verwendung der Konfigurationsdirektive ProxyJump. Beachten Sie, dass auf der Befehlszeile ubergebene Konfigurationsdirektiven sich im Allgemeinen auf den Zielrechner und nicht den angegebenen Sprungrechner beziehen. Verwenden Sie ~/.ssh/config, um Konfiguration fur 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 uber 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 Einschliessen der Adresse in eckige Klammern konnen IPv6-Adressen angegeben werden. Standardmassig ist der lokale Port gemass 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, wahrend eine leere Adresse oder >>*<< anzeigt, dass der Port von allen Schnittstellen aus verfugbar 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 fur die gemeinsame Benutzung von Verbindungen. Durch mehrere Optionen -M wird ssh in den "master" -Modus gebracht, es wird aber eine Bestatigung mit ssh-askpass(1) vor jeder Aktion verlangt, die den Multiplexing- Zustand andert (z.B. Offnen einer neuen Sitzung). Lesen Sie die Beschreibung von ControlMaster in ssh_config(5) fur Details. -m MAC_Spez Eine Kommata-getrennte Liste von MAC- (Nachrichtenauthentifizierungscodes-)Algorithmen, in der Reihenfolge der Praferenz angegeben. Siehe das Schlusselwort MAC in ssh_config(5) fur weitere Informationen. -N Fuhrt keinen Befehl in der Ferne aus. Dies ist nutzlich, wenn nur Ports weitergeleitet werden. Schauen Sie in die Beschreibung von SessionType in ssh_config(5) fur Details. -n Leitet Stdin nach /dev/null um (tatsachlich wird des Lesen von Stdin verhindert). Dies muss verwandt werden, wenn ssh im Hintergrund ausgefuhrt wird. Ein haufiger 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 uber einen verschlusselten 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) fur Details. -O Steuerbefehl Steuert einen aktiven Master-Prozess fur Verbindungs- Multiplexing. Wird die Option -O angegeben, dann wird das Argument Steuerbefehl interpretiert und an den Master-Prozess ubergeben. Gultige Befehle sind: "check" (prufen, ob der Master- Prozess lauft), "forward" (Weiterleitungen ohne Befehlsausfuhrung 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 nutzlich, um Optionen anzugeben, fur die es keinen separaten Befehlszeilenschalter gibt. Fur vollstandige Details uber die nachfolgend aufgefuhrten Optionen und ihre moglichen 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 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 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. Fur weitere Informationen siehe die Schlusselworter 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 Funktionalitaten unterstutzt werden: cipher (unterstutzte symmetrische Chiffren), cipher-auth (unterstutzte symmetrische Chiffren, die authentifizierte Verschlusselung unterstutzen), help (die fur den Einsatz mit dem Schalter -Q unterstutzten Abfrageausdrucke), mac (unterstutzte Nachrichtenintegritatscodes), kex (Schlussel- Austauschalgorithmen), key (Schlusseltypen), key-ca-sign (gultige CA-Signaturealgorithmen fur Zertifikate), key-cert (Zertifikatsschlusseltypen), key-plain (nicht- Zertifikatsschlusseltypen), key-sig (alle Schlusseltypen und Signaturalgorithmen), Protokollversion (unterstutzte SSH- Protokollversionen) und sig (unterstutzte Signaturalgorithmen). Alternativ kann jedes Schlusselwort aus ssh_config(5) und sshd_config(5), das eine Algorithmenliste akzeptiert, als ein Alias fur die entsprechende Abfrageoption verwandt werden. -q Stiller Modus. Damit werden die meisten Warnungen und Diagnosemeldungen unterdruckt. -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 uber den sicheren Kanal weitergeleitet und eine weitere Verbindung erstellt, die zu einem expliziten Ziel fuhrt (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 konnen auch in der Konfigurationsdatei festgelegt werden. Privilegierte Ports konnen nur nach Anmeldung als root auf der fernen Maschine weitergeleitet werden. Durch Einschluss der Adresse in eckige Klammern konnen IPv6-Adressen angegeben werden. Standardmassig werden TCP-Ports auf dem Server, an denen auf Anfragen gewartet wird, nur an die Loopback-Schnittstelle gebunden. Dies kann durch Angabe einer Anbindeadresse ausser 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 fur 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) fur Details. -s Kann dazu verwandt werden, um das Starten eines Subsystems auf dem fernen System zu erbitten. Subsysteme ermoglichen die Verwendung von SSH als sicheren Transport fur 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) fur Details. -T Deaktiviert Pseudo-Terminal-Zuweisung. -t Erzwingt Pseudo-Terminal-Zuweisung. Dies kann zur Ausfuhrung mehrerer, auf Screen-basierter Programme auf fernen Maschinen verwandt werden. Dies kann zur Implementierung von beispielsweise Menu-Diensten sehr nutzlich 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 Ausfuhrlicher Modus. Fuhrt dazu, dass ssh Fehlersuchmeldungen uber seinen Fortschritt ausgibt. Dies ist fur die Fehlersuche bei Verbindungs-, Authentifizierungs- und Konfigurationsproblemen hilfreich. Mehrere Optionen -v erhohen die Ausfuhrlichkeit. Das Maximum ist 3. -W Rechner:Port Fordert, dass die Standardein- und -ausgabe auf dem Client an Rechner auf Port uber den sicheren Kanal weitergeleitet wird. Impliziert -N, -T, ExitOnForwardFailure und ClearAllForwardings, allerdings konnen diese in der Konfigurationsdatei oder mittels der Befehlszeilenoptionen -o ausser Kraft gesetzt werden. -w lokaler_Tun[:ferner_Tun] Fordert Tunnelgerat-Weiterleitung mit den angegebenen tun(4) -Geraten zwischen dem Client (lokaler_Tun) und dem Server (ferner_Tun). Die Gerate konnen uber numerische Kennungen oder das Schlusselwort "any", das das nachste verfugbare Tunnelgerat 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 gewunscht 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 konnen (fur die X-Autorisierungs-Datenbank), konnen durch die weitergeleitete Verbindung auf das lokale X11-Display zugreifen. Ein Angreifer konnte dann in der Lage sein, Aktivitaten wie die Uberwachung der Eingabe durchzufuhren. Aus diesem Grund unterliegt X11-Weiterleitung standardmassig den X11-SECURITY-Erweiterungen. Lesen Sie fur weitere Informationen die Beschreibung der Option ssh -Y und der Direktive ForwardX11Trusted in ssh_config(5). -x Deaktiviert X11-Weiterleitung. -Y Aktiviert vertrauenswurdige X11-Weiterleitung. Vertrauenswurdige X11-Weiterleitungen unterliegen nicht den Massnahmen der X11-SECURITY-Erweiterungen. -y Sendet mittels des Systemmoduls syslog(3) Protokollinformationen. Standardmassig werden diese Informationen auf die Stderr gesandt. ssh kann zusatzliche 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 unterstutzt SSH-Protokoll 2. Die fur die Authentifizierung unterstutzten 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 geandert 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 aufgefuhrt ist, der Benutzer nicht root ist und die Benutzernamen auf beiden Seiten ubereinstimmen, 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 enthalt, wird der Benutzer fur die Anmeldung in Betracht gezogen. Zusatzlich muss der Server in der Lage sein, den Rechner-Schlussel des Clients zu uberprufen (siehe die nachfolgende Beschreibung von /etc/ssh/ssh_known_hosts und ~/.ssh/known_hosts), damit die Anmeldung erlaubt wird. Diese Authentifzierungsmethode schliesst Sicherheitslucken aufgrund von Falschungen 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 gewunscht ist.] Asymmetrische Authentifizierung funktioniert wie folgt: Das Schema basiert auf asymmetrischer Kryptographie unter Verwendung von Kryptosystemen, bei denen Ver- und Entschlusselung mittels getrennter Schlussel erfolgt und es undurchfuhrbar ist, den Entschlusselungsschlussel aus dem Verschlusselungsschlussel abzuleiten. Die Idee ist, das jeder Benutzer ein offentliches/privates Schlusselpaar fur Authentifizierungszwecke erstellt. Der Server kennt den offentlichen Schlussel und nur der Benutzer kennt den privaten Schlussel. ssh implementiert automatisch ein asymmetrisches Authentifzierungsprotokoll und verwendet entweder den DSA-, ECDSA-, Ed25519- oder den RSA- Algorithmus. Der Abschnitt HISTORY von ssl(8) enthalt eine kurze Diskussion der DSA- und RSA-Algorithmen. Die Datei ~/.ssh/authorized_keys fuhrt die offentlichen Schlussel auf, die fur die Anmeldung erlaubt sind. Wenn sich der Benutzer anmeldet, teilt das ssh -Programm dem Server das Schlusselpaar mit, das es fur die Authentifizierung verwenden mochte. Der Client weist nach, dass er Zugriff auf den privaten Schlussel hat und der Server pruft, dass der entsprechende offentliche Schlussel authorisiert ist, das Konto zu akzeptieren. Der Server kann den Client uber Fehler informieren, die eine erfolgreiche asymmetrische Authentifizierung verhindern, nachdem die Authentifizierung mit einer anderen Methode erfolgreich war. Diese Fehler konnen durch Erhohen des LogLevel auf DEBUG oder hoher (z.B. durch die Verwendung des Schalters -v) eingesehen werden. Der Benutzer erstellt sein/ihr Schlusselpaar durch Ausfuhrung von ssh-keygen(1). Dadurch wird der private Schlussel 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 offentlichen Schlussel 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 offentlichen Schlussel nach ~/.ssh/authorized_keys in seinem/ihrem Home-Verzeichnis auf der fernen Maschinen kopieren. Die Datei authorized_keys entspricht der konventionellen Datei ~/.rhosts und enthalt einen Schlussel 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 verfugbar: Statt eines Satzes von offentlichen/privaten Schlusseln werden signierte Zertifikate verwandt. Dies hat den Vorteil, das einer einzelnen, vertrauenswurdigen Stelle anstatt vieler Paare von offentlichen/privaten Schlusseln vertraut werden kann. Siehe den Abschnitt ZERTIFIKATE in ssh-keygen(1) fur weitere Informationen. Der bequemste Weg, asymmetrische oder Zertifikats-Authentifizierung zu verwenden, kann uber einen Authentifizierungs-Vermittler sein. Siehe ssh-agent(1) und (optional) die Direktive AddKeysToAgent in ssh_config(5) fur weitere Informationen. Interaktive Tastatur-Authentifizierung funktioniert wie folgt: Der Server sendet einen beliebigen "Challenge" -Text und erbittet eine Antwort, moglicherweise mehrfach. Beispiele fur 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 Uberprufung gesandt. Da aber samtliche Kommunikation verschlusselt ist, kann das Passwort von jemanden, der am Netzwerk mitliest, nicht gesehen werden. ssh verwaltet und uberpruft automatisch eine Datenbank, die Identifikationen fur alle Rechner enthalten, mit denen es bisher verwandt wurde. Rechnerschlussel werden in ~/.ssh/known_hosts im Home-Verzeichnis des Benutzers gespeichert. Zusatzlich wird die Datei /etc/ssh/ssh_known_hosts auf bekannte Rechner uberpruft. Jeder neue Rechner wird automatisch zu der Datei des Benutzers hinzugefugt. Falls sich die Identifikation eines Rechners jemals andert, warnt ssh und deaktiviert Passwort-Authentifizierung, um Server-Falschung oder man-in- the-middle-Angriffe zu vermeiden, die andernfalls zum Umgehen der Verschlusselung verwandt werden konnten. Die Option StrictHostKeyChecking kann zum Steuern von Anmeldungen an Maschinen, deren Rechnerschlussel neu ist oder sich geandert hat, verwandt werden. Wenn die Benutzeridentitat vom Server akzeptiert wurde, fuhrt der Server entweder die ubergebenen Befehle in einer nichtinteraktiven Sitzung aus oder, falls kein Befehl angegeben wurde, meldet er sich bei der Maschine an und ubergibt dem Benutzer eine normale Shell als interaktive Sitzung. Samtliche Kommunikation mit dem fernen Befehl oder der Shell wird automatisch verschlusselt. Falls eine interaktive Sitzung erbeten wird, wird ssh standardmassig nur dann ein Pseudo-Terminal (PTY) fur die interaktive Sitzung erbitten, wenn der Client auch eines hat. Die Schalter -T und -t konnen dazu verwandt werden, dieses Verhalten ausser 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 zuverlassigen Ubertragung beliebiger binarer 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, unterstutzt 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 geandert werden. Die unterstutzten 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 nutzlich, wenn die Gegenstelle das unterstutzt). ~C Eine Befehlzeile offnen. Derzeit erlaubt dies das Hinzufugen von Port-Weiterleitungen mittels der (oben beschriebenen) Optionen -L, -R und -D. Es erlaubt auch den Abbruch bestehender Port- Weiterleitungen mit -KL[Anbindeadresse:]Port fur lokale, -KR[Anbindeadresse:]Port fur ferne und -KD[Anbindeadresse:]Port fur dynamische Port-Weiterleitungen. !Befehl erlaubt es dem Benutzer, einen lokalen Befehl auszufuhren, falls die Option PermitLocalCommand in ssh_config(5) aktiviert ist. Grundlegende Hilfe ist mit der Option -h verfugbar. ~R Neue Schlusselaushandlung der Verbindung erbitten (nur nutzlich, wenn die Gegenstelle das unterstutzt). ~V Verringert die Ausfuhrlichkeit von (LogLevel), wenn Fehler auf die Standardfehlerausgabe geschrieben werden. ~v Erhoht die Ausfuhrlichkeit von (LogLevel), wenn Fehler auf die Standardfehlerausgabe geschrieben werden. TCP-WEITERLEITUNG Die Weiterleitung von beliebigen TCP-Verbindungen uber einen sicheren Kanal kann entweder auf der Befehlszeile angegeben oder in einer Konfigurationsdatei festgelegt werden. Eine mogliche Anwendung der TCP- Weiterleitung ist die sichere Verbindung zu einem E-Mail-Server, eine andere das Durchtunneln von Firewalls. Im nachfolgenden Beispiel wird eine verschlusselte Verbindung fur einen IRC-Client betrachtet, obwohl der IRC-Server, zu dem die Verbindung aufgebaut wird, direkt keine verschlusselte Kommunikation unterstutzt. Dies funktioniert wie folgt: der Benutzer verbindet sich mit dem fernen Rechner mittels ssh und gibt dabei die Ports an, die fur das Weiterleiten der Verbindung verwandt werden sollen. Danach ist es moglich, das Programm lokal zu starten und ssh wird die Verbindung zum fernen Server verschlusseln 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) fur 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 fur 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 verschlusselten 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 fur DISPLAY wird auf die Server-Maschine zeigen, aber mit einer Displaynummer, die grosser als Null ist. Dies ist normal und passiert, da ssh einen "proxy" -X-Server auf der Server- Maschine fur die Weiterleitung der Verbindungen uber den verschlusselten Kanal erstellt. ssh wird auch automatisch Xauthority-Daten auf der Server-Maschine einrichten. Zu diesem Zweck wird es ein zufalliges Autorisierungs-Cookie erstellen, dies in Xauthority auf dem Server speichern und uberprufen, dass alle weitergeleiteten Verbindungen dieses Cookie tragen und dieses dann durch das echte Cookie ersetzen, wenn die Verbindung geoffnet 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. RECHNERSCHLUSSEL UBERPRUFEN Bei der erstmaligen Verbindung zu einem Server wird dem Benutzer ein Fingerabdruck des offentlichen Schlussels des Servers angezeigt (ausser die Option StrictHostKeyChecking wurde deaktiviert). Fingerabdrucke konnen 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 Schlussel akzeptiert oder zuruckgewiesen werden. Falls nur veraltete (MD5) Fingerabdrucke fur den Server verfugbar sind, kann die Option -E von ssh-keygen(1) verwandt werden, um den Fingerabdruck-Algorithmus zum Vergleichen herunterzustufen. Da es schwierig ist, Rechnerschlussel nur durch Anschauen von Fingerabdruck-Zeichenketten zu vergleichen, wird auch der visuelle Vergleich mittels Random Art (ASCII-Visualisierung) unterstutzt. Wird die Option VisualHostKey auf "yes" gesetzt, dann wird bei jeder Anmeldung an einem Server eine kleine ASCII-Graphik angezeigt, unabhangig 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 Rechnerschlussel geandert hat und ein komplett anderes Muster angezeigt wird. Da diese Muster aber nicht eindeutig sind, wird ein Muster, das einem Muster aus der Erinnerung ahnlich sieht, nur eine gute Wahrscheinlichkeit dafur geben, dass der Rechnerschlussel unverandert ist, kein garantierter Beweis. Um zusammen mit der zufalligen Kunst die Fingerabdrucke fur 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 Uberprufung verfugbar: Durch DNS-bestatigte SSH-Fingerabdrucke. Ein zusatzlicher Ressourcendatensatz (RR), SSHFP, wird zu einer Zonendatei hinzugefugt 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-Ressourcendatensatze sollten zuerst zu der Zonendatei fur host.example.com hinzugefugt werden: $ ssh-keygen -r host.example.com. Die Ausgabezeilen mussen zur der Zonendatei hinzugefugt werden. So uberprufen Sie, ob die Zone auf Fingerabdruckanfragen antwortet: $ dig -t SSHFP host.example.com Schiesslich 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) fur weitere Informationen. SSH-BASIERTE VIRTUELLE PRIVATE NETZWERKE ssh unterstutzt ,,Virtual Private Network"- (VPN-)Tunneln mittels des tun(4) -Netzwerk-Pseudogerates. Damit wird es moglich, 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 unterstutzt. Das folgende Beispiel wurde 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 wurde: 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 wurde Verbindungen auf dem tun(4) -Gerat 1 von Benutzer "jane" und auf dem Tun-Gerat 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, konnte sie mehr fur temporare Installationen, wie fur 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 lauft und >>n<< eine Ganzzahl >= 1 ist. ssh verwendet diesen besonderen Wert, um X11-Verbindungen uber den sicheren Kanal weiterzuleiten. Der Benutzer sollte normalerweise DISPLAY nicht explizit setzen, da dies zu einer unsicheren X11-Verbindung fuhren wird (und verlangt, dass der Benutzer samtliche Autorisierungs-Cookies manuell kopiert). HOME Wird auf den Pfad zum Home-Verzeichnis des Benutzers gesetzt. LOGNAME Synonym fur USER; wird zur Kompatibilitat 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 benotigt, 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 ausfuhren und ein X11-Fenster offnen, um die Passphrase einzulesen. Dies ist insbesondere nutzlich, wenn ssh von einer .xsession oder einem zugehorigen Skript aufgerufen wird. (Beachten Sie, dass Sie auf einigen Maschinen die Eingabe von /dev/null umleiten mussen, damit dieses funktioniert.) SSH_ASKPASS_REQUIRE Erlaubt genauere Kontrolle uber die Verwendung eines Programms zur Abfrage von Passwortern. 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 Passwortern statt einem TTY zu verwenden, wenn Passworter erbeten werden. Falls diese Variable schliesslich auf "force" gesetzt ist, dann wird das Programm zur Abfrage von Passwortern fur alle Passphrasen verwandt, unabhangig 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 enthalt vier durch Leerzeichen getrennte Werte: Client-IP-Adresse, Client-Port-Nummer, Server-IP-Adresse und Server- Port-Nummer. SSH_ORIGINAL_COMMAND Diese Variable enthalt die ursprungliche Befehlszeile, falls ein erzwungener Befehl ausgefuhrt wird. Sie kann zum Herauslosen der ursprunglichen Argumente verwandt werden. SSH_TTY Dies ist auf den Namen des TTY (Pfad zu dem Gerat) gesetzt, das der aktuellen Shell oder dem Befehl zugeordnet ist. Falls die aktuelle Sitzung uber kein TTY verfugt, 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 enthalt, die erfolgreich verwandt wurden, als die Sitzung etabliert wurde, einschliesslich aller verwandten offentlichen Schlussel. 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. Zusatzlich liest ssh ~/.ssh/environment und fugt Zeilen im Format "VARIABLENNAME=Wert" zu der Umgebung hinzu, falls die Datei existiert und Benutzer ihre Umgebung andern durfen. Fur weitere Informationen siehe die Option PermitUserEnvironment in sshd_config(5). DATEIEN ~/.rhosts Diese Datei wird fur Rechner-basierte Authentifizierung (siehe oben) verwandt. Auf einigen Maschinen muss diese Datei fur alle schreibbar sein, falls das Home-Verzeichnis des Benutzers sich auf einer NFS-Partition befindet, da sshd(8) sie als root einliest. Zusatzlich muss diese Datei dem Benutzer gehoren und darf fur keinen anderen Schreibberechtigung haben. Die empfohlenen Berechtigungen fur die meisten Maschinen ist Lesen/Schreiben fur den Benutzer und kein Zugriff fur andere. ~/.shosts Die Datei wird genau auf die gleiche Art wie .rhosts verwandt, erlaubt aber Rechner-basierte Authentifizierung, ohne Anmeldungen mittels Rlogin/Rsh zu ermoglichen. ~/.ssh/ Das Verzeichnis ist der Standardort fur alle benutzerspezifischen Konfigurations- und Authentifizierungsinformationen. Es gibt keine allgemeine Anforderung, samtliche Informationen in diesem Verzeichnis geheim zu halten, aber die empfohlenen Berechtigungen sind Lesen/Schreiben/Ausfuhren fur den Benutzer und kein Zugriff fur andere. ~/.ssh/authorized_keys Listet die offentlichen Schlussel (DSA, ECDSA, Ed25519, RSA) auf, die zur Anmeldung als Benutzer verwandt werden konnen. Das Format dieser Datei ist in der Handbuchseite sshd(8) beschrieben. Diese Datei ist nicht sehr sensitiv, aber die empfohlenen Berechtigungen sind Lesen/Schreiben fur den Benutzer und kein Zugriff fur andere. ~/.ssh/config Dies ist die benutzerbezogene Konfigurationsdatei. Das Dateiformat und die Konfigurationsoptionen sind in ssh_config(5) beschrieben. Aufgrund der Missbrauchsmoglichkeit mussen die Berechtigungen der Datei sehr streng sein: Lesen/Schreiben fur den Benutzer und kein Schreibzugriff fur andere. ~/.ssh/environment Enthalt zusatzliche Definitionen fur Umgebungsvariablen; siehe UMGEBUNGSVARIABLEN, oben. ~/.ssh/id_dsa ~/.ssh/id_ecdsa ~/.ssh/id_ecdsa_sk ~/.ssh/id_ed25519 ~/.ssh/id_ed25519_sk ~/.ssh/id_rsa Enthalt den privaten Schlussel fur die Authentifizierung. Diese Datei enthalt sensitive Daten und sollte nur durch den Benutzer lesbar sein, aber andere sollten nicht drauf zugreifen konnen (lesen/schreiben/ausfuhren). ssh wird eine Datei mit einem privaten Schlussel ignorieren, falls andere darauf zugreifen konnen. Es ist bei der Erstellung des Schlussels moglich, eine Passphrase festzulegen, die zur Verschlusselung 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 Enthalt den offentlichen Schlussel fur die Authentifizierung. Diese Dateien sind nicht sensitiv und konnen (mussen aber nicht) von jedem lesbar sein. ~/.ssh/known_hosts Enthalt eine Liste von Rechnerschlusseln fur alle Rechner, bei denen sich der Benutzer angemeldet hat und die nicht bereits in der systemweiten Liste der bekannten Rechnerschlussel sind. Siehe sshd(8) fur weitere Details uber das Format dieser Datei. ~/.ssh/rc Befehle in dieser Datei werden durch ssh ausgefuhrt, wenn sich der Benutzer anmeldet, genau bevor die Shell (oder der Befehl) des Benutzers gestartet wird. Lesen Sie die Handbuchseite sshd(8) fur weitere Informationen. /etc/hosts.equiv Diese Datei ist fur 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 ermoglichen. /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 Rechnerschlussel und werden fur rechnerbasierte Authentifizierung verwandt. /etc/ssh/ssh_known_hosts Systemweite Liste der bekannten Rechnerschlussel. Diese Datei sollte vom Systemadministrator erstellt werden, um die Rechnerschlussel aller Maschinen der Organisation zu enthalten. Sie sollte von allen lesbar sein. Siehe sshd(8) fur weitere Details uber das Format dieser Datei. /etc/ssh/sshrc Befehle in dieser Datei werden durch ssh ausgefuhrt, wenn sich der Benutzer anmeldet, genau bevor die Shell (oder der Befehl) des Benutzers gestartet wird. Lesen Sie die Handbuchseite sshd(8) fur 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 Veroffentlichung von Fingerabdrucken von Schlusseln der Secure Shell (SSH), RFC 4255, Januar 2006. F. Cusack and M. Forssen, Generische Nachrichtenaustausch- Authentifizierung fur 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- Verschlusselungsmodi der Secure Shell (SSH), RFC 4344, Januar 2006. B. Harris, Verbesserte Arcfour-Modi fur das Transportebenen-Protokoll der Secure Shell (SSH), RFC 4345, Januar 2006. M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman-Gruppenaustausch fur das Transportebenen-Protokoll der Secure Shell (SSH), RFC 4419, Marz 2006. J. Galbraith and R. Thayer, Das Format der offentlichen Schlussel 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 ursprunglichen und freien SSH-1.2.12-Veroffentlichung durch Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt und Dug Song entfernten viele Fehler, fugten neuere Funktionalitaten wieder hinzu und erstellten OpenSSH. Markus Friedl steuerte die Unterstutzung fur SSH- Protokollversion 1.5 und 2.0 bei. UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3: https://www.gnu.org/licenses/gpl-3.0.html oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer: debian-l10n-german@lists.debian.org Linux 6.8.2-arch2-1 $Mdocdate: 11. Oktober 2023 $ Linux 6.8.2-arch2-1