ssh — OpenSSH-Remote-Login-Client
SYNOPSIS
ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
[-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd]
[-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] destination [command [argument ...]]
ssh [-Q query_option]
DESCRIPTION
ssh (SSH-Client) ist ein Programm zum Anmelden an einem Remote-Rechner und zum Ausführen von Befehlen auf einem Remote-Rechner. Es soll eine sichere, verschlüsselte Kommunikation zwischen zwei nicht vertrauenswürdigen Hosts über ein unsicheres Netzwerk ermöglichen. X11-Verbindungen, beliebige TCP-Ports und Unix-Domain-Sockets können ebenfalls über den sicheren Kanal weitergeleitet werden.
ssh verbindet sich mit dem angegebenen Zielrechner und meldet sich dort an, wobei das Ziel entweder als [user@]hostname oder in Form einer URI ssh://[user@]hostname[:port] angegeben werden kann. Der Benutzer muss seine Identität gegenüber dem Remote-Rechner nachweisen, indem er eine der folgenden Methoden verwendet (siehe unten).
Wenn ein Befehl angegeben wird, wird dieser auf dem Remote-Host anstelle einer Login-Shell ausgeführt. Eine vollständige Befehlszeile kann als Befehl angegeben werden oder zusätzliche Argumente enthalten. Wenn angegeben, werden die Argumente an den Befehl angehängt, bevor er durch Leerzeichen getrennt an den Server gesendet und dort ausgeführt wird.
Die Optionen sind wie folgt:
-4 Erzwingt, dass ssh nur IPv4-Adressen verwendet.
-6 Erzwingt, dass ssh nur IPv6-Adressen verwendet.
-A Aktiviert die Weiterleitung von Verbindungen von einem Authentifizierungs-Agenten wie ssh-agent(1).
Dies kann auch pro Host in einer Konfigurationsdatei angegeben werden.
Die Agenten-Weiterleitung sollte mit Vorsicht aktiviert werden. Benutzer, die die Fähigkeit haben, Dateiberechtigungen auf dem Remote-Host (für den Unix-Domain-Socket des Agenten) zu umgehen, können über die weitergeleitete Verbindung auf den lokalen Agenten zugreifen. Ein Angreifer kann zwar keine Schlüsselmaterialien vom Agenten erhalten, aber er kann Operationen an den Schlüsseln durchführen, die es ihm ermöglichen, sich mit den im Agenten gespeicherten Identitäten zu authentifizieren. Eine sicherere Alternative könnte die Verwendung eines Jump-Hosts sein (siehe -J).
-a Deaktiviert die Weiterleitung der Authentifizierungs-Agenten-Verbindung.
-B bind_interface
Binden Sie sich an die Adresse von bind_interface, bevor Sie versuchen, eine Verbindung zum Zielhost herzustellen. Dies ist nur auf Systemen mit mehr als einer Adresse nützlich.
-b bind_address
Verwenden Sie bind_address auf dem lokalen Rechner als Quelladresse der Verbindung. Nur auf Systemen mit mehr als einer Adresse nützlich.
-c cipher_spec
Gibt die zu verwendende Verschlüsselung an.
-D [bind_address:]port
Dynamischer Portweiterleitung. Bindet an den angegebenen Port auf dem lokalen Rechner und leitet die Verbindung zum Zielrechner weiter.
-E log_file
Gibt eine Datei an, in die Protokollmeldungen geschrieben werden sollen.
-e escape_char
Gibt ein Escapezeichen für die Befehlseingabe an.
-F configfile
Gibt eine Datei an, die die Konfiguration enthält.
-I pkcs11
Gibt den Pfad zu einer PKCS#11-Bibliothek an, die zum Speichern privater Schlüssel verwendet wird.
-i identity_file
Gibt die zu verwendende private Schlüsseldatei an.
-J destination
Verwenden Sie einen Jump-Host, um eine Verbindung zum Zielhost herzustellen.
-L address
Leitet einen Port auf dem lokalen Rechner zum Zielrechner weiter.
-l login_name
Gibt den Benutzernamen an, mit dem sich angemeldet werden soll.
-m mac_spec
Gibt die zu verwendende MAC-Funktion an.
-O ctl_cmd
Gibt einen Steuerbefehl für den Socket an.
-o option
Gibt eine Konfigurationsoption an.
-P tag
Gibt ein Tag für den SSH-Agenten an.
-p port
Gibt den Port an, mit dem eine Verbindung hergestellt werden soll.
-R address
Leitet einen Port auf dem Remote-Rechner zum lokalen Rechner weiter.
-S ctl_path
Gibt den Pfad zum Kontroll-Socket an.
-W host:port
Verwendet eine Portweiterleitung mit einem bestimmten Host und Port.
-w local_tun[:remote_tun]
Fordert ein TTY-Zuweisungs-Pseudo-Terminal von der Remote-Seite an. Dies kann verwendet werden, um eine interaktive Shell auf dem Remote-Rechner zu starten.
destination [command [argument ...]] Gibt das Ziel an, zu dem eine Verbindung hergestellt werden soll. Wenn ein Befehl angegeben ist, wird dieser auf dem Remote-Host ausgeführt.
ssh [-Q query_option]
Gibt eine Abfrageoption an.
-C Fordert die Komprimierung aller Daten an (einschließlich stdin, stdout, stderr und Daten für weitergeleitete
X11-, TCP- und Unix-Domain-Verbindungen). Der Komprimierungsalgorithmus ist derselbe, der von
[gzip]({filename}../../gzip)(1) verwendet wird. Die Komprimierung ist auf Modemleitungen und anderen langsamen Verbindungen wünschenswert, wird aber in schnellen Netzwerken nur zu einer Verlangsamung führen. Der Standardwert kann hostbasiert in den Konfigurationsdateien festgelegt werden; siehe die Option „Komprimierung“ in ssh_config(5).
-c cipher_spec
Wählt die Verschlüsselungsspezifikation für die Verschlüsselung der Sitzung aus. cipher_spec ist eine durch Kommas getrennte Liste von Chiffren, die in der Reihenfolge der Präferenz angegeben werden. Siehe das Schlüsselwort „Ciphers“ in ssh_config(5) für weitere Informationen.
-D [bind_address:]port
Gibt eine lokale „dynamische“ Anwendungsebene-Portweiterleitung an. Dies funktioniert, indem ein Socket zugewiesen wird, um auf dem lokalen Port zu lauschen, optional an die angegebene bind_address gebunden. Wenn eine Verbindung zu diesem Port hergestellt wird, wird die Verbindung über den sicheren Kanal weitergeleitet, und das Anwendungsprotokoll wird dann verwendet, um zu bestimmen, wohin von der Remote-Maschine aus eine Verbindung hergestellt werden soll. Derzeit werden die Protokolle SOCKS4 und SOCKS5 unterstützt, und ssh fungiert als SOCKS-Server. Nur Root-Benutzer können privilegierte Ports weiterleiten. Dynamische Portweiterleitungen können auch in der Konfigurationsdatei angegeben werden.
IPv6-Adressen können angegeben werden, indem die Adresse in eckige Klammern eingeschlossen wird. Nur der Superuser kann privilegierte Ports weiterleiten. Standardmäßig wird der lokale Port gemäß der GatewayPorts-Einstellung gebunden. Es kann jedoch eine explizite bind_address verwendet werden, um die Verbindung an eine bestimmte Adresse zu binden. Die bind_address „localhost“ gibt an, dass der lauschende Port nur für die lokale Verwendung gebunden werden soll, während eine leere Adresse oder „*“ angibt, dass der Port von allen Schnittstellen aus verfügbar sein soll.
-E log_file
Fügt Debug-Protokolle anstatt an die Standardfehlerausgabe an log_file an.
-e escape_char
Setzt das Escape-Zeichen für Sitzungen mit einem PTY (Standard: ‚\~‘). Das Escape-Zeichen wird nur am Anfang einer Zeile erkannt. Das Escape-Zeichen gefolgt von einem Punkt (‚.‘) schließt die Verbindung; gefolgt von Strg-Z setzt die Verbindung in den Hintergrund; und gefolgt von sich selbst sendet das Escape-Zeichen einmal. Wenn das Zeichen auf „none“ gesetzt wird, werden alle Escapes deaktiviert und die Sitzung wird vollständig transparent.
-F configfile
Gibt eine alternative, benutzerspezifische Konfigurationsdatei an. Wenn eine Konfigurationsdatei in der Befehlszeile angegeben wird, wird die systemweite Konfigurationsdatei (/etc/ssh/ssh_config) ignoriert. Der Standard für die benutzerspezifische Konfigurationsdatei ist ~/.ssh/config. Wenn sie auf „none“ gesetzt ist, werden keine Konfigurationsdateien gelesen.
-f Fordert ssh auf, kurz vor der Befehlsausführung in den Hintergrund zu gehen. Dies ist nützlich, wenn ssh nach Passwörtern oder Passphrasen fragen soll, der Benutzer sie aber im Hintergrund ausführen möchte. Dies impliziert -n. Die empfohlene Methode zum Starten von X11-Programmen auf einem Remote-Standort ist z. B. ssh -f host xterm.
Wenn die Konfigurationsoption ExitOnForwardFailure auf „yes“ gesetzt ist, wartet ein mit -f gestarteter Client, bis alle Remote-Portweiterleitungen erfolgreich eingerichtet sind, bevor er sich in den Hintergrund begibt. Weitere Informationen finden Sie in der Beschreibung von ForkAfterAuthentication in ssh_config(5).
^ G Veranlasst ssh, seine Konfiguration nach der Auswertung der Blöcke Host und Match auszugeben und zu beenden.
^ g Ermöglicht es Remote-Hosts, sich mit lokalen weitergeleiteten Ports zu verbinden. Wenn dies bei einer Multiplex-Verbindung verwendet wird, muss diese Option im Master-Prozess angegeben werden.
^ I pkcs11 Gibt die PKCS#11-Shared Library an, die ssh zur Kommunikation mit einem PKCS#11-Token verwenden soll, das Schlüssel für die Benutzerauthentifizierung bereitstellt.
^ i identity_file Wählt eine Datei aus, aus der die Identität (privater Schlüssel) für die Public-Key-Authentifizierung gelesen wird. Sie können auch eine Datei mit dem öffentlichen Schlüssel angeben, um den entsprechenden privaten Schlüssel zu verwenden, der in ssh-agent(1) geladen ist, wenn die Datei mit dem privaten Schlüssel nicht lokal vorhanden ist. Standardmäßig sind dies ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 und ~/.ssh/id_ed25519_sk. Identitätsdateien können auch pro Host in der Konfigurationsdatei angegeben werden. Es ist möglich, mehrere -i-Optionen (und mehrere in der Konfigurationsdatei angegebene Identitäten) zu haben. Wenn keine Zertifikate explizit mit der Direktive CertificateFile angegeben wurden, versucht ssh auch, Zertifikatinformationen aus der durch Anhängen von -cert.pub an die Dateinamen der Identitäten abgeleiteten Datei zu laden.
^ J destination Verbindet sich mit dem Zielhost, indem zuerst eine ssh-Verbindung zum in destination beschriebenen Jump-Host hergestellt und dann eine TCP-Weiterleitung zum endgültigen Ziel von dort aus aufgebaut wird. Es können mehrere Jump-Hops durch Kommas getrennt angegeben werden. IPv6-Adressen können angegeben werden, indem sie in eckige Klammern eingeschlossen werden. Dies ist eine Abkürzung, um eine ProxyJump-Konfigurationsdirektive anzugeben. Beachten Sie, dass Konfigurationsdirektiven, die über die Befehlszeile angegeben werden, im Allgemeinen für den Zielhost und nicht für die angegebenen Jump-Hosts gelten. Verwenden Sie ~/.ssh/config, um die Konfiguration für Jump-Hosts anzugeben.
^ K Aktiviert die GSSAPI-basierte Authentifizierung und die Weiterleitung (Delegierung) von GSSAPI-Anmeldeinformationen an den Server.
^ k Deaktiviert die Weiterleitung (Delegierung) von GSSAPI-Anmeldeinformationen an den Server.
^ L [bind_address:]port:host:hostport
^ L [bind_address:]port:remote_socket
^ L local_socket:host:hostport
^ L local_socket:remote_socket
Gibt an, dass Verbindungen zum angegebenen TCP-Port oder Unix-Socket auf dem lokalen (Client-)Host an den angegebenen Host und Port oder Unix-Socket auf der Remote-Seite weitergeleitet werden sollen. Dies funktioniert, indem ein Socket zum Abhören entweder eines TCP-Ports auf der lokalen Seite oder eines Unix-Sockets zugewiesen wird, wobei optional die angegebene bind_address verwendet wird. Wann immer eine Verbindung zu dem lokalen Port oder Socket hergestellt wird, wird die Verbindung über den sicheren Kanal weitergeleitet, und eine Verbindung wird entweder zu dem Host-Port hostport oder zu dem Unix-Socket remote_socket von der Remote-Maschine hergestellt.
Portweiterleitungen können auch in der Konfigurationsdatei angegeben werden. Nur der Superuser kann privilegierte Ports weiterleiten. IPv6-Adressen können angegeben werden, indem die Adresse in eckige Klammern eingeschlossen wird.
Standardmäßig wird der lokale Port gemäß der Einstellung GatewayPorts gebunden. Es kann jedoch eine explizite Bindungsadresse verwendet werden, um die Verbindung an eine bestimmte Adresse zu binden. Die Bindungsadresse „localhost“ gibt an, dass der lauschende Port nur für die lokale Verwendung gebunden werden soll, während eine leere Adresse oder „*“ angibt, dass der Port von allen Schnittstellen aus verfügbar sein soll.
-l login_name
Gibt den Benutzer an, unter dem auf der Remote-Maschine angemeldet werden soll. Dies kann auch pro Host in der Konfigurationsdatei angegeben werden.
-M Setzt den SSH-Client in den „Master“-Modus für die Verbindungswiederverwendung. Mehrere -M-Optionen
setzen SSH in den „Master“-Modus, erfordern aber eine Bestätigung mit ssh-askpass(1), bevor
jede Operation, die den Multiplexing-Zustand ändert (z. B. das Öffnen einer neuen Sitzung), durchgeführt wird. Beachten Sie die Beschreibung von ControlMaster in ssh_config(5) für weitere Informationen.
-m mac_spec
Eine durch Kommas getrennte Liste von MAC-Algorithmen (Message Authentication Code), die in der Reihenfolge ihrer Präferenz angegeben sind. Siehe das Schlüsselwort MACs in ssh_config(5) für weitere Informationen.
-N Führt keinen Remote-Befehl aus. Dies ist nützlich, um nur Ports weiterzuleiten. Beachten Sie die
Beschreibung von SessionType in ssh_config(5) für weitere Informationen.
-n Leitet stdin von /dev/null um (verhindert tatsächlich das Lesen von stdin). Dies muss
verwendet werden, wenn ssh im Hintergrund ausgeführt wird. Ein gängiger Trick ist die Verwendung, um X11-Programme auf einer Remote-Maschine auszuführen. Zum Beispiel startet ssh -n shadows.cs.hut.fi emacs &
ein emacs auf shadows.cs.hut.fi, und die X11-Verbindung wird automatisch über einen verschlüsselten Kanal weitergeleitet. Das ssh-Programm wird in den Hintergrund verschoben. (Dies funktioniert nicht, wenn ssh ein Passwort oder eine Passphrase abfragen muss; siehe auch die Option -f.) Beachten Sie die Beschreibung von StdinNull in ssh_config(5) für weitere Informationen.
-O ctl_cmd
Steuert einen aktiven Verbindungsmultiplexing-Masterprozess. Wenn die Option -O angegeben wird, wird das Argument ctl_cmd interpretiert und an den Masterprozess übergeben. Gültige Befehle sind: „check“ (prüfen, ob der Masterprozess ausgeführt wird), „forward“ (Weiterleitungen anfordern, ohne einen Befehl auszuführen), „cancel“ (Weiterleitungen abbrechen), „proxy“ (mit einem laufenden Multiplexing-Master im Proxy-Modus verbinden), „exit“ (den Master auffordern, zu beenden) und
„stop“ (den Master auffordern, keine weiteren Multiplexinganforderungen mehr zu akzeptieren).
-o option
Kann verwendet werden, um Optionen im Format anzugeben, das in der Konfigurationsdatei verwendet wird. Dies ist nützlich
zum Angeben von Optionen, für die es kein separates Befehlszeilen-Flag gibt. Für vollständige Informationen über die unten aufgeführten Optionen und ihre möglichen Werte siehe ssh_config(5).
AddKeysToAgent
AddressFamily
BatchMode
BindAddress
BindInterface
CASignatureAlgorithms
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CertificateFile
ChannelTimeout
CheckHostIP
Ciphers
ClearAllForwardings
Compression
ConnectTimeout
ConnectionAttempts
ControlMaster
ControlPath
ControlPersist
DynamicForward
EnableEscapeCommandline
EnableSSHKeysign
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForkAfterAuthentication
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GSSAPIAuthentication
GSSAPIKeyExchange
GSSAPIClientIdentity
GSSAPIDelegateCredentials
GSSAPIKexAlgorithms
GSSAPIRenewalForcesRekey
GSSAPIServerIdentity
GSSAPITrustDns
GatewayPorts
GlobalKnownHostsFile
HashKnownHosts
Host
HostKeyAlgorithms
HostKeyAlias
HostbasedAcceptedAlgorithms
HostbasedAuthentication
Hostname
IPQoS
IdentitiesOnly
IdentityAgent
IdentityFile
IgnoreUnknown
Include
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LocalCommand
LocalForward
LogLevel
LogVerbose
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
ObscureKeystrokeTiming
PKCS11Provider
PasswordAuthentication
PermitLocalCommand
PermitRemoteOpen
Port
PreferredAuthentications
ProxyCommand
ProxyJump
ProxyUseFdpass
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RemoteCommand
RemoteForward
RequestTTY
RequiredRSASize
RevokedHostKeys
SecurityKeyProvider
SendEnv
ServerAliveCountMax
ServerAliveInterval
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
SyslogFacility
TCPKeepAlive
Tag
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation
-P tag Geben Sie einen Tag-Namen an, der verwendet werden kann, um die Konfiguration in ssh_config(5) auszuwählen. Siehe
die Schlüsselwörter „Tag“ und „Match“ in ssh_config(5) für weitere Informationen.
-p port
Port, zu dem eine Verbindung zum Remote-Host hergestellt werden soll. Dies kann auf Host-Basis in der
Konfigurationsdatei angegeben werden.
-Q query_option
Fragt die durch eine der folgenden Funktionen unterstützten Algorithmen ab: cipher (unterstützte
symmetrische Chiffren), cipher-auth (unterstützte symmetrische Chiffren, die eine authentifizierte
Verschlüsselung unterstützen), help (unterstützte Abfrageterme für die Verwendung mit der Option -Q), mac (unterstützte Nachrichtenintegritätscodes), kex (Schlüsselaustauschalgorithmen), kex-gss (GSSAPI-Schlüsselaustauschalgorithmen), key (Schlüsseltypen), key-ca-sign (gültige CA-Signaturalgorithmen für Zertifikate),
key-cert (Zertifikatschlüsseltypen), key-plain (nicht-zertifikatsbasierte Schlüsseltypen), key-sig (alle Schlüsseltypen
und Signaturalgorithmen), protocol-version (unterstützte SSH-Protokollversionen) und sig (unterstützte Signaturalgorithmen). Alternativ kann jedes Schlüsselwort aus ssh_config(5) oder
sshd_config(5), das eine Algorithmusliste akzeptiert, als Alias für die entsprechende
query_option verwendet werden.
-q Leiser Modus. Unterdrückt die meisten Warn- und Diagnosemeldungen.
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket
-R [bind_address:]port
Gibt an, dass Verbindungen zum angegebenen TCP-Port oder Unix-Socket auf dem Remote-Host (Server) an die lokale Seite weitergeleitet werden sollen.
Dies funktioniert, indem ein Socket zugewiesen wird, um entweder auf einen TCP-Port oder einen Unix-Socket auf der Remote-Seite zu lauschen. Wann immer eine Verbindung zu diesem Port oder Unix-Socket hergestellt wird, wird die Verbindung über den sicheren Kanal weitergeleitet, und es wird eine Verbindung von der lokalen Maschine zu einem explizit angegebenen Ziel (host:port) oder local_socket hergestellt.
Wenn kein explizites Ziel angegeben wurde, fungiert ssh als SOCKS 4/5-Proxy und leitet Verbindungen zu den von dem Remote-SOCKS-Client angeforderten Zielen weiter.
Portweiterleitungen können auch in der Konfigurationsdatei angegeben werden. Privilegierte Ports können nur dann weitergeleitet werden, wenn Sie als Root-Benutzer auf dem Remote-Computer angemeldet sind. IPv6-Adressen können angegeben werden, indem Sie die Adresse in eckige Klammern setzen.
Standardmäßig werden TCP-Listener-Sockets auf dem Server nur an die Loopback-Schnittstelle gebunden. Dies kann durch Angabe einer bind_address überschrieben werden. Eine leere bind_address oder die Adresse „*“ zeigt an, dass der Remote-Socket auf allen Schnittstellen lauschen soll. Das Angeben einer Remote-bind_address ist nur dann erfolgreich, wenn die GatewayPorts-Option des Servers aktiviert ist (siehe sshd_config(5)).
Wenn das Argument „port“ „0“ ist, wird der Listener-Port dynamisch auf dem Server zugewiesen und dem Client zur Laufzeit gemeldet. In Kombination mit -O forward wird der zugewiesene Port auf der Standardausgabe ausgegeben.
-S ctl_path
Gibt den Speicherort eines Steuersockets für die Verbindungsfreigabe an oder die Zeichenfolge „none“, um die Verbindungsfreigabe zu deaktivieren. Weitere Informationen finden Sie in der Beschreibung von ControlPath und ControlMaster in ssh_config(5).
-s Kann verwendet werden, um die Aufrufung eines Subsystems auf dem Remote-System anzufordern. Subsysteme ermöglichen die Verwendung von SSH als sicheren Transport für andere Anwendungen (z. B. [sftp]({filename}../../sftp)(1)). Das Subsystem wird als Remote-Befehl angegeben. Weitere Informationen finden Sie in der Beschreibung von SessionType in ssh_config(5).
-T Deaktiviert die Pseudo-Terminal-Zuweisung.
-t Erzwingt die Pseudo-Terminal-Zuweisung. Dies kann verwendet werden, um beliebige, bildschirmbasierte Programme auf einer Remote-Maschine auszuführen, was z. B. bei der Implementierung von Menüservices sehr nützlich sein kann. Mehrere -t-Optionen erzwingen die TTY-Zuweisung, auch wenn ssh kein lokales TTY hat.
-V Zeigt die Versionsnummer an und beendet das Programm.
-v Ausführlicher Modus. Veranlasst ssh, Debugging-Meldungen über seinen Fortschritt auszugeben. Dies ist hilfreich beim Debuggen von Verbindungsproblemen, Authentifizierungsproblemen und Konfigurationsproblemen. Mehrere -v-Optionen erhöhen die Ausführlichkeit. Das Maximum ist 3.
-W host:port
Fordert an, dass die Standardeingabe und -ausgabe auf dem Client über den sicheren Kanal an den Host auf dem angegebenen Port weitergeleitet werden. Impliziert -N, -T, ExitOnForwardFailure und ClearAllForwardings, obwohl diese in der Konfigurationsdatei oder mit den Befehlszeilenoptionen -o überschrieben werden können.
-w local_tun[:remote_tun]
Fordert eine Tunnelgeräte-Weiterleitung mit den angegebenen tun(4)-Geräten zwischen dem Client (local_tun) und dem Server (remote_tun) an.
Die Geräte können entweder durch ihre numerische ID oder durch das Schlüsselwort „any“ angegeben werden, wobei dann das nächste verfügbare Tunnelgerät verwendet wird. Wenn remote_tun nicht angegeben ist, wird es standardmäßig auf „any“ gesetzt. Siehe auch die Direktiven Tunnel und TunnelDevice in ssh_config(5).
Wenn die Direktive Tunnel nicht gesetzt ist, wird sie auf den Standard-Tunnelmodus gesetzt, der „Punkt-zu-Punkt“ lautet. Wenn ein anderer Tunnelweiterungsmodus gewünscht wird, sollte dieser vor -w angegeben werden.
-X Aktiviert die X11-Weiterleitung. Dies kann auch für jeden Host in einer Konfigurationsdatei angegeben werden.
Die X11-Weiterleitung sollte mit Vorsicht aktiviert werden. Benutzer, die in der Lage sind, Dateiberechtigungen auf dem Remote-Host zu umgehen (für die X-Autorisierungsdatenbank des Benutzers), können über die weitergeleitete Verbindung auf das lokale X11-Display zugreifen. Ein Angreifer kann dann möglicherweise Aktivitäten wie das Aufzeichnen von Tastatureingaben durchführen.
Aus diesem Grund unterliegt die X11-Weiterleitung standardmäßig den X11-Sicherheitserweiterungsbeschränkungen. Siehe die Option ssh -Y und die Direktive ForwardX11Trusted in ssh_config(5) für weitere Informationen.
(Debian-spezifisch: Die X11-Weiterleitung unterliegt standardmäßig nicht den X11-Sicherheitserweiterungsbeschränkungen, da zu viele Programme derzeit in diesem Modus abstürzen. Setzen Sie die Option ForwardX11Trusted auf „no“, um das ursprüngliche Verhalten wiederherzustellen. Dies kann sich in Zukunft je nach clientseitigen Verbesserungen ändern.)
-x Deaktiviert die X11-Weiterleitung.
-Y Aktiviert die vertrauenswürdige X11-Weiterleitung. Bei der vertrauenswürdigen X11-Weiterleitung werden die X11-Sicherheitserweiterungsbeschränkungen nicht angewendet.
(Debian-spezifisch: In der Standardkonfiguration ist diese Option äquivalent zu -X, da ForwardX11Trusted standardmäßig auf „yes“ gesetzt ist, wie oben beschrieben. Setzen Sie die Option ForwardX11Trusted auf „no“, um das ursprüngliche Verhalten wiederherzustellen. Dies kann sich in Zukunft je nach clientseitigen Verbesserungen ändern.)
-y Sendet Protokollinformationen mithilfe des Systemmoduls syslog(3). Standardmäßig werden diese Informationen an stderr gesendet.
ssh kann zusätzlich Konfigurationsdaten aus einer benutzerspezifischen Konfigurationsdatei und einer systemweiten Konfigurationsdatei beziehen. Das Dateiformat und die Konfigurationsoptionen sind in ssh_config(5) beschrieben.
AUTHENTIFIZIERUNG
Der OpenSSH-SSH-Client unterstützt das SSH-Protokoll 2.
Die verfügbaren Authentifizierungsmethoden sind: GSSAPI-basierte Authentifizierung, hostbasierte Authentifizierung, Public-Key-Authentifizierung, interaktive Authentifizierung und Passwortauthentifizierung. Die Authentifizierungsmethoden werden in der oben genannten Reihenfolge ausprobiert, wobei PreferredAuthentications verwendet werden kann, um die Standardreihenfolge zu ändern.
Die hostbasierte Authentifizierung funktioniert wie folgt: Wenn die Maschine, von der sich der Benutzer anmeldet, in der Datei /etc/hosts.equiv oder /etc/ssh/shosts.equiv auf der Remote-Maschine aufgeführt ist, der Benutzer kein Root-Benutzer ist und die Benutzernamen auf beiden Seiten übereinstimmen, oder wenn die Dateien ~/.rhosts oder ~/.shosts im Home-Verzeichnis des Benutzers auf der Remote-Maschine vorhanden sind 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 berücksichtigt. Zusätzlich muss der Server in der Lage sein, den Hostschlüssel des Clients zu überprüfen (siehe die Beschreibung von /etc/ssh/ssh_known_hosts und ~/.ssh/known_hosts unten), damit die Anmeldung zulässig ist. Diese Authentifizierungsmethode schließt Sicherheitslücken aufgrund von IP-Spoofing, DNS-Spoofing und Routing-Spoofing.
[Hinweis für den Administrator: /etc/hosts.equiv, ~/.rhosts und das rlogin/rsh-Protokoll im Allgemeinen sind von Natur aus unsicher und sollten deaktiviert werden, wenn Sicherheit gewünscht ist.]
Die Public-Key-Authentifizierung funktioniert wie folgt: Das Schema basiert auf der Public-Key-Kryptographie, wobei Verschlüsselungs- und Entschlüsselungsvorgänge mit separaten Schlüsseln durchgeführt werden, und es ist unmöglich, den Entschlüsselungsschlüssel aus dem Verschlüsselungsschlüssel abzuleiten. Die Idee ist, dass jeder Benutzer ein öffentliches/privates Schlüsselpaar für Authentifizierungszwecke erstellt. Der Server kennt den öffentlichen Schlüssel, und nur der Benutzer kennt den privaten Schlüssel. ssh implementiert das Public-Key-Authentifizierungsprotokoll automatisch und verwendet dabei einen der ECDSA-, Ed25519- oder RSA-Algorithmen.
Die Datei ~/.ssh/authorized_keys listet die öffentlichen Schlüssel auf, die für die Anmeldung zulässig sind. Wenn sich der Benutzer anmeldet, teilt das ssh-Programm dem Server mit, welches Schlüsselpaar es für die Authentifizierung verwenden möchte. Der Client beweist, dass er Zugriff auf den privaten Schlüssel hat, und der Server überprüft, ob der entsprechende öffentliche Schlüssel autorisiert ist, das Konto zu akzeptieren.
Der Server kann den Client über Fehler informieren, die die erfolgreiche Public-Key-Authentifizierung verhindert haben, nachdem die Authentifizierung mit einer anderen Methode abgeschlossen wurde. Diese können durch Erhöhung des LogLevels auf DEBUG oder höher (z. B. mit der Option -v) angezeigt werden.
Der Benutzer erstellt sein Schlüsselpaar mit dem Befehl ssh-keygen(1). Dieser speichert den privaten Schlüssel in ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (authenticator-hosted ECDSA), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (authenticator-hosted Ed25519) oder ~/.ssh/id_rsa (RSA) und speichert den öffentlichen Schlüssel in ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (authenticator-hosted ECDSA), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (authenticator-hosted Ed25519) oder ~/.ssh/id_rsa.pub (RSA) im Home-Verzeichnis des Benutzers. Der Benutzer sollte dann den öffentlichen Schlüssel in die Datei ~/.ssh/authorized_keys in seinem Home-Verzeichnis auf der Remote-Maschine kopieren. Die Datei authorized_keys entspricht der üblichen Datei ~/.rhosts und enthält jeweils einen Schlüssel pro Zeile, wobei die Zeilen sehr lang sein können. Danach kann sich der Benutzer anmelden, ohne das Passwort eingeben zu müssen.
Eine Variante der Public-Key-Authentifizierung ist in Form der Zertifikatsauthentifizierung verfügbar: Anstelle eines Satzes von Public/Private-Schlüssel werden signierte Zertifikate verwendet. Dies hat den Vorteil, dass anstelle vieler Public/Private-Schlüssel eine einzelne vertrauenswürdige Zertifizierungsstelle verwendet werden kann. Weitere Informationen finden Sie im Abschnitt ZERTIFIKATE von ssh-keygen(1).
Die bequemste Möglichkeit, die Public-Key- oder Zertifikatsauthentifizierung zu verwenden, ist möglicherweise mit einem Authentifizierungsagenten. Weitere Informationen finden Sie unter ssh-agent(1) und (optional) der Direktive AddKeysToAgent in ssh_config(5).
Die Keyboard-Interactive-Authentifizierung funktioniert wie folgt: Der Server sendet einen beliebigen „Challenge“-Text und fordert eine Antwort an, möglicherweise mehrmals. Beispiele für die Keyboard-Interactive-Authentifizierung sind BSD-Authentifizierung (siehe login.conf(5)) und PAM (einige Nicht-OpenBSD-Systeme).
Wenn alle anderen Authentifizierungsmethoden fehlschlagen, fordert ssh den Benutzer zur Eingabe eines Passworts auf. Das Passwort wird an den Remote-Host zur Überprüfung gesendet; da jedoch alle Kommunikationen verschlüsselt sind, kann das Passwort von jemandem, der das Netzwerk abhört, nicht eingesehen werden.
ssh verwaltet und überprüft automatisch eine Datenbank, die Identifikationsdaten für alle Hosts enthält, mit denen es jemals verwendet wurde. Hostschlüssel werden im Verzeichnis ~/.ssh/known_hosts im Home-Verzeichnis des Benutzers gespeichert. Darüber hinaus wird die Datei /etc/ssh/ssh_known_hosts automatisch auf bekannte Hosts überprüft. Alle neuen Hosts werden automatisch zur Datei des Benutzers hinzugefügt. Wenn sich die Identifikation eines Hosts jemals ändert, warnt ssh dies und deaktiviert die Passwortauthentifizierung, um Server-Spoofing oder Man-in-the-Middle-Angriffe zu verhindern, die andernfalls verwendet werden könnten, um die Verschlüsselung zu umgehen. Mit der Option StrictHostKeyChecking kann die Anmeldung bei Maschinen gesteuert werden, deren Hostschlüssel nicht bekannt ist oder sich geändert hat.
Wenn die Identität des Benutzers vom Server akzeptiert wurde, führt der Server entweder den angegebenen Befehl in einer nicht-interaktiven Sitzung aus oder, wenn kein Befehl angegeben wurde, meldet er sich bei der Maschine an und stellt dem Benutzer eine normale Shell als interaktive Sitzung zur Verfügung. Die gesamte Kommunikation mit dem Remote-Befehl oder der Remote-Shell wird automatisch verschlüsselt.
Wenn eine interaktive Sitzung angefordert wird, fordert ssh standardmäßig nur ein Pseudo-Terminal (pty) für interaktive Sitzungen an, wenn der Client eines hat. Mit den Flags -T und -t kann dieses Verhalten überschrieben werden.
Wenn ein Pseudo-Terminal zugewiesen wurde, kann der Benutzer die unten aufgeführten Escape-Zeichen verwenden.
Wenn kein Pseudo-Terminal zugewiesen wurde, ist die Sitzung transparent und kann verwendet werden, um zuverlässig Binärdaten zu übertragen. Auf den meisten Systemen führt das Setzen des Escape-Zeichens auf „kein“ auch dann zu einer transparenten Sitzung, wenn ein TTY verwendet wird.
Die Sitzung wird beendet, wenn der Befehl oder die Shell auf der Remote-Maschine beendet wird und alle X11- und TCP-Verbindungen geschlossen wurden.
ESCAPE-ZEICHEN
Wenn ein Pseudo-Terminal angefordert wurde, unterstützt ssh eine Reihe von Funktionen über die Verwendung eines Escape-Zeichens.
Ein einzelnes Tilde-Zeichen kann als ~~ gesendet werden oder durch Anhängen eines anderen Zeichens an das Tilde-Zeichen, das nicht in den unten beschriebenen Zeichen enthalten ist. Das Escape-Zeichen muss immer auf eine neue Zeile folgen, um als speziell interpretiert zu werden. Das Escape-Zeichen kann in Konfigurationsdateien mit der Konfigurationsdirektive EscapeChar oder über die Befehlszeile mit der Option -e geändert werden.
Die unterstützten Escape-Sequenzen (unter der Annahme des Standardwerts '\~') sind:
~. Trennen.
~^Z ssh im Hintergrund ausführen.
~# Liste der weitergeleiteten Verbindungen anzeigen.
~& ssh im Hintergrund ausführen, wenn sich die Sitzung beendet, und auf das Beenden weitergeleiteter Verbindungen/X11-Sitzungen warten.
~? Eine Liste der Escape-Zeichen anzeigen.
~B Ein BREAK-Signal an das Remote-System senden (nur nützlich, wenn das Gegenüber dies unterstützt).
~C Eine Befehlszeile öffnen. Derzeit ermöglicht dies das Hinzufügen von Portweiterleitungen mit den Optionen -L, -R und -D (siehe oben). Außerdem können vorhandene Portweiterleitungen mit -KL[bind_address:]port für lokale, -KR[bind_address:]port für Remote- und -KD[bind_address:]port für dynamische Portweiterleitungen abgebrochen werden. !command ermöglicht es dem Benutzer, einen lokalen Befehl auszuführen, wenn die Option PermitLocalCommand in ssh_config(5) aktiviert ist. Eine grundlegende Hilfe ist mit der Option -h verfügbar.
~R Eine erneute Verschlüsselung der Verbindung anfordern (nur nützlich, wenn das Gegenüber dies unterstützt).
~V Die Ausführlichkeit (LogLevel) verringern, wenn Fehler in stderr geschrieben werden.
~v Die Ausführlichkeit (LogLevel) erhöhen, wenn Fehler in stderr geschrieben werden.
TCP-WEITERLEITUNG
Die Weiterleitung beliebiger TCP-Verbindungen über einen sicheren Kanal kann entweder über die Befehlszeile oder in einer Konfigurationsdatei angegeben werden. Eine mögliche Anwendung der TCP-Weiterleitung ist eine sichere Verbindung zu einem Mailserver; eine andere ist das Umgehen von Firewalls.
In dem folgenden Beispiel wird die Verschlüsselung der Kommunikation für einen IRC-Client betrachtet, auch wenn der IRC-Server, mit dem er sich verbindet, keine verschlüsselte Kommunikation direkt unterstützt. Dies funktioniert wie folgt: Der Benutzer verbindet sich mit dem Remote-Host über ssh und gibt die zu verwendenden Ports an, um die Verbindung weiterzuleiten. Danach ist es möglich, das Programm lokal zu starten, und ssh wird die Verbindung verschlüsseln und an den Remote-Server weiterleiten.
Das folgende Beispiel tunnelt eine IRC-Sitzung vom Client zu einem IRC-Server unter "server.example.com", wobei die Verbindung zum Kanal "#users" hergestellt und der Benutzername "pinky" verwendet wird, und zwar über 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 führt ssh im Hintergrund aus, und der Remote-Befehl "sleep 10" wird angegeben, um eine bestimmte Zeit (im Beispiel 10 Sekunden) zu ermöglichen, damit das Programm, das den Tunnel verwenden wird, gestartet wird. Wenn innerhalb der angegebenen Zeit keine Verbindungen hergestellt werden, wird ssh beendet.
X11-WEITERLEITUNG
Wenn die Variable ForwardX11 auf „yes“ gesetzt ist (oder die Beschreibung der Optionen -X, -x und -Y oben beachten Sie) und der Benutzer X11 verwendet (die Umgebungsvariable DISPLAY ist gesetzt),
wird die Verbindung zum X11-Display automatisch auf die Remote-Seite weitergeleitet, sodass alle X11-Programme, die von der Shell (oder dem Befehl) gestartet werden, über den verschlüsselten Kanal laufen
und die Verbindung zum eigentlichen X-Server von der lokalen Maschine hergestellt wird. Der Benutzer sollte DISPLAY nicht manuell festlegen.
Die Weiterleitung von X11-Verbindungen kann über die Befehlszeile oder in Konfigurationsdateien konfiguriert werden.
Der von ssh festgelegte DISPLAY-Wert zeigt auf die Servermaschine, verwendet aber eine Anzeigenummer größer als Null. Dies ist normal, da ssh einen "Proxy"-X-Server auf der Servermaschine erstellt, um
die Verbindungen über den verschlüsselten Kanal weiterzuleiten.
^ sh richtet auch automatisch Xauthority-Daten auf der Servermaschine ein. Zu diesem Zweck generiert es ein zufälliges Autorisierungscookie, speichert es in Xauthority auf dem Server und überprüft, ob alle
weitergeleiteten Verbindungen dieses Cookie übertragen und es durch das eigentliche Cookie ersetzt wird, wenn die Verbindung geöffnet wird. Das eigentliche Authentifizierungscookie wird niemals an die
Servermaschine gesendet (und keine Cookies werden im Klartext gesendet).
Wenn die Variable ForwardAgent auf „yes“ gesetzt ist (oder die Beschreibung der Optionen -A und -a oben beachten Sie) und der Benutzer einen Authentifizierungsagenten verwendet, wird die Verbindung
zum Agenten automatisch auf die Remote-Seite weitergeleitet.
HOST-SCHLÜSSEL VERIFIZIEREN
Wenn Sie sich zum ersten Mal mit einem Server verbinden, wird dem Benutzer ein Fingerabdruck des öffentlichen Schlüssels des Servers angezeigt (es sei denn, die Option StrictHostKeyChecking wurde
deaktiviert). Fingerabdrücke können mit ssh-keygen(1) ermittelt werden:
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
Wenn der Fingerabdruck bereits bekannt ist, kann er abgeglichen und der Schlüssel akzeptiert oder abgelehnt werden. Wenn nur alte (MD5-)Fingerabdrücke für den Server verfügbar sind, kann die Option
^ sh-keygen(1) -E verwendet werden, um den Fingerabdruckalgorithmus herabzusetzen.
Da es schwierig ist, Host-Schlüssel einfach durch Betrachten von Fingerabdruck-Strings zu vergleichen, gibt es auch die Möglichkeit, Host-Schlüssel visuell zu vergleichen, mit Hilfe von zufälliger Kunst.
Durch Setzen der Option VisualHostKey auf „yes“ wird bei jeder Anmeldung an einem Server ein kleines ASCII-Grafik dargestellt, unabhängig davon, ob die Sitzung selbst interaktiv ist oder nicht. Durch das
Erlernen des Musters, das ein bekannter Server erzeugt, kann ein Benutzer leicht feststellen, ob sich der Host-Schlüssel geändert hat, wenn ein völlig anderes Muster angezeigt wird. Da diese Muster jedoch
nicht eindeutig sind, gibt ein Muster, das dem erinnerten Muster ähnlich sieht, nur eine gute Wahrscheinlichkeit an, dass der Host-Schlüssel gleich ist, nicht aber einen garantierten Beweis.
Um eine Liste der Fingerabdrücke zusammen mit ihren Random Art-Darstellungen für alle bekannten Hosts abzurufen, kann der folgende Befehl verwendet werden:
$ ssh-keygen -lv -f ~/.ssh/known_hosts
Wenn der Fingerabdruck unbekannt ist, steht eine alternative Methode zur Überprüfung zur Verfügung: SSH-Fingerabdrücke, die von DNS verifiziert werden. Ein zusätzlicher Resource Record (RR), SSHFP, wird einer Zonen-Datei hinzugefügt, und der Client kann sich mit dem präsentierten Schlüssel abgleichen.
In diesem Beispiel verbinden wir einen Client mit einem Server, „host.example.com“. Die SSHFP-Resource-Records sollten zuerst der Zonen-Datei für host.example.com hinzugefügt werden:
$ ssh-keygen -r host.example.com.
Die Ausgabezeilen müssen der Zonen-Datei hinzugefügt werden. Um zu überprüfen, ob die Zone Fingerabdruck-Abfragen beantwortet:
$ dig -t SSHFP host.example.com
Schließlich verbindet sich der Client:
$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Übereinstimmender Host-Schlüssel-Fingerabdruck in DNS gefunden. Möchten Sie die Verbindung wirklich fortsetzen (ja/nein)?
Weitere Informationen finden Sie in der Option VerifyHostKeyDNS in ssh_config(5).
SSH-BASIERTE VIRTUELLEN PRIVATNETZWERKE
ssh enthält Unterstützung für Virtual Private Network (VPN)-Tunneling unter Verwendung des tun(4)-Netzwerk-Pseudo-Geräts, wodurch zwei Netzwerke sicher verbunden werden können. Die sshd_config(5)-Konfigurationsoption PermitTunnel steuert, ob der Server dies unterstützt und auf welcher Ebene (Layer-2- oder Layer-3-Verkehr).
Das folgende Beispiel würde das Client-Netzwerk 10.0.50.0/24 mit dem Remote-Netzwerk 10.0.99.0/24 mithilfe einer Punkt-zu-Punkt-Verbindung von 10.1.1.1 zu 10.1.1.2 verbinden, vorausgesetzt, der SSH-Server, der auf dem Gateway zum Remote-Netzwerk unter 192.168.1.15 ausgeführt wird, erlaubt dies.
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 über die Datei /root/.ssh/authorized_keys (siehe unten) und die Server-Option PermitRootLogin feiner abgestimmt werden. Der folgende Eintrag würde Verbindungen auf dem tun(4)-Gerät 1 vom Benutzer „jane“ und auf dem tun-Gerät 2 vom Benutzer „john“ zulassen, wenn 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 Einrichtung einen erheblichen Overhead mit sich bringt, ist sie möglicherweise besser für temporäre Setups geeignet, z. B. für drahtlose VPNs. Dauerhaftere VPNs werden besser durch Tools wie ipsecctl(8) und isakmpd(8) bereitgestellt.
UMGEBUNG
ssh setzt normalerweise die folgenden Umgebungsvariablen:
DISPLAY Die DISPLAY-Variable gibt den Speicherort des X11-Servers an. ssh setzt diese automatisch auf einen Wert der Form „hostname:n“, wobei „hostname“ den Host angibt, auf dem die Shell ausgeführt wird, und „n“ eine ganze Zahl ≥ ist.
ssh verwendet diesen speziellen Wert, um X11-Verbindungen über den sicheren Kanal weiterzuleiten. Der Benutzer sollte DISPLAY normalerweise nicht explizit festlegen, da dies die X11-Verbindung unsicher macht (und erfordert, dass der Benutzer alle erforderlichen Autorisierungscookies manuell kopiert).
HOME Auf den Pfad des Home-Verzeichnisses des Benutzers gesetzt.
LOGNAME Synonym für USER; zur Kompatibilität mit Systemen, die diese Variable verwenden, gesetzt.
MAIL Auf den Pfad der Mailbox des Benutzers gesetzt.
PATH Auf den Standard-PATH gesetzt, wie er beim Kompilieren von ssh angegeben wurde.
SSH_ASKPASS Wenn ssh ein Passwort benötigt, liest es dieses aus dem aktuellen Terminal, wenn es von einem Terminal aus ausgeführt wurde. Wenn ssh kein Terminal zugeordnet hat, aber DISPLAY und SSH_ASKPASS gesetzt sind, wird das in SSH_ASKPASS angegebene Programm ausgeführt und ein X11-Fenster geöffnet, um das Passwort einzulesen. Dies ist besonders nützlich, wenn ssh von einem .xsession- oder ähnlichen Skript aufgerufen wird. (Beachten Sie, dass es auf einigen Maschinen erforderlich sein kann, die Eingabe von /dev/null umzuleiten, damit dies funktioniert.)
SSH_ASKPASS_REQUIRE Ermöglicht eine weitere Steuerung der Verwendung eines Askpass-Programms. Wenn diese Variable auf „never“ gesetzt ist, versucht ssh niemals, ein solches Programm zu verwenden. Wenn sie auf „prefer“ gesetzt ist, bevorzugt ssh die Verwendung des Askpass-Programms anstelle des TTY, wenn Passwörter abgefragt werden. Schließlich wird, wenn die Variable auf „force“ gesetzt ist, das Askpass-Programm für alle Passwortabfragen verwendet, unabhängig davon, ob DISPLAY gesetzt ist.
SSH_AUTH_SOCK Gibt den Pfad eines Unix-Domain-Sockets an, der zur Kommunikation mit dem Agent verwendet wird.
SSH_CONNECTION Identifiziert die Client- und Serverseiten der Verbindung. Die Variable enthält vier durch Leerzeichen getrennte Werte: Client-IP-Adresse, Client-Portnummer, Server-IP-Adresse und Server-Portnummer.
SSH_ORIGINAL_COMMAND Diese Variable enthält die ursprüngliche Befehlszeile, wenn ein erzwungener Befehl ausgeführt wird. Sie kann verwendet werden, um die ursprünglichen Argumente zu extrahieren.
SSH_TTY Diese Variable wird auf den Namen des TTY (Pfad zum Gerät) gesetzt, das der aktuellen Shell oder dem aktuellen Befehl zugeordnet ist. Wenn die aktuelle Sitzung kein TTY hat, wird diese Variable nicht gesetzt.
SSH_TUNNEL Optional von [sshd]({filename}../../sshd)(8) gesetzt, um die Namen der zugewiesenen Schnittstellen zu enthalten, wenn Tunneling vom Client angefordert wurde.
SSH_USER_AUTH Optional von [sshd]({filename}../../sshd)(8) gesetzt. Diese Variable kann einen Pfad zu einer Datei enthalten, die die erfolgreich verwendeten Authentifizierungsmethoden auflistet, als die Sitzung eingerichtet wurde, einschließlich aller verwendeten öffentlichen Schlüssel.
TZ Diese Variable wird gesetzt, um die aktuelle Zeitzone anzugeben, wenn diese beim Start des Daemons festgelegt wurde (d. h. der Daemon übergibt den Wert an neue Verbindungen).
USER Auf den Namen des Benutzers gesetzt, der sich anmeldet.
Zusätzlich liest ssh \~/.ssh/environment und fügt Zeilen im Format „VARNAME=value“ zur Umgebung hinzu, wenn die Datei vorhanden ist und den Benutzern erlaubt ist, ihre Umgebung zu ändern. Weitere Informationen finden Sie in der Option PermitUserEnvironment in sshd_config(5).
DATEIEN
~/.rhosts
Diese Datei wird für die Host-basierte Authentifizierung verwendet (siehe oben). Auf einigen Maschinen muss diese Datei möglicherweise von allen Benutzern gelesen werden können, wenn das Home-Verzeichnis des Benutzers sich auf einer NFS-Partition befindet, da sshd(8) diese Datei als Root-Benutzer liest. Darüber hinaus muss diese Datei im Besitz des Benutzers sein und darf keine Schreibberechtigungen für andere Benutzer haben. Die empfohlene Berechtigung für die meisten Maschinen ist Lese-/Schreibzugriff für den Benutzer und kein Zugriff für andere.
~/.shosts
Diese Datei wird genau wie .rhosts verwendet, ermöglicht aber die Host-basierte Authentifizierung, ohne das Anmelden mit rlogin/rsh zu ermöglichen.
~/.ssh/
Dieses Verzeichnis ist der Standardspeicherort für alle benutzerspezifischen Konfigurations- und Authentifizierungsinformationen. Es besteht keine allgemeine Anforderung, den gesamten Inhalt dieses Verzeichnisses geheim zu halten, aber die empfohlenen Berechtigungen sind Lese-/Schreib-/Ausführungszugriff für den Benutzer und kein Zugriff für andere.
~/.ssh/authorized_keys
Enthält die öffentlichen Schlüssel (ECDSA, Ed25519, RSA), die für die Anmeldung als dieser Benutzer verwendet werden können. Das Format dieser Datei wird in der sshd(8)-Handbuchseite beschrieben. Diese Datei ist nicht hochsensibel, aber die empfohlenen Berechtigungen sind Lese-/Schreibzugriff für den Benutzer und kein Zugriff für andere.
~/.ssh/config
Dies ist die Konfigurationsdatei pro Benutzer. Das Dateiformat und die Konfigurationsoptionen werden in ssh_config(5) beschrieben. Aufgrund des Potenzials für Missbrauch muss diese Datei strikte Berechtigungen haben: Lese-/Schreibzugriff für den Benutzer und darf nicht von anderen schreibbar sein. Sie kann gruppenweise beschreibbar sein, vorausgesetzt, die betreffende Gruppe enthält nur den Benutzer.
~/.ssh/environment
Enthält zusätzliche Definitionen für Umgebungsvariablen; siehe „UMGEBUNG“, oben.
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Enthält den privaten Schlüssel für die Authentifizierung. Diese Dateien enthalten sensible Daten und sollten vom Benutzer lesbar sein, dürfen aber nicht für andere zugänglich sein (Lese-/Schreib-/Ausführungszugriff). ssh ignoriert einfach eine private Schlüsselddatei, wenn sie für andere zugänglich ist. Es ist möglich, eine Passphrase anzugeben, wenn der Schlüssel generiert wird, die dann verwendet wird, um den sensiblen Teil dieser Datei mit AES-128 zu verschlüsseln.
~/.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 sensibel und können (müssen aber nicht) von allen gelesen werden.
~/.ssh/known_hosts
Enthält eine Liste der Hostschlüssel für alle Hosts, bei denen sich der Benutzer angemeldet hat, die nicht bereits in der systemweiten Liste der bekannten Hostschlüssel enthalten sind. Siehe sshd(8) für weitere Informationen zum Format dieser Datei.
~/.ssh/rc
Die Befehle in dieser Datei werden von ssh ausgeführt, wenn sich der Benutzer anmeldet, unmittelbar bevor die Shell (oder der Befehl) des Benutzers gestartet wird. Weitere Informationen finden Sie in der sshd(8)-Handbuchseite.
/etc/hosts.equiv
Diese Datei dient der hostbasierten Authentifizierung (siehe oben). Sie sollte nur von root beschreibbar sein.
/etc/ssh/shosts.equiv
Diese Datei wird auf die gleiche Weise wie hosts.equiv verwendet, ermöglicht jedoch die hostbasierte Authentifizierung, ohne die Anmeldung mit rlogin/rsh zu erlauben.
/etc/ssh/ssh_config
Systemweite Konfigurationsdatei. Das Dateiformat und die Konfigurationsoptionen werden in ssh_config(5) beschrieben.
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
Diese Dateien enthalten die privaten Teile der Host-Schlüssel und werden für die hostbasierte Authentifizierung verwendet.
/etc/ssh/ssh_known_hosts
Systemweite Liste der bekannten Host-Schlüssel. Diese Datei sollte vom Systemadministrator erstellt werden, um die öffentlichen Host-Schlüssel aller Maschinen in der Organisation zu enthalten. Sie sollte weltweit lesbar sein. Weitere Informationen zum Format dieser Datei finden Sie in sshd(8).
/etc/ssh/sshrc
Die Befehle in dieser Datei werden von ssh ausgeführt, wenn sich der Benutzer anmeldet, kurz bevor die Shell (oder der Befehl) des Benutzers gestartet wird. Weitere Informationen finden Sie in der Manpage sshd(8).
RÜCKGABEWERT
ssh gibt den Rückgabewert des Remote-Befehls oder 255 zurück, wenn ein Fehler aufgetreten ist.
SIEHE AUCH
scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)
STANDARDS
S. Lehtinen und C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, Januar
2006.
T. Ylonen und C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, Januar 2006.
T. Ylonen und C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, Januar 2006.
T. Ylonen und C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, Januar
2006.
T. Ylonen und C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, Januar 2006.
J. Schlyter und W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints,
RFC 4255, Januar 2006.
F. Cusack und M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol
(SSH), RFC 4256, Januar 2006.
J. Galbraith und P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335,
Januar 2006.
M. Bellare, T. Kohno und C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes,
RFC 4344, Januar 2006.
B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345,
Januar 2006.
M. Friedl, N. Provos und W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH)
Transport Layer Protocol, RFC 4419, März 2006.
J. Galbraith und R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, November
2006.
D. Stebila und J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport
Layer, RFC 5656, Dezember 2009.
A. Perrig und D. Song, Hash Visualization: Eine neue Technik zur Verbesserung der 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 kostenlosen ssh 1.2.12-Version von Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt und Dug Song haben viele Fehler behoben, neuere Funktionen wieder hinzugefügt und OpenSSH erstellt. Markus Friedl hat die Unterstützung für SSH-Protokollversionen 1.5 und 2.0 beigetragen.