| SSHD(8) | System Manager's Manual | SSHD(8) |
sshd —
OpenSSH-Daemon
sshd [-46DdeiqTt]
[-C Verbindungsfestlegung]
[-c Rechnerzertifikatsdatei]
[-E Protokolldatei]
[-f Konfigurationsdatei]
[-g Anmeldeaufschubzeit]
[-h Rechnerschlüsseldatei]
[-o Option]
[-p Port]
[-u Länge]
sshd (OpenSSH Daemon) ist das
Daemon-Programm für ssh(1). Zusammen ersetzen diese
Programme rlogin and rsh und stellen 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:
-4sshd nur IPv4-Adressen
verwendet.-6sshd nur IPv6-Adressen
verwendet.-C
Verbindungsfestlegung-T verwandt werden sollen. Falls
bereitgestellt, werden alle Direktiven Match 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
Rechnerzertifikatsdateisshd während des
Schlüsselaustausches zu identifizieren. Die Zertifikatsdatei muss
auf eine Rechnerschlüsseldatei passen, die mit der Option
-h oder der Konfigurationsdirektive
HostKey festgelegt wird.-Dsshd
nicht abtrennen und kein Daemon werden. Dies erlaubt das einfache
Überwachen von sshd.-d-d erhöhen
die Fehlersuchstufe. Maximum ist 3.-E
Protokolldatei-e-f
Konfigurationsdateisshd
verweigert den Start, falls es keine Konfigurationsdatei gibt.-g
Anmeldeaufschubzeit-h
Rechnerschlüsseldateisshd
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.-isshd von inetd(8)
ausgeführt wird.-o
Option-p
PortPort
festgelegte Ports werden ignoriert, wenn ein Port auf der Befehlszeile
angegeben wird. Ports, die mit der Option
ListenAddress festgelegt werden, setzen auf der
Befehlszeile angegebene außer Kraft.-q-TMatch -Regeln angewandt werden, indem die
Verbindungsparameter mittels einer oder mehrere Optionen
-C angegeben werden.-tsshd
nützlich, da sich Konfigurationsoptionen ändern
könnten.-u
Längeutmp 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
Option from="Musterliste" gehören
zu den Authentifizierungsmechanismen, die DNS benötigen. Die
Verwendung eines BENUTZER@RECHNER-Musters in
AllowUsers oder DenyUsers
gehört zu den Konfigurationsoptionen, die DNS
benötigen.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 erbittet der Client entweder eine Shell oder die Ausführung eines Befehls. 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.
Wenn sich ein Benutzer erfolgreich anmeldet, macht
sshd Folgendes:
PermitUserEnvironment in
sshd_config(5).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 ausgeführt. Den
“rc” -Dateien wird das X11-Authentifizierungsprotokoll und
den Cookie auf der Standardeingabe übergeben. Siehe nachfolgenden
Abschnitt 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.
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:
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-forwardingrestrict deaktiviert war.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"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 Direktive
ForceCommand 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"PermitUserEnvironment
gesteuert.expiry-time="Zeitangabe"from="Musterliste"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-forwardingno-port-forwardingcommand verwandt werden.no-ptyno-user-rcno-X11-forwardingpermitlisten="[Rechner:]Port"-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 Optionen
permitlisten 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 Einstellung GatewayPorts
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"-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 Optionen
permitopen 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-forwardingrestrict deaktiviert wurde.principals="Prinzipale"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 Option cert-authority als
vertrauenswürdige Zertifikatsignierer markiert sind,
ignoriert.ptyrestrict deaktiviert wurde.no-touch-requiredecdsa-sk und ed25519-sk
Sinn.verify-requiredecdsa-sk und
ed25519-sk Sinn.restricttunnel="n"user-rcrestrict deaktiviert
war.X11-forwardingrestrict deaktiviert war.Ein Beispiel für eine authorized_keys-Datei:
# Am Anfang der Zeile sind Kommentare erlaubt ssh-rsa AAAAB3Nza…LiPk== user@example.net from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2…19Q== john@example.net command="dump /home",no-pty,no-port-forwarding ssh-rsa AAAAC3…51R== example.net permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa AAAAB5…21S== permitlisten="localhost:8080",permitopen="localhost:22000" ssh-rsa AAAAB5…21S== tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA…== jane@example.net restrict,command="uptime" ssh-rsa AAAA1C8…32Tv== user@example.net restrict,pty,command="nethack" ssh-rsa AAAA1f8…IrrC5== user@example.net no-touch-required sk-ecdsa-sha2-nistp256@openssh.com AAAAInN…Ko== user@example.net
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: Markierungen (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 closenet,…,192.0.2.53 1024 37 159…93 closenet.example.net 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…
PrintLastLog bzw.
PrintMotd aktiviert wurden, verwandt. Es
unterdrückt nicht die Ausgabe des durch
Banner festgelegten Spruchtextes.
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.
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 Option
StrictModes wurde auf “no”
gesetzt.
#’ 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 Option
PermitUserEnvironment gesteuert.
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.
sshd nicht startet, wenn auf diese Dateien von
Gruppen oder anderen Benutzern zugegriffen werden kann.
sshd. Das Dateiformat und die
Konfigurationsoptionen sind in sshd_config(5)
beschrieben.
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.
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.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)
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.
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
| $Mdocdate: 27. August 2020 $ | Debian |