- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
SSHD(8) | System Manager's Manual | SSHD(8) |
BEZEICHNUNG¶
sshd
—
OpenSSH-Daemon
ÜBERSICHT¶
sshd
[-46DdeiqTtV
]
[-C
Verbindungsfestlegung]
[-c
Rechnerzertifikatsdatei]
[-E
Protokolldatei]
[-f
Konfigurationsdatei]
[-g
Anmeldeaufschubzeit]
[-h
Rechnerschlüsseldatei]
[-o
Option]
[-p
Port]
[-u
Länge]
BESCHREIBUNG¶
sshd
(OpenSSH Daemon) ist das
Daemon-Programm für ssh(1). Es stellt eine sichere
verschlüsselte Kommunikation zwischen zwei nicht
vertrauenswürdigen Rechnern über ein unsicheres Netzwerk
bereit.
sshd
wartet auf Anfragen von Clients. Es
wird normalerweise beim Systemstart mittels
/etc/init.d/ssh gestartet. Es erstellt mit Fork
einen neuen Deamon für jede Verbindung. Der mit Fork erstellte Daemon
handhabt den Schlüsselaustausch, die Verschlüsselung,
Authentifizierung, die Befehlsausführung und den Datenaustausch.
sshd
kann mittels Befehlszeilenoptionen
oder einer Konfigurationsdatei (standardmäßig
sshd_config(5)) konfiguriert werden; Befehlszeilenoptionen
setzen die in der Konfigurationsdatei gesetzten Werte außer Kraft.
sshd
liest seine Konfigurationsdatei neu, wenn er
ein Auflegen-Signal, SIGHUP
, erhält, indem er
sich selbst mit dem Namen und den Optionen ausführt, mit denen er
gestartet wurde, z.B. /usr/sbin/sshd.
Folgende Optionen stehen zur Verfügung:
-4
- Erzwingt, dass
sshd
nur IPv4-Adressen verwendet. -6
- Erzwingt, dass
sshd
nur IPv6-Adressen verwendet. -C
Verbindungsfestlegung- Legt die Verbindungsparameter fest, die für den erweiterten
Testmodus
-T
verwandt werden sollen. Falls bereitgestellt, werden alle DirektivenMatch
in der Konfigurationsdatei, die angewandt würden, angewandt, bevor die Konfigurationsdatei auf die Standardausgabe geschrieben wird. Die Verbindungsparameter werden als Schlüsselwort=Wert-Paare bereitgestellt und können in beliebiger Reihenfolge angegeben werden, entweder mit mehreren-C
-Optionen oder als Kommata-getrennte Liste. Die Schlüsselwörter sind »addr«, »user«, »host«, »laddr«, »lport« und »rdomain« und entsprechen der Quelladresse, dem Benutzer, dem aufgelösten Quellrechnernamen, der lokalen Adresse, der lokalen Port-Nummer bzw. der Routing-Domain. -c
Rechnerzertifikatsdatei- Legt den Pfad zu einer Zertifikatsdatei fest, um
sshd
während des Schlüsselaustausches zu identifizieren. Die Zertifikatsdatei muss auf eine Rechnerschlüsseldatei passen, die mit der Option-h
oder der KonfigurationsdirektiveHostKey
festgelegt wird. -D
- Wenn diese Option angegeben ist, wird sich
sshd
nicht abtrennen und kein Daemon werden. Dies erlaubt das einfache Überwachen vonsshd
. -d
- Fehlersuchmodus. Der Server schickt ausführliche Fehlersuchausgaben
auf die Standardfehlerausgabe und legt sich selbst nicht in den
Hintergrund. Der Server wird auch kein fork(2)
durchführen und nur eine Verbindung verarbeiten. Diese Option ist
nur zur Fehlersuche im Server gedacht. Mehrere Optionen
-d
erhöhen die Fehlersuchstufe. Maximum ist 3. -E
Protokolldatei- Hängt Fehlersuchprotokolle an Protokolldatei statt an das Systemprotokoll an.
-e
- Schreibt Fehlersuchprotokolle in die Standardfehlerausgabe statt in das Systemprotokoll.
-f
Konfigurationsdatei- Gibt den Namen der Konfigurationsdatei an. Die Vorgabe ist
/etc/ssh/sshd_config.
sshd
verweigert den Start, falls es keine Konfigurationsdatei gibt. -g
Anmeldeaufschubzeit- Gibt die Aufschubzeit an, die Clients für die Authentifizierung haben (standardmäßig 120 Sekunden). Falls es dem Client nicht gelingt, sich innerhalb der angegebenen Sekunden zu authentifizieren, löst der Server die Verbindung und beendet sich. Ein Wert von 0 zeigt an, dass es keine Begrenzung geben soll.
-h
Rechnerschlüsseldatei- Gibt eine Datei an, aus der der Rechnerschlüssel gelesen wird.
Diese Option muss angegeben werden, falls
sshd
nicht als root ausgeführt wird (da die normalen Rechnerschlüsseldateien normalerweise nur von root lesbar sind). Die Vorgabe ist /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key und /etc/ssh/ssh_host_rsa_key. Es ist möglich, für die einzelnen Rechnerschlüsselalgorithmen jeweils mehrere Rechnerschlüsseldateien zu haben. -i
- Gibt an, dass
sshd
von inetd(8) ausgeführt wird. -o
Option- Kann dazu verwandt werden, Optionen im Format der Konfigurationsdatei anzugeben. Dies ist für Optionen nützlich, für die es keinen separaten Befehlszeilenschalter gibt. Für die vollständigen Details dieser Optionen und ihrer Werte siehe sshd_config(5).
-p
Port- Legt den Port fest, auf dem der Server auf Anfragen wartet
(standardmäßig 22). Mehrere Port-Optionen sind erlaubt. In
der Konfiguration mittels der Option
Port
festgelegte Ports werden ignoriert, wenn ein Port auf der Befehlszeile angegeben wird. Ports, die mit der OptionListenAddress
festgelegt werden, setzen auf der Befehlszeile angegebene außer Kraft. -q
- Stiller Modus. Es wird nichts an das Systemprotokoll gesandt. Normalerweise wird der Beginn, die Authentifizierung und die Beendigung jeder Verbindung protokolliert.
-T
- Erweiterter Testmodus. Prüft die Gültigkeit der
Konfigurationsdatei, gibt die wirksame Konfiguration auf der
Standardausgabe aus und beendet sich. Optional können die
Match
-Regeln angewandt werden, indem die Verbindungsparameter mittels einer oder mehrere Optionen-C
angegeben werden. -t
- Testmodus. Prüft nur die Gültigkeit der Konfigurationsdatei
und die Plausibilität der Schlüssel. Dies ist zur
zuverlässigen Aktualisierung von
sshd
nützlich, da sich Konfigurationsoptionen ändern könnten. -u
Länge- Diese Option wird dazu verwandt, die Größe des Feldes in der
Struktur utmp festzulegen, die den Namen des fernen
Rechners enthält. Falls der aufgelöste Rechnername die
angegebene Länge überschreitet, wird
stattdessen der gepunktete Dezimalwert verwandt. Dies erlaubt es, Rechner
mit sehr langen Rechnernamen, bei denen dieser Wert
überläuft, weiterhin eindeutig zu identifizieren. Die
Festlegung von
-u0
zeigt an, dass nur gepunktete Dezimaladressen in die Datei utmp abgelegt werden sollen.-u0
kann auch dazu verwandt werden,sshd
an der Durchführung von DNS-Anfragen zu hindern, außer der Authentifizierungsmechanismus oder die Konfiguration verlangt dies.HostbasedAuthentication
und die Verwendung der Optionfrom="Musterliste"
gehören zu den Authentifizierungsmechanismen, die DNS benötigen. Die Verwendung eines BENUTZER@RECHNER-Musters inAllowUsers
oderDenyUsers
gehört zu den Konfigurationsoptionen, die DNS benötigen. -V
- Zeigt die Version an und beendet das Programm.
AUTHENTIFIZIERUNG¶
Der OpenSSH-SSH-Daemon unterstützt nur SSH-Protokoll 2. Jeder Rechner verfügt über einen Rechner-spezifischen Schlüssel, der diesen Rechner identifiziert. Jedes Mal, wenn sich ein Client verbindet, antwortet der Daemon mit seinem öffentlichen Rechnerschlüssel. Der Client vergleicht den Rechnerschlüssel mit seiner eigenen Datenbank, um sicherzustellen, dass er sich nicht geändert hat. Durch eine Diffie-Hellman-Schlüsselvereinbarung wird Vorwärtssicherheit bereitgestellt. Diese Schlüsselvereinbarung führt zu einem gemeinsam benutzten Sitzungsschlüssel. Der Rest der Sitzung wird mit einer symmetrischen Chiffre verschlüsselt. Der Client wählt aus den vom Server angebotenen Chiffren den Verschlüsselungsalgorithmus aus. Zusätzlich wird die Sitzungsintegrität mittels eines kryptographischen Nachrichtenauthentifizierungscodes (MAC) bereitgestellt.
Schließlich treten der Server und der Client in einen Authentifizierungsdialog. Der Client versucht sich selbst mittels Rechner-basierter, asymmetrischer, challenge-response oder Passwort-basierter Authentifizierung zu authentifizieren.
Unabhängig vom Authentifizierungstyp wird das Konto
geprüft, um sicherzustellen, dass es zugreifbar ist. Ein Konto ist
nicht zugreifbar, falls es gesperrt, in DenyUsers
oder seine Gruppe in in DenyGroups
aufgeführt
ist. Die Definition eines gesperrten Kontos ist systemabhängig.
Einige Plattformen haben ihre eigene Kontendatenbank (z.B. AIX) und andere
ändern das Passwd-Feld (›*LK*‹ auf Solaris und
UnixWare, ›*‹ auf HP-UX, enthält
›NOLOGIN‹ auf Tru64, ein ›LOCKED‹ am Anfang auf
FreeBSD und ein ›!‹ am Anfang bei den meisten Linuxen). Falls
die Notwendigkeit besteht, Passwort-basierende Authentifizierung zu
deaktivieren, aber weiterhin asymmetrische Authentifizierung zu erlauben,
dann sollte das Passwd-Feld auf etwas anderes als diese Werte gesetzt werden
(z.B. ›NP‹ oder ›*NP*‹).
Falls sich der Client erfolgreich authentifiziert, wird ein Dialog zur Vorbereitung der Sitzung begonnen. 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 Verbindung des Authentifizierungsvermittlers über den sicheren Kanal erbitten.
Danach fordert der Client entweder eine interaktive Shell oder die
Ausführung eines nichtinteraktiven Befehls, den
sshd
mittels der Shell des Benutzers über die
Option -c
ausführt. Beide Seiten treten dann
in den Sitzungsmodus ein. In diesem Modus kann jede Seite zu jeder Zeit
Daten senden, und diese Daten werden dann an die Shell oder den Befehl auf
der Server-Seite und dem Terminal auf der Client-Seite weitergeleitet (oder
kommen von dort).
Wenn sich das Benutzerprogramm beendet und alle weitergeleiteten X11- und anderen Verbindungen geschlossen wurden, sendet der Server den Exit-Status an den Client und beide Seiten beenden sich.
ANMELDEPROZESS¶
Wenn sich ein Benutzer erfolgreich anmeldet, macht
sshd
Folgendes:
- Falls die Anmeldung auf einem TTY erfolgt und kein Befehl angegeben wurde, wird die letzte Anmeldezeit und /etc/motd ausgegeben (außer dies wird in der Konfigurationsdatei oder durch ~/.hushlogin verhindert, siehe den Abschnitt DATEIEN).
- Falls die Anmeldung auf einem TTY erfolgt, wird die Anmeldezeit aufgezeichnet.
- /etc/nologin wird überprüft; falls es existiert, wird der Inhalt ausgegeben und die Verbindung beendet (außer bei root).
- Die Ausführung wird auf normale Benutzerprivilegien umgeschaltet.
- Eine grundlegende Umgebung wird eingerichtet.
- Die Datei ~/.ssh/environment, falls sie existiert,
wird eingelesen und Benutzern wird das Ändern ihrer Umgebung
erlaubt. Siehe die Option
PermitUserEnvironment
in sshd_config(5). - Es wird in das Home-Verzeichnis des Benutzers gewechselt.
- Falls die Datei ~/.ssh/rc existiert und die Option
PermitUserRC
in sshd_config(5) gesetzt ist, wird die Datei ausgeführt, ansonsten falls /etc/ssh/sshrc existiert, wird diese ausgeführt, andernfalls wird xauth(1) ausgeführt. Den “rc” -Dateien wird das X11-Authentifizierungsprotokoll und den Cookie auf der Standardeingabe übergeben. Siehe nachfolgenden Abschnitt SSHRC. - Die Shell des Benutzers oder der Befehl wird ausgeführt. Alle Befehle werden unter der Anmelde-Shell des Benutzers ausgeführt, wie diese in der Systempasswortdatenbank festgelegt ist.
SSHRC¶
Falls die Datei ~/.ssh/rc existiert,
führt sh(1) sie nach dem Einlesen der
Umgebungsvariablen, aber vor dem Starten der Shell des Benutzers oder des
Befehls aus. Sie darf keine Ausgabe auf der Standardausgabe erstellen,
stattdessen muss Stderr verwandt werden. Falls X11-Weiterleitung in
Benutzung ist, wird sie das »proto cookie«-Paar in seiner
Standardeingabe (und DISPLAY
in seiner Umgebung)
erhalten. Das Skript muss xauth(1) aufrufen, da
sshd
Xauth nicht automatisch aufrufen wird, um
X11-Cookies hinzuzufügen.
Der Hauptzweck dieser Datei besteht darin, sämtliche Initialisierungsroutinen auszuführen, die benötigt werden, um auf das Home-Verzeichnis des Benutzers zuzugreifen; AFS ist ein besonderes Beispiel für solch eine Umgebung.
Diese Datei wird wahrscheinlich einigen Initialisierungs-Code enthalten, dem etwas ähnlicher Art folgt:
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
Falls diese Datei nicht existiert, wird /etc/ssh/sshrc ausgeführt und falls auch diese Datei nicht existiert, wird Xauth verwandt, um den Cookie hinzuzufügen.
AUTHORIZED_KEYS-DATEIFORMAT¶
AuthorizedKeysFile
legt die Dateien fest,
die öffentliche Schlüssel für die asymmetrische
Authentifizierung enthalten. Falls diese Option nicht festgelegt ist, ist
die Vorgabe ~/.ssh/authorized_keys und
~/.ssh/authorized_keys2. Jede Zeile der Datei
enthält einen Schlüssel (leere Zeilen und Zeilen, die mit
einem ‘#
’ 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
Optionenfeld ist optional. Die unterstützten Schlüsseltypen
sind:
- sk-ecdsa-sha2-nistp256@openssh.com
- ecdsa-sha2-nistp256
- ecdsa-sha2-nistp384
- ecdsa-sha2-nistp521
- sk-ssh-ed25519@openssh.com
- ssh-ed25519
- ssh-dss
- ssh-rsa
Das Kommentarfeld wird für nichts verwandt (kann aber für den Benutzer zur Identifikation des Schlüssels nützlich sein).
Beachten Sie, dass diese Zeilen in diesen Dateien mehrere hundert Byte lang sein können (aufgrund der Größe der Kodierung des öffentlichen Schlüssels), bis zu einer Grenze von 8 Kilobyte, wodurch RSA-Schlüssel bis zu 16 Kilobit erlaubt sind. Normalerweise geben Sie diese nicht ein, sondern kopieren die Datei id_dsa.pub, id_ecdsa.pub, id_ecdsa_sk.pub, id_ed25519.pub, id_ed25519_sk.pub oder id_rsa.pub und bearbeiten sie.
sshd
erzwingt eine minimale
RSA-Schlüssel-Modulogröße von 1024 Bit.
Falls Optionen vorhanden sind, werden diese durch Kommata getrennt angegeben. Leerzeichen sind nur innerhalb doppelter englischer Anführungszeichen erlaubt. Die folgenden Optionsangaben werden unterstützt (beachten Sie, dass bei Optionsschlüsselwörtern die Groß-/Kleinschreibung egal ist):
agent-forwarding
- Aktiviert den Weiterleitungsvermittler, der vorher mit der Option
restrict
deaktiviert war. - Legt fest, dass der aufgeführte Schlüssel eine
Zertifizierungsstelle (CA) ist, der vertraut wird, um signierte
Zertifikate zur Benutzerauthentifizierung zu validieren.
Zertifikate können Zugangsbeschränkungen festlegen, ähnlich wie bei Schlüsseloptionen. Falls sowohl Zertifikatsbeschränkungen als auch Schlüsseloptionen vorhanden sind, wird die restriktivste Vereinigung beider angewandt.
command="Befehl"
- Legt fest, dass der Befehl immer bei der Verwendung des Schlüssels
zur Authentifizierung ausgeführt wird. Der durch den Benutzer
bereitgestellte Schlüssel (falls vorhanden) wird ignoriert. Der
Befehl wird auf einem PTY ausgeführt, falls der Client ein PTY
anfordert; andernfalls läuft er ohne ein TTY. Falls ein
8-Bit-fähiger Kanal benötigt wird, darf kein PTY angefordert
werden oder es muss
no-pty
festgelegt werden. Um ein englisches Anführungszeichen in dem Befehl aufzuführen, stellen Sie ihm einen Rückwärtsschrägstrich voran.Diese Option kann zur Einschränkung bestimmter öffentlicher Schlüssel verwandt werden, damit diese nur eine bestimmte Aktion ausführen. Beispielsweise einen Schlüssel, der nur ferne Datensicherungen erlaubt, aber nichts sonst. Beachten Sie, dass der Client TCP- und/oder X11-Weiterleitung festlegen darf, außer dies wird explizit verboten, z.B. durch Verwendung der Schlüsseloption
restrict
.Der vom Client bereitgestellte Befehl ist in der Umgebungsvariablen
SSH_ORIGINAL_COMMAND
verfügbar. Beachten Sie, dass diese Option für eine Shell-, Befehls- oder Subsystemausführung gilt. Beachten Sie auch, dass dieser Befehl durch eine DirektiveForceCommand
in sshd_config(5) ersetzt werden kann.Falls ein Befehl festgelegt ist und ein Erzwingungsbefehl in einem für die Authentifizierung verwandten Zertifikat eingebettet ist, dann wird dieses Zertifikat nur akzeptiert, falls die zwei Befehle identisch sind.
environment="NAME=Wert"
- Legt fest, dass die Zeichenkette zu der Umgebung beim Protokollieren
hinzugefügt wird, wenn dieser Schlüssel verwandt wird. Auf
diese Art gesetzte Umgebungsvariablen setzen andere Vorgabeumgebungswerte
außer Kraft. Mehrere Optionen dieser Art sind erlaubt.
Standardmäßig ist die Verarbeitung der Umgebung deaktiviert
und wird mittels der Option
PermitUserEnvironment
gesteuert. expiry-time="Zeitangabe"
- Legt eine Zeit fest, nach der der Schlüssel nicht akzeptiert wird. Die Zeit kann als Datum YYYYMMDD[Z] oder eine Zeit YYYYMMDDHHMM[SS][Z] festgelegt werden. Daten und Zeiten werden in der Zeitzone des Systems interpretiert, außer es wird ein »Z«-Zeichen angehängt, dann werden sie in der UTC-Zeitzone interpretiert.
from="Musterliste"
- Legt fest, dass zusätzlich zur asymmetrischen Authentifizierung
entweder der kanonische Name des fernen Rechners oder seine IP-Adresse in
der Kommata-getrennten Liste der Muster vorhanden sein muss. Siehe MUSTER
in ssh_config(5) für weitere Informationen
über Muster.
Zusätzlich zum Platzhaltervergleich, der für Rechnernamen oder Adressen angewandt werden kann, kann ein
from
-Abschnitt auf IP-Adressen mit der CIDR address/masklen-Notation passen.Der Zweck dieser Option besteht darin, optional die Sicherheit zu erhöhen: asymmetrische Authentifizierung an sich vertraut dem Netzwerk oder den Name-Servern oder irgendetwas (außer dem Schlüssel) nicht. Falls allerdings jemand den Schlüssel klaut, ermöglicht er es dem Eindringling, sich von überall aus der Welt anzumelden. Diese zusätzliche Option erschwert den Einsatz eines gestohlenen Schlüssels (es müssten Name-Server und/oder Router zusätzlich kompromittiert werden, nicht nur der Schlüssel).
no-agent-forwarding
- Verbietet die Vermittlerweiterleitung der Authentifizierung, wenn dieser Schlüssel für die Authentifizierung verwandt wird.
no-port-forwarding
- Verbietet die TCP-Weiterleitung, wenn dieser Schlüssel für
die Authentifizierung verwandt wird. Jede Port-Weiterleitungsanfrage durch
den Client wird einen Fehler zurückliefern. Dies kann
beispielsweise bei Verbindungen mit der Option
command
verwandt werden. no-pty
- Verhindert TTY-Zuweisung (eine Anfrage, ein PTY zuzuweisen, wird fehlschlagen).
no-user-rc
- Deaktiviert die Ausführung von ~/.ssh/rc.
no-X11-forwarding
- Verbietet X11-Weiterleitung, wenn dieser Schlüssel zur Authentifizierung verwandt wird. Jede X11-Weiterleitungsanfrage vom Client wird einen Fehler zurückliefern.
permitlisten="[Rechner:]Port"
- Schränkt ferne Port-Weiterleitung mit der Option
-R
von ssh(1) ein, so dass es nur auf dem festgelegten Rechner (optional) und Port auf Anfragen wartet. IPv6-Adressen können durch Einschluss der Adresse in eckige Klammern festgelegt werden. Mehrere Optionenpermitlisten
können durch Kommata getrennt angewandt werden. Rechnernamen können Platzhalter enthalten, wie dies im Abschnitt MUSTER in ssh_config(5) beschrieben ist. Eine Port-Festlegung*
passt auf jeden Port. Beachten Sie, dass die EinstellungGatewayPorts
die Adressen, an denen auf Anfragen gewartet wird, weiter einschränken kann. Beachten Sie, dass ssh(1) einen Rechnernamen “localhost” senden wird, falls kein Rechner, an dem auf Anfragen gewartet werden soll, bei der Bitte um eine Weiterleitung angegeben wurde und dass dieser Name anders als die expliziten Localhost-Adressen “127.0.0.1” und “::1” behandelt wird. permitopen="Rechner:Port"
- Beschränkt Port-Weiterleitungen mit der Option
-L
von ssh(1), so dass nur Verbindungen zu dem festgelegten Rechner und Port möglich sind. IPv6-Adressen können durch Einschluss der Adresse in eckige Klammern festgelegt werden. Mehrere Optionenpermitopen
können durch Kommata getrennt angewandt werden. Es erfolgt bei den festgelegten Rechnernamen kein Mustervergleich und Namensauflösung, sie müssen wortwörtliche Rechnernamen und/oder Adressen sein. Eine Port-Festlegung*
passt auf jeden Port. port-forwarding
- Aktiviert Port-Weiterleitung, die vorher mit der Option
restrict
deaktiviert wurde. principals="Prinzipale"
- Legt auf einer
cert-authority
-Zeile die erlaubten Prinzipale für die Zertifikatsauthentifizierung als Kommata-getrennte Liste fest. Mindestens ein Name aus der Liste muss in der Zertifikatsliste der Prinzipale erscheinen, damit das Zertifikat akzeptiert wird. Diese Option wird für Schlüssel, die nicht mit der Optioncert-authority
als vertrauenswürdige Zertifikatsignierer markiert sind, ignoriert. pty
- Erlaubt TTY-Zuweisung, die vorher mit der Option
restrict
deaktiviert wurde. no-touch-required
- Erfordert keinen Nachweis der Anwesenheit des Benutzers für
Signaturen, die mittels dieses Schlüssels erfolgten. Diese Option
ergibt nur für die FIDO-Authenticator-Algorithmen
ecdsa-sk
unded25519-sk
Sinn. verify-required
- Verlangt, dass mit diesem Schlüssel erstellte Signaturen
beglaubigen, dass sie vom Benutzer bestätigt wurden, z.B.
über eine PIN. Diese Option ergibt nur für die
FIDO-Authenticator-Algorithmen
ecdsa-sk
unded25519-sk
Sinn. restrict
- Aktiviert alle Beschränkungen, d.h. deaktiviert die Weiterleitung vom Port, Vermittler und X11, sowie deaktiviert die PTY-Zuweisung und die Ausführung von ~/.ssh/rc. Falls zukünftig weitere Beschränkungsfähigkeiten zu den authorized_keys-Dateien hinzugefügt werden, werden sie in diese Menge aufgenommen.
tunnel="n"
- Erzwingt ein tun(4) -Gerät auf dem Server. Ohne diese Option wird das nächste verfügbare Gerät verwandt, falls der Client einen Tunnel anfordert.
user-rc
- Aktiviert die Ausführung von ~/.ssh/rc, die
vorher durch die Option
restrict
deaktiviert war. X11-forwarding
- Erlaubt X11-Weiterleitung, die vorher durch die Option
restrict
deaktiviert war.
Ein Beispiel für eine authorized_keys-Datei:
# Kommentare dürfen am Zeilenanfang anfangen. Leere Zeilen sind erlaubt. # Einfacher Schlüssel, keine Einschränkung ssh-rsa … # Befehl erzwingen, deaktiviert PTY und sämtliche Weiterleitung restrict,command="dump /home" ssh-rsa … # »ssh -L«-Weiterleitungsziele beschränken permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa … # Auf Anfrage wartende »ssh -R«-Weiterleitungen beschränken permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa … # Konfiguration für lokale Tunnel-Weiterleitung tunnel="0",command="sh /etc/netstart tun0" ssh-rsa … # Außerkraftsetzung der Beschränkung, um PTY-Zuweisungen zu erlauben restrict,pty,command="nethack" ssh-rsa … # FIDO-Schlüssel erlauben, ohne Berührung zu erzwingen no-touch-required sk-ecdsa-sha2-nistp256@openssh.com … # Benutzer-Überprüfung (z.B. PIN oder Biometrie) für FIDO-Schlüssel verlangen verify-required sk-ecdsa-sha2-nistp256@openssh.com … # CA-Schlüssel vertrauen, berühungsloses FIDO erlauben, falls im Zertifikat erbeten cert-authority,no-touch-required,principals="user_a" ssh-rsa …
SSH_KNOWN_HOSTS-DATEIFORMAT¶
Die Dateien /etc/ssh/ssh_known_hosts und ~/.ssh/known_hosts enthalten öffentliche Schlüssel für alle bekannten Rechner. Die globale Datei sollte durch den Administrator vorbereitet werden (optional) und die benutzerbezogene Datei wird automatisch verwaltet: immer wenn sich der Benutzer mit einem unbekannten Rechner verbindet, wird sein Schlüssel zu der benutzerbezogenen Datei hinzugefügt.
Jede Zeile in diesen Dateien enthält die folgenden Felder: Markierung (optional), Rechnername, Schlüsseltyp, Base64-kodierter Schlüssel, Kommentar. Die Felder sind durch Leerzeichen getrennt.
Die Markierung ist optional, falls sie aber vorhanden ist, muss sie entweder “@cert-authority” sein, um anzuzeigen, dass die Zeile einen Schlüssel einer Zertifizierungsstelle (CA) ist, oder “@revoked”, um anzuzeigen, dass der in der Zeile enthaltene Schlüssel zurückgezogen wurde und niemals akzeptiert werden darf. Auf einer Schlüsselzeile sollte nur eine Markierung verwandt werden.
Rechnernamen sind eine durch Kommata getrennte Liste von Mustern
(‘*
’ und
‘?
’ wirken als Platzhalter); jedes
Muster wiederum wird mit dem Rechnernamen verglichen. Wenn
sshd
einen Client authentifiziert, wie
beispielsweise bei der Verwendung von
HostbasedAuthentication
, wird dies der kanonische
Rechnername sein. Wenn ssh(1) durch einen Server
authentifiziert wird, wird dies der vom Benutzer angegebene Rechnername
sein, der Wert aus HostkeyAlias
von
ssh(1), falls dieser festgelegt wurde oder der kanonische
Rechnername, falls die Option CanonicalizeHostname
von ssh(1) verwandt wurde.
Einem Muster kann auch ‘!
’
als Zeichen für die Verneinung vorangestellt werden: falls der
Rechner auf ein verneintes Muster passt, wird er (durch diese Zeile)
überhaupt nicht akzeptiert, selbst falls er auf ein anderes Muster in
dieser Zeile passt. Ein Rechnername oder eine Adresse kann optional in die
Klammern ‘[
’ und
‘]
’ eingeschlossen sein, gefolgt dann
von einem ‘:
’ und einer individuellen
Port-Nummer.
Alternativ können Rechnernamen in einer gehashten Form
gespeichert werden. Diese versteckt die Rechnernamen und -adressen, sollte
der Inhalt der Datei offengelegt werden. Gehashte Rechnernamen beginnen mit
dem Zeichen ‘|
’. Auf einer Zeile darf
nur ein einzelner gehashter Rechername auftauchen und die oben beschriebenen
Verneinungs- und Platzhalteroperatoren dürfen nicht angewandt
werden.
Der Schlüsseltyp und der Base64-kodierte Schlüssel werden direkt aus dem Rechnerschlüssel entnommen; sie können beispielsweise aus /etc/ssh/ssh_host_rsa_key.pub erhalten werden. Das optionale Kommentarfeld geht bis zum Zeilenende und wird nicht verwandt.
Leere Zeilen und Zeilen, die mit
‘#
’ beginnen, werden als Kommentare
ignoriert.
Bei der Durchführung von Rechner-Authentifizierung wird die Authentifizierung akzeptiert, falls auf einer Zeile der geeignete Schlüssel steht; entweder einer, der genau passt oder, falls der Server ein Zertifikat für die Authentifizierung präsentiert hat, der Schlüssel der Zertifizierungsstelle, die das Zertifikat signierte. Damit einem Schlüssel von einer Zertifizierungsstelle vertraut wird, muss er die oben beschriebene Markierung “@cert-authority” verwenden.
Die Datei der bekannten Rechner bietet auch die Möglichkeit, Schlüssel als widerrufen zu markieren, wenn beispielsweise bekannt ist, dass der zugehörige private Schlüssel gestohlen wurde. Widerrufene Schlüssel werden gekennzeichnet, indem die Markierung “@revoked” am Anfang der Schlüsselzeile aufgenommen wird und diese werden für die Autorisierung oder als Zertifizierungsstelle niemals akzeptiert sondern führen zu einer Warnung durch ssh(1), wenn sie angetroffen werden.
Es ist erlaubt (wird aber nicht empfohlen), mehrere Zeilen oder verschiedene Rechnerschlüssel für den gleichen Namen zu haben. Dies wird zwangsläufig passieren, wenn Kurzformen von Rechnernamen von verschiedenen Domains in der Datei abgelegt werden. Es ist möglich, dass die Dateien widersprüchliche Informationen enthalten; Authentifizierung wird akzeptiert, falls gültige Informationen in einer der Dateien gefunden werden können.
Beachten Sie, dass die Zeilen in diesen Dateien normalerweise Hunderte von Zeichen lang sind und sie garantiert nicht die Rechnerschlüssel händisch eingeben wollen. Erstellen Sie sie eher durch ein Skript, ssh-keyscan(1), oder indem Sie beispielsweise /etc/ssh/ssh_host_rsa_key.pub verwenden und vorne Rechnernamen hinzufügen. ssh-keygen(1) bietet auch grundlegende automatische Bearbeitung von ~/.ssh/known_hosts an, einschließlich dem Entfernen von Rechnern, die auf einen Rechnernamen passen und die Umwandlung aller Rechnernamen in ihre gehashte Darstellung.
Beispiel für eine ssh_known_hosts-Datei:
# Kommentare am Zeilenanfang erlaubt cvs.example.net,192.0.2.10 ssh-rsa AAAA1234……= # Ein gehashter Rechnername |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa AAAA1234……= # Ein widerrufener Schlüssel @revoked * ssh-rsa AAAAB5W… # Ein CA-Schlüssel, akzeptiert für jeden Rechner in *.mydomain.com oder *.mydomain.org @cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W…
DATEIEN¶
- ~/.hushlogin
- Diese Datei wird zum Unterdrücken der Ausgabe der letzten
Anmeldezeit und von /etc/motd, falls
PrintLastLog
bzw.PrintMotd
aktiviert wurden, verwandt. Es unterdrückt nicht die Ausgabe des durchBanner
festgelegten Spruchtextes. - ~/.rhosts
- Diese Datei wird für Rechner-basierte Authentifizierung verwandt
(siehe ssh(1) für weitere Informationen). Auf
einigen Maschinen muss diese Datei für alle lesbar sein, falls sich
das Home-Verzeichnis des Benutzers auf einer NFS-Partition befindet, da
sshd
es als Root liest. Zusätzlich muss diese Datei dem Benutzer gehören und darf für keinen anderen eine Schreibberechtigung enthalten. Die empfohlenen Berechtigungen für die meisten Maschinen ist lesen/schreiben für den Benutzer und keinen Zugriff für alle anderen. - ~/.shosts
- Die Datei wird genau auf die gleiche Art wie .rhosts verwandt, erlaubt aber Rechner-basierte Authentifizierung, ohne Anmeldungen mittels Rlogin/Rsh zu ermöglichen.
- ~/.ssh/
- Das Verzeichnis ist der Standardort für alle benutzerspezifischen Konfigurations- und Authentifizierungsinformationen. Es gibt keine allgemeine Anforderung, sämtliche Informationen in diesem Verzeichnis geheim zu halten, aber die empfohlenen Berechtigungen sind Lesen/Schreiben/Ausführen für den Benutzer und kein Zugriff für andere.
- ~/.ssh/authorized_keys
- Listet die öffentlichen Schlüssel (DSA, ECDSA, Ed25519, RSA)
auf, die für die Anmeldung dieses Benutzers verwandt werden
können. Das Format dieser Datei ist oben beschrieben. Der Inhalt
der Datei ist nicht groß sensitiv, aber die empfohlenen
Berechtigungen sind lesen/schreiben für den Benutzer und kein
Zugriff für alle anderen.
Falls diese Datei, das Verzeichnis ~/.ssh oder das Home-Verzeichnis des Benutzer für andere Benutzer schreibbar sind, dann könnte diese Datei durch nicht berechtigte Benutzer verändert oder ausgetauscht werden. In diesem Fall wird
sshd
die Verwendung nicht erlauben, außer die OptionStrictModes
wurde auf “no” gesetzt. - ~/.ssh/environment
- Diese Datei wird (falls sie existiert) bei der Anmeldung in die Umgebung
gelesen. Sie darf nur leere Zeilen, Kommentarzeilen (die mit
‘
#
’ beginnen) und Zuweisungszeilen der Form Name=Wert enthalten. Die Datei sollte nur für den Benutzer schreibbar sein; kein anderer Benutzer muss sie lesen können. Standardmäßig ist die Verarbeitung der Umgebung deaktiviert und dies wird über die OptionPermitUserEnvironment
gesteuert. - ~/.ssh/known_hosts
- Enthält eine Liste von Rechnerschlüsseln für alle Rechner, bei denen sich der Benutzer angemeldet hat und die nicht bereits in der systemweiten Liste der bekannten Rechner enthalten sind. Das Format dieser Datei ist oben beschrieben. Diese Datei sollte nur für den Benutzer/root les-/schreibbar sein und muss nicht für alle lesbar sein.
- ~/.ssh/rc
- Enthält Initialisierungsroutinen, die ausgeführt werden sollen, bevor das Home-Verzeichnis des Benutzers zugreifbar wird. In diese Datei sollte nur der Benutzer schreiben können und sie muss nicht für andere lesbar sein.
- /etc/hosts.allow
- /etc/hosts.deny
- Zugriffssteuerungen, die durch tcp-wrappers erzwungen werden sollen, sind hier definiert. Weitere Details sind in hosts_access(5) beschrieben.
- /etc/hosts.equiv
- Diese Datei ist für Rechner-basierte Authentifizierung (siehe ssh(1)). Sie sollte nur für Root beschreibbar sein.
- /etc/ssh/moduli
- Enthält Diffie-Hellman-Gruppen, die für die »Diffie-Hellman Group Exchange«-Schlüsselaustauschmethode verwandt werden. Das Dateiformat ist in moduli(5) beschrieben. Falls keine benutzbaren Gruppen in dieser Datei gefunden werden, dann werden interne Gruppen verwandt.
- /etc/motd
- Siehe motd(5).
- /etc/nologin
- Falls diese Datei existiert, wird
sshd
die Anmeldung aller Benutzer außer Root ablehnen. Der Inhalt der Datei wird allen angezeigt, die eine Anmeldung versuchen und alle Anmeldungen außer Root werden abgelehnt. Die Datei sollte für jeden Benutzer lesbar sein. - /etc/ssh/shosts.equiv
- Die Datei wird genau auf die gleiche Art wie hosts.equiv verwandt, erlaubt aber Rechner-basierte Authentifizierung, ohne Anmeldungen mittels Rlogin/Rsh zu ermöglichen.
- /etc/ssh/ssh_host_ecdsa_key
- /etc/ssh/ssh_host_ed25519_key
- /etc/ssh/ssh_host_rsa_key
- Diese Dateien enthalten die privaten Anteile der Rechnerschlüssel.
Diese Dateien sollten nur Root gehören, nur von Root lesbar sein
und andere sollten keinen Zugriff darauf haben. Beachten Sie, dass
sshd
nicht startet, wenn auf diese Dateien von Gruppen oder anderen Benutzern zugegriffen werden kann. - /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 Anteile der Rechnerschlüssel. Diese Dateien sollten von jedem gelesen werden können, aber nur für Root schreibbar sein. Ihre Inhalte sollten auf die entsprechenden privaten Teile passen. Diese Dateien werden nicht wirklich für etwas verwandt, sie sind zum Nutzen der Benutzer bereitgestellt, so dass ihr Inhalt in die Datei bekannter Rechner kopiert werden kann. Diese Dateien werden mittels ssh-keygen(1) erstellt.
- /etc/ssh/ssh_known_hosts
- Systemweite Liste der Schlüssel der bekannten Rechner. Diese Datei sollte durch den Systemadministrator zusammengestellt werden, um die Rechner-Schlüssel aller Maschinen in der Organisation zu enthalten. Das Format der Datei wird oben beschrieben. Diese Datei sollte nur von Root/dem Eigentümer beschreibbar sein und von jedem gelesen werden können.
- /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 sie global zur Angabe maschinen-spezifischer Initialisierung zum Anmeldezeitpunkt verwandt werden. Diese Datei sollte nur durch Root beschreibbar und von jedem lesbar sein.
- /run/sshd
- Das von
sshd
während der Privilegientrennung in der Vor-Authentifizierungsphase verwandte chroot(2) -Verzeichnis. Das Verzeichnis sollte keine Dateien enthalten und muss Root gehören und nicht für Gruppen oder alle anderen beschreibbar sein. - /run/sshd.pid
- Enthält die Prozesskennung des
sshd
, das auf Verbindungen wartet (falls es mehrere Daemons gibt, die gleichzeitig auf verschiedenen Ports laufen, enthält dies die Prozesskennung des zuletzt gestarteten). Der Inhalt dieser Datei ist nicht sensitiv; sie kann für alle 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 freien SSH-1.2.12-Veröffentlichung durch Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt und Dug Song entfernten viele Fehler, fügten neue Funktionalitäten wieder hinzu und erstellten OpenSSH. Markus Friedl steuerte die Unterstützung für SSH-Protokollversion 1.5 und 2.0 bei. Niels Provos und Markus Friedl steuerten die Unterstützung für die Privilegientrennung bei.
ÜBERSETZUNG¶
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org
$Mdocdate: 18. Januar 2023 $ | Debian |