sshd — OpenSSH-Daemon
SYNOPSIS
sshd [-46DdeGiqTtV] [-C connection_spec] [-c host_certificate_file] [-E log_file]
[-f config_file] [-g login_grace_time] [-h host_key_file] [-o option] [-p port] [-u len]
DESCRIPTION
sshd (OpenSSH-Daemon) ist das Daemon-Programm für ssh(1). Es bietet sichere, verschlüsselte Kommunikation zwischen zwei nicht vertrauenswürdigen Hosts über ein unsicheres Netzwerk.
sshd lauscht auf Verbindungen von Clients. Es wird normalerweise beim Booten aus /etc/init.d/ssh gestartet.
Für jede eingehende Verbindung wird ein neuer Daemon gestartet. Die gestarteten Daemons verwalten den Schlüsselaustausch, die Verschlüsselung, die Authentifizierung, die Befehlsausführung und den Datenaustausch.
sshd kann mithilfe von Befehlszeilenoptionen oder einer Konfigurationsdatei (standardmäßig sshd_config(5)) konfiguriert werden; Befehlszeilenoptionen überschreiben die in der Konfigurationsdatei angegebenen Werte. sshd liest seine Konfigurationsdatei neu, wenn es ein SIGHUP-Signal empfängt, indem es sich selbst mit dem Namen und den Optionen startet, mit denen es gestartet wurde, z. B. /usr/sbin/sshd.
Die Optionen sind wie folgt:
-4 Erzwingt, dass sshd nur IPv4-Adressen verwendet.
-6 Erzwingt, dass sshd nur IPv6-Adressen verwendet.
-C connection_spec
Gibt die Verbindungsparameter an, die für den -T-erweiterten Testmodus verwendet werden sollen. Wenn angegeben, werden alle Match-Direktiven in der Konfigurationsdatei angewendet, bevor die Konfiguration in die Standardausgabe geschrieben wird. Die Verbindungsparameter werden als Schlüssel=Wert-Paare angegeben und können in beliebiger Reihenfolge angegeben werden, entweder mit mehreren -C-Optionen oder als kommagetrennte Liste. Die Schlüssel sind „addr“, „user“, „host“, „laddr“, „lport“ und „rdomain“ und entsprechen der Quelladresse, dem Benutzer, dem aufgelösten Quell-Hostnamen, der lokalen Adresse, der lokalen Portnummer bzw. der Routing-Domäne. Zusätzlich kann das Flag „invalid-user“ (das kein Wertargument entgegennimmt) angegeben werden, um eine Verbindung von einem nicht erkannten Benutzernamen zu simulieren.
-c host_certificate_file
Gibt einen Pfad zu einer Zertifikatsdatei an, um sshd während des Schlüsselaustauschs zu identifizieren. Die Zertifikatsdatei muss mit einer Hostschlüsseldatei übereinstimmen, die mithilfe der Option -h oder der Konfigurationsdirektive HostKey angegeben wird.
-D Wenn diese Option angegeben ist, wird sshd nicht als Daemon ausgeführt. Dies ermöglicht eine einfache Überwachung von sshd.
-d Debug-Modus. Der Server sendet ausführliche Debug-Ausgaben an die Standardfehlerausgabe und wird nicht im Hintergrund ausgeführt. Der Server verzweigt sich auch nicht (fork(2)) und verarbeitet nur eine Verbindung. Diese Option ist nur für das Debugging des Servers vorgesehen. Mehrere -d-Optionen erhöhen die Debug-Ebene. Maximal ist 3.
-E log_datei
Fügt Debug-Protokolle an die Datei `log_datei` anstelle des Systemprotokolls an.
-e
Schreibt Debug-Protokolle an die Standardfehlerausgabe anstelle des Systemprotokolls.
-f konfigurationsdatei
Gibt den Namen der Konfigurationsdatei an. Standardmäßig ist dies `/etc/ssh/sshd_config`. `sshd`
verweigert den Start, wenn keine Konfigurationsdatei vorhanden ist.
-G
Analysiert und gibt die Konfigurationsdatei aus. Überprüft die Gültigkeit der Konfigurationsdatei, gibt die effektive Konfiguration nach `stdout` aus und beendet sich dann. Optional können `Match`-Regeln angewendet werden, indem die Verbindungsparameter mit einer oder mehreren Optionen `-C` angegeben werden.
-g anmelde_wartezeit
Gibt die Wartezeit für Clients an, sich zu authentifizieren (Standard: 120 Sekunden).
Wenn sich der Client innerhalb dieser Zeit nicht authentifizieren kann, wird die Verbindung vom Server getrennt und er beendet sich. Ein Wert von Null bedeutet, dass kein Limit besteht.
-h host_schluesseldatei
Gibt eine Datei an, aus der ein Hostschlüssel gelesen wird. Diese Option muss angegeben werden, wenn `sshd` nicht als Root ausgeführt wird (da die normalen Hostschlüsseldateien normalerweise nur für Root lesbar sind).
Die Standardwerte sind `/etc/ssh/ssh_host_ecdsa_key`, `/etc/ssh/ssh_host_ed25519_key` und
`/etc/ssh/ssh_host_rsa_key`. Es ist möglich, mehrere Hostschlüsseldateien für die verschiedenen Hostschlüsselalgorithmen zu haben.
-i
Gibt an, dass `sshd` von `inetd(8)` aus ausgeführt wird.
-o option
Kann verwendet werden, um Optionen im Format anzugeben, das in der Konfigurationsdatei verwendet wird. Dies ist nützlich, um Optionen anzugeben, für die es keine separate Befehlszeilenoption gibt. Für vollständige Details zu den Optionen und ihren Werten siehe `sshd_config(5)`.
-p port
Gibt den Port an, an dem der Server auf Verbindungen wartet (Standard: 22). Mehrere
Portoptionen sind zulässig. In der Konfigurationsdatei mit der Option `Port` angegebene Ports werden ignoriert, wenn ein Port in der Befehlszeile angegeben wird. In der Option `ListenAddress` angegebene Ports überschreiben Ports, die in der Befehlszeile angegeben wurden.
-q
Leiser Modus. Es wird nichts an das Systemprotokoll gesendet. Normalerweise werden der Beginn, die Authentifizierung und das Beenden jeder Verbindung protokolliert.
-T
Erweiterter Testmodus. Überprüft die Gültigkeit der Konfigurationsdatei, gibt die effektive
Konfiguration nach `stdout` aus und beendet sich dann. Optional können `Match`-Regeln angewendet werden, indem die Verbindungsparameter mit einer oder mehreren Optionen `-C` angegeben werden. Dies ähnelt der Option `-G`, enthält aber zusätzlich die Tests, die in der Option `-t` durchgeführt werden.
-t
Testmodus. Es wird nur die Gültigkeit der Konfigurationsdatei und die Richtigkeit der Schlüssel überprüft.
Dies ist nützlich, um `sshd` zuverlässig zu aktualisieren, da sich Konfigurationsoptionen ändern können.
-u laenge
Diese Option wird verwendet, um die Größe des Feldes in der `utmp`-Struktur anzugeben, das den
entfernten Hostnamen enthält. Wenn der aufgelöste Hostname länger als `laenge` ist, wird stattdessen der dezimale Punktwert verwendet. Dies ermöglicht es Hosts mit sehr langen Hostnamen, die dieses Feld überschreiten, weiterhin eindeutig identifiziert zu werden. Das Angeben von `-u0` bedeutet, dass nur dezimale Punktadressen in die `utmp`-Datei geschrieben werden. `-u0` kann auch verwendet werden, um zu verhindern, dass `sshd` DNS-Anfragen stellt, es sei denn, der Authentifizierungsmechanismus oder die Konfiguration erfordern dies.
Authentifizierungsmechanismen, die DNS erfordern, sind `HostbasedAuthentication` und die Verwendung einer Option `from="pattern-list"` in einer SchlüsseldDatei. Konfigurationsoptionen, die DNS erfordern, sind die Verwendung eines Musters `USER@HOST` in `AllowUsers` oder `DenyUsers`.
-V Zeigt die Versionsnummer an und beendet das Programm.
AUTHENTIFIZIERUNG
Der OpenSSH SSH-Daemon unterstützt nur das SSH-Protokoll 2. Jeder Host verfügt über einen Host-spezifischen Schlüssel, der zur Identifizierung des Hosts verwendet wird. Wenn sich ein Client verbindet, antwortet der Daemon mit seinem öffentlichen Host-Schlüssel. Der Client vergleicht den Host-Schlüssel mit seiner eigenen Datenbank, um zu überprüfen, ob er sich nicht geändert hat.
Die Vorwärtsgeheimhaltung wird durch eine Diffie-Hellman-Schlüsselvereinbarung bereitgestellt. Diese Schlüsselvereinbarung führt zu einem gemeinsamen Sitzungsschlüssel. Der Rest der Sitzung wird mit einer symmetrischen Chiffre verschlüsselt. Der Client wählt den Verschlüsselungsalgorithmus aus, der von den vom Server angebotenen Algorithmen verwendet werden soll. Darüber hinaus wird die Integrität der Sitzung durch einen kryptografischen Nachrichtenauthentifizierungscode (MAC) gewährleistet.
Anschließend treten der Server und der Client in einen Authentifizierungsdialog ein. Der Client versucht, sich mithilfe der Host-basierten Authentifizierung, der öffentlichen Schlüsselauthentifizierung, der Challenge-Response-Authentifizierung oder der Passwortauthentifizierung zu authentifizieren.
Unabhängig vom Authentifizierungstyp wird das Konto überprüft, um sicherzustellen, dass es zugänglich ist. Ein Konto ist nicht zugänglich, wenn es gesperrt ist, in DenyUsers aufgeführt ist oder seine Gruppe in DenyGroups aufgeführt ist. Die Definition eines gesperrten Kontos ist systemspezifisch. Einige Plattformen verfügen über eine eigene Kontendatenbank (z. B. AIX), während andere das Feld „passwd“ ändern („*LK*“ auf Solaris und UnixWare, „*“ auf HP-UX, das „Nologin“ auf Tru64 enthält, ein führendes „*LOCKED*“ auf FreeBSD und ein führendes „!“ auf den meisten Linux-Distributionen). Wenn es erforderlich ist, die Passwortauthentifizierung für das Konto zu deaktivieren, während gleichzeitig die öffentliche Schlüsselauthentifizierung weiterhin zulässig ist, sollte das Feld „passwd“ auf etwas anderes als diese Werte gesetzt werden (z. B. „NP“ oder „*NP*“).
Wenn sich der Client erfolgreich authentifiziert hat, wird ein Dialog zur Vorbereitung der Sitzung gestartet. Zu diesem Zeitpunkt kann der Client Dinge wie die Zuweisung eines Pseudo-TTY, die Weiterleitung von X11-Verbindungen, die Weiterleitung von TCP-Verbindungen oder die Weiterleitung der Authentifizierungsagent-Verbindung über den sicheren Kanal anfordern.
Danach fordert der Client entweder eine interaktive Shell oder die Ausführung eines nicht interaktiven Befehls an, den sshd über die -c-Option in der Shell des Benutzers ausführt. Anschließend treten beide Seiten in den Sitzungsmodus ein. In diesem Modus kann jede Seite jederzeit Daten senden, und diese Daten werden an die Shell oder den Befehl auf der Serverseite und das Benutzerterminal auf der Clientseite weitergeleitet.
Wenn das Benutzerprogramm beendet wird und alle weitergeleiteten X11- und anderen Verbindungen geschlossen wurden, sendet der Server den Befehl-Exit-Status an den Client, und beide Seiten beenden die Verbindung.
ANMELDEPROZESS
Wenn sich ein Benutzer erfolgreich anmeldet, führt sshd Folgendes aus:
Wenn die Anmeldung an einem TTY erfolgt und kein Befehl angegeben wurde, wird die letzte Anmeldezeit
und /etc/motd ausgegeben (es sei denn, dies wird in der Konfigurationsdatei oder durch ~/.hushlogin verhindert; siehe den Abschnitt „DATEIEN“).
Wenn die Anmeldung an einem TTY erfolgt, wird die Anmeldezeit protokolliert.
Überprüft /etc/nologin; wenn diese Datei vorhanden ist, wird der Inhalt ausgegeben und das Programm beendet (es sei denn, der Benutzer ist root).
Wechselt zu den normalen Benutzerrechten.
Richtet die grundlegende Umgebung ein.
Liest die Datei ~/.ssh/environment, falls diese vorhanden ist, und Benutzer dürfen ihre
Umgebung ändern. Siehe die Option PermitUserEnvironment in sshd_config(5).
Wechselt in das Home-Verzeichnis des Benutzers.
Wenn die Datei ~/.ssh/rc vorhanden ist und die Option PermitUserRC in sshd_config(5) gesetzt ist, wird diese ausgeführt; andernfalls wird, wenn /etc/ssh/sshrc vorhanden ist, diese ausgeführt; andernfalls wird [xauth]({filename}../../xauth)(1) ausgeführt. Die „rc“-Dateien erhalten
das X11-Authentifizierungsprotokoll und das Cookie auf der Standardeingabe. Siehe „SSHRC“ unten.
Führt die Shell oder den Befehl des Benutzers aus. Alle Befehle werden unter der Login-Shell des Benutzers ausgeführt, wie in der System-Passwortdatenbank angegeben.
SSHRC
Wenn die Datei ~/.ssh/rc vorhanden ist, führt sh(1) diese nach dem Lesen der Umgebungsvariablen und vor dem Starten der Shell oder des Befehls des Benutzers aus. Sie darf keine Ausgabe auf stdout erzeugen; stattdessen muss stderr verwendet werden. Wenn die X11-Weiterleitung verwendet wird, erhält sie das „Proto-Cookie“-Paar auf ihrer Standardeingabe (und DISPLAY in ihrer Umgebung). Das Skript muss xauth(1) aufrufen, da sshd xauth nicht automatisch ausführt, um X11-Cookies hinzuzufügen.
Der Hauptzweck dieser Datei ist es, alle Initialisierungsroutinen auszuführen, die möglicherweise erforderlich sind, bevor das Home-Verzeichnis des Benutzers zugänglich wird; AFS ist ein typisches Beispiel für eine solche Umgebung.
Diese Datei enthält wahrscheinlich einige Initialisierungscode gefolgt von etwas Ähnlichem:
if read proto cookie && [ -n "$DISPLAY" ]; then
if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
# X11UseLocalhost=yes
echo add unix:`echo $DISPLAY |
cut -c11-` $proto $cookie
else
# X11UseLocalhost=no
echo add $DISPLAY $proto $cookie
fi | xauth -q fi
Wenn diese Datei nicht vorhanden ist, wird /etc/ssh/sshrc ausgeführt, und wenn diese ebenfalls nicht vorhanden ist, wird xauth verwendet, um das Cookie hinzuzufügen.
FORMAT DER AUTORISIERUNGS-DATEI
AuthorizedKeysFile gibt die Dateien an, die die öffentlichen Schlüssel für die Public-Key-Authentifizierung enthalten; wenn diese Option nicht angegeben ist, ist die Standardeinstellung ~/.ssh/authorized_keys und ~/.ssh/authorized_keys2. Jede Zeile der Datei enthält einen Schlüssel (leere Zeilen und Zeilen, die mit „#“ beginnen, werden als Kommentare ignoriert). Öffentliche Schlüssel bestehen aus den folgenden durch Leerzeichen getrennten Feldern: Optionen, Schlüsseltyp, base64-kodierter Schlüssel, Kommentar. Das Optionsfeld ist optional. Die unterstützten Schlüsseltypen sind:
_
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
_
ssh-ed25519
ssh-rsa
Das Kommentarfeld wird für nichts verwendet (kann aber für den Benutzer nützlich sein, um den Schlüssel zu identifizieren).
Beachten Sie, dass die Zeilen in dieser Datei mehrere hundert Bytes lang sein können (aufgrund der Größe der öffentlichen Schlüsselcodierung), bis zu einem Limit von 8 Kilobyte, was RSA-Schlüssel mit bis zu 16 Kilobit ermöglicht. Sie möchten diese nicht eintippen; kopieren Sie stattdessen die Dateien id_ecdsa.pub, id_ecdsa_sk.pub, id_ed25519.pub, id_ed25519_sk.pub oder id_rsa.pub und bearbeiten Sie sie.
^ shd erzwingt eine minimale RSA-Schlüsselmodulgröße von 1024 Bit.
Die Optionen (falls vorhanden) bestehen aus kommagetrennten Optionspezifikationen. Leerzeichen sind nicht erlaubt, außer innerhalb von doppelten Anführungszeichen. Die folgenden Optionsspezifikationen werden unterstützt (beachten Sie, dass Schlüsselwörter für Optionen Groß- und Kleinschreibung nicht beachten):
agent-forwarding
Aktiviert die Authentifizierungsagentenweiterleitung, die zuvor durch die Option restrict deaktiviert wurde.
cert-authority
Gibt an, dass der aufgeführte Schlüssel eine Zertifizierungsstelle (CA) ist, der vertraut wird, um signierte Zertifikate für die Benutzerauthentifizierung zu validieren.
Zertifikate können Zugriffsbeschränkungen ähnlich diesen Schlüsseloptionen codieren. Wenn sowohl Zertifikatbeschränkungen als auch Schlüsseloptionen vorhanden sind, wird die restriktivste Kombination der beiden angewendet.
command="Befehl"
Gibt an, dass der Befehl ausgeführt wird, wenn dieser Schlüssel für die Authentifizierung verwendet wird. Der vom Benutzer angegebene Befehl (falls vorhanden) wird ignoriert. Der Befehl wird auf einem PTY ausgeführt, wenn der Client ein PTY anfordert; andernfalls wird er ohne TTY ausgeführt. Wenn ein 8-Bit-Cleaner-Kanal erforderlich ist, darf kein PTY angefordert werden, oder es sollte no-pty angegeben werden. Ein Anführungszeichen kann durch Voranstellen eines Backslashes in den Befehl eingefügt werden.
Diese Option kann nützlich sein, um bestimmte öffentliche Schlüssel so einzuschränken, dass sie nur eine bestimmte Operation ausführen. Ein Beispiel wäre ein Schlüssel, der nur Remote-Backups zulässt, aber nichts anderes. Beachten Sie, dass der Client TCP- und/oder X11-Weiterleitung angeben kann, es sei denn, diese werden explizit untersagt, z. B. mit der Schlüsseloption restrict.
Der ursprünglich vom Client angegebene Befehl ist in der Umgebungsvariable SSH_ORIGINAL_COMMAND verfügbar. Beachten Sie, dass diese Option für die Ausführung von Shell-, Befehls- oder Subsystemen gilt. Beachten Sie auch, dass dieser Befehl durch eine ForceCommand-Direktive in sshd_config(5) überschrieben werden kann.
Wenn ein Befehl angegeben wird und ein erzwungener Befehl in einem für die Authentifizierung verwendeten Zertifikat enthalten ist, wird das Zertifikat nur dann akzeptiert, wenn die beiden Befehle identisch sind.
environment="NAME=Wert"
Gibt an, dass die Zeichenfolge der Umgebung hinzugefügt werden soll, wenn sich der Benutzer mit diesem Schlüssel anmeldet. Umgebungsvariablen, die auf diese Weise festgelegt werden, überschreiben andere Standardumgebungswerte. Mehrere Optionen dieses Typs sind zulässig. Die Umgebungsprozessierung ist standardmäßig deaktiviert und wird über die Option PermitUserEnvironment gesteuert.
expiry-time="Zeitangabe"
Gibt einen Zeitpunkt an, nach dem der Schlüssel nicht mehr akzeptiert wird. Die Zeit kann als Datum im Format YYYYMMDD[Z] oder als Zeit im Format YYYYMMDDHHMM[SS][Z] angegeben werden. Datums- und Zeitangaben werden in der Systemzeitzone interpretiert, es sei denn, sie sind mit einem Zeichen Z versehen, in diesem Fall werden sie in der UTC-Zeitzone interpretiert.
from="pattern-list"
Gibt an, dass zusätzlich zur öffentlichen Schlüsselauthentifizierung entweder der kanonische Name des entfernten Hosts oder seine IP-Adresse in der durch Kommas getrennten Liste von Mustern enthalten sein muss. Siehe PATTERNS in ssh_config(5) für weitere Informationen zu Mustern.
Zusätzlich zur Wildcard-Suche, die auf Hostnamen oder Adressen angewendet werden kann, kann ein from-Abschnitt IP-Adressen mithilfe der CIDR-Adress-/Maskenlängen-Notation abgleichen.
Der Zweck dieser Option ist es, die Sicherheit optional zu erhöhen: Die öffentliche Schlüsselauthentifizierung
allein vertraut dem Netzwerk, den Nameservern oder irgendetwas anderem nicht (sondern nur dem Schlüssel); wenn jedoch
jemand auf irgendeine Weise den Schlüssel stiehlt, erlaubt der Schlüssel einem Eindringling die Anmeldung von überall
auf der Welt. Diese zusätzliche Option erschwert die Verwendung eines gestohlenen Schlüssels (Nameserver
und/oder Router müssten zusätzlich zum Schlüssel kompromittiert werden).
no-agent-forwarding
Verbietet die Weiterleitung des Authentifizierungs-Agents, wenn dieser Schlüssel für die Authentifizierung verwendet wird.
no-port-forwarding
Verbietet die TCP-Weiterleitung, wenn dieser Schlüssel für die Authentifizierung verwendet wird. Alle Portweiterleitungsanforderungen des Clients führen zu einem Fehler. Dies könnte beispielsweise in Verbindung mit der Option command verwendet werden.
no-pty Verhindert die Zuweisung eines TTY (eine Anforderung zur Zuweisung eines TTY schlägt fehl).
no-user-rc
Deaktiviert die Ausführung von \~/.ssh/rc.
no-X11-forwarding
Verbietet die X11-Weiterleitung, wenn dieser Schlüssel für die Authentifizierung verwendet wird. Alle X11-Weiterleitungsanforderungen des Clients führen zu einem Fehler.
permitlisten="[host:]port"
Beschränkt die Remote-Portweiterleitung mit der ssh(1) -R-Option, so dass sie nur auf dem angegebenen Host (optional) und Port lauschen darf. IPv6-Adressen können angegeben werden, indem man die Adresse in eckige Klammern setzt. Mehrere permitlisten-Optionen können durch Kommas getrennt angegeben werden. Hostnamen können Wildcards enthalten, wie im Abschnitt PATTERNS in ssh_config(5) beschrieben. Eine Portspezifikation von \* stimmt mit jedem Port überein. Beachten Sie, dass die Einstellung von GatewayPorts die Adressen, an denen gelauscht wird, weiter einschränken kann. Beachten Sie, dass ssh(1) einen Hostnamen von „localhost“ sendet, wenn beim Anfordern der Weiterleitung kein Host zum Lauschen angegeben wurde, und dass dieser Name anders behandelt wird als die expliziten localhost-Adressen „127.0.0.1“ und „::1“.
permitopen="host:port"
Beschränkt die lokale Portweiterleitung mit der ssh(1) -L-Option, so dass sie nur eine Verbindung zu dem angegebenen Host und Port herstellen darf. IPv6-Adressen können angegeben werden, indem man die Adresse in eckige Klammern setzt. Mehrere permitopen-Optionen können durch Kommas getrennt angegeben werden. Es wird keine Mustererkennung oder Namensauflösung für die angegebenen Hostnamen durchgeführt; sie müssen wörtliche Hostnamen und/oder Adressen sein. Eine Portspezifikation von \* stimmt mit jedem Port überein.
port-forwarding
Aktiviert die Portweiterleitung, die zuvor mit der Option restrict deaktiviert wurde.
principals="principals"
Auf einer Zeile mit cert-authority werden die zulässigen Principals für die Zertifikatsauthentifizierung als
kommagetrennte Liste angegeben. Mindestens ein Name aus der Liste muss in der Liste der
Principals des Zertifikats enthalten sein, damit das Zertifikat akzeptiert wird. Diese Option wird für
Schlüssel ignoriert, die nicht als vertrauenswürdige Zertifikatsaussteller mit der Option cert-authority gekennzeichnet sind.
pty Ermöglicht die zuvor durch die Option `restrict` deaktivierte Zuweisung eines TTY.
no-touch-required
Verlangt keine Benutzerbestätigung für Signaturen, die mit diesem Schlüssel erstellt werden. Diese
Option ist nur für die FIDO-Authentifikator-Algorithmen ecdsa-sk und ed25519-sk sinnvoll.
verify-required
Verlangt, dass Signaturen, die mit diesem Schlüssel erstellt werden, bestätigen, dass der Benutzer
verifiziert wurde, z. B. über eine PIN. Diese Option ist nur für die FIDO-Authentifikator-Algorithmen ecdsa-sk und
ed25519-sk sinnvoll.
restrict
Aktiviert alle Einschränkungen, d. h. deaktiviert Port-, Agent- und X11-Weiterleitung sowie die
Zuweisung eines TTY und die Ausführung von ~/.ssh/rc. Wenn in Zukunft weitere
Einschränkungsfunktionen zu den authorized_keys-Dateien hinzugefügt werden, werden diese ebenfalls in diesem Satz enthalten sein.
tunnel="n"
Erzwingt ein tun(4)-Gerät auf dem Server. Ohne diese Option wird bei Bedarf das nächste verfügbare Gerät verwendet, wenn der Client eine Tunnelverbindung anfordert.
user-rc
Ermöglicht die Ausführung von ~/.ssh/rc, die zuvor durch die Option restrict deaktiviert wurde.
X11-forwarding
Ermöglicht die X11-Weiterleitung, die zuvor durch die Option restrict deaktiviert wurde.
Ein Beispiel für eine authorized_keys-Datei:
# Kommentare sind am Zeilenanfang zulässig. Leere Zeilen sind zulässig.
# Einfacher Schlüssel, keine Einschränkungen
ssh-rsa ...
# Erzwingen eines Befehls, Deaktivieren von PTY und aller Weiterleitungen
restrict,command="dump /home" ssh-rsa ...
# Einschränkung der ssh -L-Weiterleistungsziele
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ...
# Einschränkung der ssh -R-Weiterleitungs-Listener
permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa ...
# Konfiguration für die Tunnelweiterleitung
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa ...
# Überschreibung der Einschränkung, um die Zuweisung eines TTY zu ermöglichen
restrict,pty,command="nethack" ssh-rsa ...
# Zulassen eines FIDO-Schlüssels ohne Anforderung einer Berührung
no-touch-required _ ...
# Anfordern einer Benutzerverifizierung (z. B. PIN oder biometrische Daten) für einen FIDO-Schlüssel
verify-required _ ...
# Vertrauenswürdiger CA-Schlüssel, Zulassen der berührungslosen FIDO-Verwendung, falls im Zertifikat angefordert
cert-authority,no-touch-required,principals="user_a" ssh-rsa ...
FORMAT DER SSH_KNOWN_HOSTS-DATEI
Die Dateien /etc/ssh/ssh_known_hosts und ~/.ssh/known_hosts enthalten die öffentlichen Schlüssel aller bekannten Hosts. Die globale Datei sollte vom Administrator vorbereitet werden (optional), und die benutzerbezogene Datei wird automatisch verwaltet: Wann immer sich ein Benutzer mit einem unbekannten Host verbindet, wird dessen Schlüssel in die benutzerbezogene Datei aufgenommen.
Jede Zeile in diesen Dateien enthält die folgenden Felder: Marker (optional), Hostnamen, Schlüsseltyp, Base64-kodierter Schlüssel, Kommentar. Die Felder werden durch Leerzeichen getrennt.
Der Marker ist optional, aber wenn er vorhanden ist, muss er einer der folgenden sein: `@cert-authority`, um anzugeben, dass die Zeile einen Schlüssel einer Zertifizierungsstelle (CA) enthält, oder `@revoked`, um anzugeben,
dass der in der Zeile enthaltene Schlüssel widerrufen wurde und niemals akzeptiert werden darf. In einer Schlüssellinie darf nur ein Marker verwendet werden.
Hostnamen ist eine durch Kommas getrennte Liste von Mustern („*“ und „?“ fungieren als Platzhalter); jedes Muster wird nacheinander mit dem Hostnamen abgeglichen. Wenn sshd einen Client authentifiziert, z. B. bei der Verwendung von HostbasedAuthentication, ist dies der kanonische Hostname des Clients. Wenn ssh(1) einen Server authentifiziert, ist dies der vom Benutzer angegebene Hostname, der Wert von ssh(1) HostkeyAlias, falls dieser angegeben wurde, oder der kanonische Hostname des Servers, wenn die Option ssh(1) CanonicalizeHostname verwendet wurde.
Ein Muster kann auch mit „!“ versehen werden, um eine Negation anzugeben: Wenn der Hostname mit einem negierten Muster übereinstimmt, wird er (für diese Zeile) nicht akzeptiert, selbst wenn er mit einem anderen Muster in der Zeile übereinstimmt. Ein Hostname oder eine Adresse kann optional in eckige Klammern „[“ und „]“ eingeschlossen und dann mit einem Doppelpunkt gefolgt von einer nicht standardmäßigen Portnummer versehen werden.
Alternativ können Hostnamen in einer gehashten Form gespeichert werden, wodurch Hostnamen und Adressen ausgeblendet werden, falls der Inhalt der Datei offengelegt wird. Gehashte Hostnamen beginnen mit dem Zeichen „|“. Nur ein gehashter Hostname darf in einer einzelnen Zeile vorkommen, und keiner der oben genannten Negations- oder Platzhalteroperatoren darf verwendet werden.
Der Schlüsseltyp und der base64-kodierte Schlüssel werden direkt aus dem Hostschlüssel übernommen; diese können beispielsweise aus /etc/ssh/ssh_host_rsa_key.pub abgerufen werden. Das optionale Kommentarfeld setzt sich bis zum Ende der Zeile fort und wird nicht verwendet.
Zeilen, die mit „#“ beginnen, und leere Zeilen werden als Kommentare ignoriert.
Bei der Durchführung der Hostauthentifizierung wird die Authentifizierung akzeptiert, wenn eine übereinstimmende Zeile den richtigen Schlüssel enthält; entweder einen, der exakt übereinstimmt, oder, wenn der Server ein Zertifikat zur Authentifizierung präsentiert hat, den Schlüssel der Zertifizierungsstelle, die das Zertifikat signiert hat. Damit ein Schlüssel als Zertifizierungsstelle vertraut wird, muss er das oben beschriebene „@cert-authority“-Kennzeichen verwenden.
Die bekannte Hostdatei bietet auch die Möglichkeit, Schlüssel als widerrufen zu kennzeichnen, z. B. wenn bekannt ist, dass der zugehörige private Schlüssel gestohlen wurde. Widerrufene Schlüssel werden angegeben, indem das „@revoked“-Kennzeichen am Anfang der Schlüsselleiste eingefügt wird, und werden nicht für die Authentifizierung oder als Zertifizierungsstellen akzeptiert, sondern erzeugen stattdessen eine Warnung von ssh(1), wenn sie gefunden werden.
Es ist zulässig (aber nicht empfehlenswert), mehrere Zeilen oder verschiedene Hostschlüssel für denselben Namen zu haben. Dies wird unweigerlich auftreten, wenn kurze Formen von Hostnamen aus verschiedenen Domänen in die Datei eingefügt werden. Es ist möglich, dass die Dateien widersprüchliche Informationen enthalten; die Authentifizierung wird akzeptiert, wenn gültige Informationen aus einer der Dateien gefunden werden können.
Beachten Sie, dass die Zeilen in diesen Dateien typischerweise hunderte von Zeichen lang sind und Sie die Hostschlüssel definitiv nicht manuell eingeben möchten. Generieren Sie sie stattdessen mit einem Skript, ssh-keyscan(1) oder indem Sie beispielsweise /etc/ssh/ssh_host_rsa_key.pub nehmen und die Hostnamen am Anfang hinzufügen. ssh-keygen(1) bietet auch einige grundlegende automatisierte Bearbeitungsfunktionen für ~/.ssh/known_hosts, einschließlich des Entfernens von Hosts, die einem Hostnamen entsprechen, und des Konvertierens aller Hostnamen in ihre gehashten Darstellungen.
Ein Beispiel für eine ssh_known_hosts-Datei:
# Kommentare sind am Zeilenanfang erlaubt
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
# Ein gehashter Hostname
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234.....=
# Ein widerrufener Schlüssel
@revoked * ssh-rsa AAAAB5W...
# Ein CA-Schlüssel, der für jeden Host in *.mydomain.com oder *.mydomain.org akzeptiert wird
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...
DATEIEN
~/.hushlogin
Diese Datei wird verwendet, um das Anzeigen der letzten Anmeldezeit und von /etc/motd zu unterdrücken, wenn PrintLastLog bzw. PrintMotd aktiviert sind. Sie unterdrückt nicht die Anzeige des durch Banner angegebenen Banners.
~/.rhosts
Diese Datei wird für die hostbasierte Authentifizierung verwendet (siehe ssh(1) für weitere Informationen). Auf einigen Maschinen muss diese Datei möglicherweise von allen Benutzern gelesen werden können, wenn sich das Home-Verzeichnis des Benutzers auf einer NFS-Partition befindet, da sshd sie als Root 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 hostbasierte Authentifizierung, ohne die Anmeldung mit rlogin/rsh zu ermöglichen.
~/.ssh/
Dieses Verzeichnis ist der Standardspeicherort für alle benutzerspezifischen Konfigurations- und Authentifizierungsinformationen. Es gibt keine allgemeine Anforderung, den gesamten Inhalt dieses Verzeichnisses geheim zu halten, aber die empfohlenen Berechtigungen sind Lese-/Schreib-/Ausführzugriff für den Benutzer und kein Zugriff für andere.
~/.ssh/authorized_keys
Listet die öffentlichen Schlüssel (ECDSA, Ed25519, RSA) auf, die für die Anmeldung als dieser Benutzer verwendet werden können. Das Format dieser Datei wird oben beschrieben. Der Inhalt der Datei ist nicht besonders sensibel, aber die empfohlenen Berechtigungen sind Lese-/Schreibzugriff für den Benutzer und kein Zugriff für andere.
Wenn diese Datei, das Verzeichnis ~/.ssh oder das Home-Verzeichnis des Benutzers von anderen Benutzern beschreibbar ist, kann die Datei von nicht autorisierten Benutzern geändert oder ersetzt werden. In diesem Fall wird sshd die Verwendung nicht zulassen, es sei denn, die Option StrictModes wurde auf „no“ gesetzt.
~/.ssh/environment
Diese Datei wird beim Anmelden (falls vorhanden) in die Umgebung eingelesen. Sie kann nur leere Zeilen, Kommentarzeilen (die mit „#“ beginnen) und Zuweisungszeilen im Format name=value enthalten. Die Datei sollte nur für den Benutzer beschreibbar sein; sie muss nicht von anderen Benutzern gelesen werden können. Die Umgebungsprozessierung ist standardmäßig deaktiviert und wird über die Option PermitUserEnvironment gesteuert.
~/.ssh/known_hosts
Enthält eine Liste der Host-Schlüssel für alle Hosts, bei denen sich der Benutzer angemeldet hat und die nicht bereits in der systemweiten Liste der bekannten Host-Schlüssel enthalten sind. Das Format dieser Datei ist oben beschrieben. Diese Datei sollte nur vom Root-Benutzer/dem Besitzer beschreibbar sein und kann, muss aber nicht, für alle lesbar sein.
~/.ssh/rc
Enthält Initialisierungsroutinen, die ausgeführt werden, bevor das Home-Verzeichnis des Benutzers zugänglich wird. Diese Datei sollte nur vom Benutzer beschreibbar sein und muss nicht von anderen lesbar sein.
/etc/hosts.allow
/etc/hosts.deny
Zugriffskontrollen, die von tcp-wrappers erzwungen werden sollen, sind hier definiert. Weitere Details finden sich in hosts_access(5).
/etc/hosts.equiv
Diese Datei dient der Host-basierten Authentifizierung (siehe ssh(1)). Sie sollte nur vom Root-Benutzer beschreibbar sein.
/etc/ssh/moduli
Enthält Diffie-Hellman-Gruppen, die für die Schlüssel-Austausch-Methode „Diffie-Hellman Group Exchange“ verwendet werden. Das Dateiformat ist in moduli(5) beschrieben. Wenn in dieser Datei keine verwendbaren Gruppen gefunden werden, werden feste interne Gruppen verwendet.
/etc/motd
Siehe motd(5).
/etc/nologin
Wenn diese Datei existiert, lehnt sshd alle Anmeldeversuche außer denen des Root-Benutzers ab. Der Inhalt der Datei wird allen angezeigt, die sich anmelden möchten, und Nicht-Root-Verbindungen werden abgelehnt. Die Datei sollte für alle lesbar sein.
/etc/ssh/shosts.equiv
Diese Datei wird genau wie hosts.equiv verwendet, ermöglicht jedoch die Host-basierte Authentifizierung, ohne die Anmeldung mit rlogin/rsh zu ermöglichen.
/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. Diese Dateien sollten nur dem Root-Benutzer gehören, nur vom Root-Benutzer lesbar sein und für andere nicht zugänglich sein. sshd wird nicht gestartet, wenn diese Dateien gruppen-/weltweit zugänglich sind.
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub
Diese Dateien enthalten die öffentlichen Teile der Host-Schlüssel. Diese Dateien sollten für alle lesbar, aber nur vom Root-Benutzer beschreibbar sein. Ihr Inhalt sollte mit dem jeweiligen privaten Teil übereinstimmen. Diese Dateien werden nicht wirklich für etwas verwendet; sie werden zur Bequemlichkeit des Benutzers bereitgestellt, damit deren Inhalt in bekannte Host-Dateien kopiert werden kann. Diese Dateien werden mit ssh-keygen(1) erstellt.
/etc/ssh/ssh_known_hosts
Systemweite Liste der bekannten Host-Schlüssel. Diese Datei sollte vom Systemadministrator so vorbereitet werden, dass sie die öffentlichen Host-Schlüssel aller Maschinen in der Organisation enthält. Das Format dieser Datei ist oben beschrieben. Diese Datei sollte nur vom Root-Benutzer/dem Besitzer beschreibbar sein und sollte für alle lesbar sein.
/etc/ssh/sshd_config
Enthält Konfigurationsdaten für sshd. Das Dateiformat und die Konfigurationsoptionen sind in sshd_config(5) beschrieben.
/etc/ssh/sshrc
Ähnlich wie ~/.ssh/rc kann es verwendet werden, um maschinenspezifische Initialisierungen zur Anmeldezeit global anzugeben. Diese Datei sollte nur vom Root-Benutzer beschreibbar sein und sollte für alle lesbar sein.
/run/sshd
chroot(2)-Verzeichnis, das von sshd während der Privilegientrennung in der Vor-Authentifizierungsphase verwendet wird. Das Verzeichnis sollte keine Dateien enthalten und muss im Besitz von root sein und darf nicht gruppenschreib- oder weltweit schreibbar sein.
/run/sshd.pid
Enthält die Prozess-ID des sshd, der auf Verbindungen wartet (wenn mehrere Daemons gleichzeitig für verschiedene Ports ausgeführt werden, enthält dies die Prozess-ID des zuletzt gestarteten Daemons). Der Inhalt dieser Datei ist nicht sensibel; sie kann weltweit lesbar sein.
SIEHE AUCH
scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), chroot(2), hosts_access(5), moduli(5), sshd_config(5), inetd(8), sftp-server(8)
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. Niels Provos und Markus Friedl haben die Unterstützung für die Privilegientrennung beigetragen.