SSHD(8) System Manager's Manual SSHD(8) BEZEICHNUNG sshd - OpenSSH-Daemon UBERSICHT sshd [-46DdeGiqTtV] [-C Verbindungsfestlegung] [-c Rechnerzertifikatsdatei] [-E Protokolldatei] [-f Konfigurationsdatei] [-g Anmeldeaufschubzeit] [-h Rechnerschlusseldatei] [-o Option] [-p Port] [-u Lange] BESCHREIBUNG sshd (OpenSSH Daemon) ist das Daemon-Programm fur ssh(1). Es stellt eine sichere verschlusselte Kommunikation zwischen zwei nicht vertrauenswurdigen Rechnern uber ein unsicheres Netzwerk bereit. sshd wartet auf Anfragen von Clients. Es wird normalerweise beim Systemstart mittels /etc/rc gestartet. Es erstellt mit Fork einen neuen Deamon fur jede Verbindung. Der mit Fork erstellte Daemon handhabt den Schlusselaustausch, die Verschlusselung, Authentifizierung, die Befehlsausfuhrung und den Datenaustausch. sshd kann mittels Befehlszeilenoptionen oder einer Konfigurationsdatei (standardmassig sshd_config(5)) konfiguriert werden; Befehlszeilenoptionen setzen die in der Konfigurationsdatei gesetzten Werte ausser Kraft. sshd liest seine Konfigurationsdatei neu, wenn er ein Auflegen-Signal, SIGHUP, erhalt, indem er sich selbst mit dem Namen und den Optionen ausfuhrt, mit denen er gestartet wurde, z.B. /usr/sbin/sshd. Folgende Optionen stehen zur Verfugung: -4 Erzwingt, dass sshd nur IPv4-Adressen verwendet. -6 Erzwingt, dass sshd nur IPv6-Adressen verwendet. -C Verbindungsfestlegung Legt die Verbindungsparameter fest, die fur den erweiterten Testmodus -T verwandt werden sollen. Falls bereitgestellt, werden alle Direktiven Match in der Konfigurationsdatei, die angewandt wurden, angewandt, bevor die Konfigurationsdatei auf die Standardausgabe geschrieben wird. Die Verbindungsparameter werden als Schlusselwort=Wert-Paare bereitgestellt und konnen in beliebiger Reihenfolge angegeben werden, entweder mit mehreren -C -Optionen oder als Kommata-getrennte Liste. Die Schlusselworter sind >>addr<<, >>user<<, >>host<<, >>laddr<<, >>lport<< und >>rdomain<< und entsprechen der Quelladresse, dem Benutzer, dem aufgelosten Quellrechnernamen, der lokalen Adresse, der lokalen Port-Nummer bzw. der Routing-Domain. -c Rechnerzertifikatsdatei Legt den Pfad zu einer Zertifikatsdatei fest, um sshd wahrend des Schlusselaustausches zu identifizieren. Die Zertifikatsdatei muss auf eine Rechnerschlusseldatei passen, die mit der Option -h oder der Konfigurationsdirektive HostKey festgelegt wird. -D Wenn diese Option angegeben ist, wird sich sshd nicht abtrennen und kein Daemon werden. Dies erlaubt das einfache Uberwachen von sshd. -d Fehlersuchmodus. Der Server schickt ausfuhrliche Fehlersuchausgaben auf die Standardfehlerausgabe und legt sich selbst nicht in den Hintergrund. Der Server wird auch kein fork(2) durchfuhren und nur eine Verbindung verarbeiten. Diese Option ist nur zur Fehlersuche im Server gedacht. Mehrere Optionen -d erhohen die Fehlersuchstufe. Maximum ist 3. -E Protokolldatei Hangt 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 Konfigurationsdatei auswerten und ausgeben. Pruft die Gultigkeit der Konfigurationsdatei, gibt die wirksame Konfiguration auf der Standardausgabe aus und beendet sich. Optional konnen die Match -Regeln angewandt werden, indem die Verbindungsparameter mittels einer oder mehrere Optionen -C angegeben werden. -g Anmeldeaufschubzeit Gibt die Aufschubzeit an, die Clients fur die Authentifizierung haben (standardmassig 120 Sekunden). Falls es dem Client nicht gelingt, sich innerhalb der angegebenen Sekunden zu authentifizieren, lost der Server die Verbindung und beendet sich. Ein Wert von 0 zeigt an, dass es keine Begrenzung geben soll. -h Rechnerschlusseldatei Gibt eine Datei an, aus der der Rechnerschlussel gelesen wird. Diese Option muss angegeben werden, falls sshd nicht als root ausgefuhrt wird (da die normalen Rechnerschlusseldateien 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 moglich, fur die einzelnen Rechnerschlusselalgorithmen jeweils mehrere Rechnerschlusseldateien zu haben. -i Gibt an, dass sshd von inetd(8) ausgefuhrt wird. -o Option Kann dazu verwandt werden, Optionen im Format der Konfigurationsdatei anzugeben. Dies ist fur Optionen nutzlich, fur die es keinen separaten Befehlszeilenschalter gibt. Fur die vollstandigen Details dieser Optionen und ihrer Werte siehe sshd_config(5). -p Port Legt den Port fest, auf dem der Server auf Anfragen wartet (standardmassig 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 Option ListenAddress festgelegt werden, setzen auf der Befehlszeile angegebene ausser 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. Pruft die Gultigkeit der Konfigurationsdatei, gibt die wirksame Konfiguration auf der Standardausgabe aus und beendet sich. Optional konnen die Match -Regeln angewandt werden, indem die Verbindungsparameter mittels einer oder mehrere Optionen -C angegeben werden. Dies ist ahnlich zum Schalter -G, schliesst aber die durch den Schalter -t durchgefuhrten zusatzlichen Tests ein. -t Testmodus. Pruft nur die Gultigkeit der Konfigurationsdatei und die Plausibilitat der Schlussel. Dies ist zur zuverlassigen Aktualisierung von sshd nutzlich, da sich Konfigurationsoptionen andern konnten. -u Lange Diese Option wird dazu verwandt, die Grosse des Feldes in der Struktur utmp festzulegen, die den Namen des fernen Rechners enthalt. Falls der aufgeloste Rechnername die angegebene Lange uberschreitet, wird stattdessen der gepunktete Dezimalwert verwandt. Dies erlaubt es, Rechner mit sehr langen Rechnernamen, bei denen dieser Wert uberlauft, 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 Durchfuhrung von DNS-Anfragen zu hindern, ausser der Authentifizierungsmechanismus oder die Konfiguration verlangt dies. HostbasedAuthentication und die Verwendung der Option from="Musterliste" gehoren zu den Authentifizierungsmechanismen, die DNS benotigen. Die Verwendung eines BENUTZER@RECHNER-Musters in AllowUsers oder DenyUsers gehort zu den Konfigurationsoptionen, die DNS benotigen. -V Zeigt die Version an und beendet das Programm. AUTHENTIFIZIERUNG Der OpenSSH-SSH-Daemon unterstutzt nur SSH-Protokoll 2. Jeder Rechner verfugt uber einen Rechner-spezifischen Schlussel, der diesen Rechner identifiziert. Jedes Mal, wenn sich ein Client verbindet, antwortet der Daemon mit seinem offentlichen Rechnerschlussel. Der Client vergleicht den Rechnerschlussel mit seiner eigenen Datenbank, um sicherzustellen, dass er sich nicht geandert hat. Durch eine Diffie-Hellman- Schlusselvereinbarung wird Vorwartssicherheit bereitgestellt. Diese Schlusselvereinbarung fuhrt zu einem gemeinsam benutzten Sitzungsschlussel. Der Rest der Sitzung wird mit einer symmetrischen Chiffre verschlusselt. Der Client wahlt aus den vom Server angebotenen Chiffren den Verschlusselungsalgorithmus aus. Zusatzlich wird die Sitzungsintegritat mittels eines kryptographischen Nachrichtenauthentifizierungscodes (MAC) bereitgestellt. Schliesslich 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. Unabhangig vom Authentifizierungstyp wird das Konto gepruft, um sicherzustellen, dass es zugreifbar ist. Ein Konto ist nicht zugreifbar, falls es gesperrt, in DenyUsers oder seine Gruppe in in DenyGroups aufgefuhrt ist. Die Definition eines gesperrten Kontos ist systemabhangig. Einige Plattformen haben ihre eigene Kontendatenbank (z.B. AIX) und andere andern das Passwd-Feld (>*LK*< auf Solaris und UnixWare, >*< auf HP-UX, enthalt >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 uber den sicheren Kanal erbitten. Danach erbittet der Client entweder eine interaktive Shell oder die Ausfuhrung eines nichtinteraktiven Befehls, den sshd mittels der Shell des Benutzers uber die Option -c ausfuhrt. 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: 1. Falls die Anmeldung auf einem TTY erfolgt und kein Befehl angegeben wurde, wird die letzte Anmeldezeit und /etc/motd ausgegeben (ausser dies wird in der Konfigurationsdatei oder durch ~/.hushlogin verhindert, siehe den Abschnitt DATEIEN). 2. Falls die Anmeldung auf einem TTY erfolgt, wird die Anmeldezeit aufgezeichnet. 3. /etc/nologin wird uberpruft; falls es existiert, wird der Inhalt ausgegeben und die Verbindung beendet (ausser bei root). 4. Die Ausfuhrung wird auf normale Benutzerprivilegien umgeschaltet. 5. Eine grundlegende Umgebung wird eingerichtet. 6. Die Datei ~/.ssh/environment, falls sie existiert, wird eingelesen und Benutzern wird das Andern ihrer Umgebung erlaubt. Siehe die Option PermitUserEnvironment in sshd_config(5). 7. Es wird in das Home-Verzeichnis des Benutzers gewechselt. 8. Falls die Datei ~/.ssh/rc existiert und die Option PermitUserRC in sshd_config(5) gesetzt ist, wird die Datei ausgefuhrt, ansonsten falls /etc/ssh/sshrc existiert, wird diese ausgefuhrt, andernfalls wird xauth(1) ausgefuhrt. Den "rc" -Dateien wird das X11-Authentifizierungsprotokoll und den Cookie auf der Standardeingabe ubergeben. Siehe nachfolgenden Abschnitt SSHRC. 9. Die Shell des Benutzers oder der Befehl wird ausgefuhrt. Alle Befehle werden unter der Anmelde-Shell des Benutzers ausgefuhrt, wie diese in der Systempasswortdatenbank festgelegt ist. SSHRC Falls die Datei ~/.ssh/rc existiert, fuhrt 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 hinzuzufugen. Der Hauptzweck dieser Datei besteht darin, samtliche Initialisierungsroutinen auszufuhren, die benotigt werden, um auf das Home-Verzeichnis des Benutzers zuzugreifen; AFS ist ein besonderes Beispiel fur solch eine Umgebung. Diese Datei wird wahrscheinlich einigen Initialisierungs-Code enthalten, dem etwas ahnlicher 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 ausgefuhrt und falls auch diese Datei nicht existiert, wird Xauth verwandt, um den Cookie hinzuzufugen. AUTHORIZED_KEYS-DATEIFORMAT AuthorizedKeysFile legt die Dateien fest, die offentliche Schlussel fur die asymmetrische Authentifizierung enthalten. Falls diese Option nicht festgelegt ist, ist die Vorgabe ~/.ssh/authorized_keys und ~/.ssh/authorized_keys2. Jede Zeile der Datei enthalt einen Schlussel (leere Zeilen und Zeilen, die mit einem `#' beginnen, werden als Kommentare ignoriert). Offentliche Schlussel bestehen aus den folgenden, durch Leerzeichen getrennten Feldern: Optionen, Schlusseltyp, Base64-kodierter Schlussel, Kommentar. Das Optionenfeld ist optional. Die unterstutzten Schlusseltypen 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 fur nichts verwandt (kann aber fur den Benutzer zur Identifikation des Schlussels nutzlich sein). Beachten Sie, dass diese Zeilen in diesen Dateien mehrere hundert Byte lang sein konnen (aufgrund der Grosse der Kodierung des offentlichen Schlussels), bis zu einer Grenze von 8 Kilobyte, wodurch RSA-Schlussel 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-Schlussel-Modulogrosse von 1024 Bit. Falls Optionen vorhanden sind, werden diese durch Kommata getrennt angegeben. Leerzeichen sind nur innerhalb doppelter englischer Anfuhrungszeichen erlaubt. Die folgenden Optionsangaben werden unterstutzt (beachten Sie, dass bei Optionsschlusselwortern die Gross-/Kleinschreibung egal ist): agent-forwarding Aktiviert den Weiterleitungsvermittler, der vorher mit der Option restrict deaktiviert war. cert-authority Legt fest, dass der aufgefuhrte Schlussel eine Zertifizierungsstelle (CA) ist, der vertraut wird, um signierte Zertifikate zur Benutzerauthentifizierung zu validieren. Zertifikate konnen Zugangsbeschrankungen festlegen, ahnlich wie bei Schlusseloptionen. Falls sowohl Zertifikatsbeschrankungen als auch Schlusseloptionen vorhanden sind, wird die restriktivste Vereinigung beider angewandt. command="Befehl" Legt fest, dass der Befehl immer bei der Verwendung des Schlussels zur Authentifizierung ausgefuhrt wird. Der durch den Benutzer bereitgestellte Schlussel (falls vorhanden) wird ignoriert. Der Befehl wird auf einem PTY ausgefuhrt, falls der Client ein PTY anfordert; andernfalls lauft er ohne ein TTY. Falls ein 8-Bit-fahiger Kanal benotigt wird, darf kein PTY angefordert werden oder es muss no-pty festgelegt werden. Um ein englisches Anfuhrungszeichen in dem Befehl aufzufuhren, stellen Sie ihm einen Ruckwartsschragstrich voran. Diese Option kann zur Einschrankung bestimmter offentlicher Schlussel verwandt werden, damit diese nur eine bestimmte Aktion ausfuhren. Beispielsweise einen Schlussel, der nur ferne Datensicherungen erlaubt, aber nichts sonst. Beachten Sie, dass der Client TCP- und/oder X11-Weiterleitung festlegen darf, ausser dies wird explizit verboten, z.B. durch Verwendung der Schlusseloption restrict. Der vom Client bereitgestellte Befehl ist in der Umgebungsvariablen SSH_ORIGINAL_COMMAND verfugbar. Beachten Sie, dass diese Option fur eine Shell-, Befehls- oder Subsystemausfuhrung 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 fur 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 hinzugefugt wird, wenn dieser Schlussel verwandt wird. Auf diese Art gesetzte Umgebungsvariablen setzen andere Vorgabeumgebungswerte ausser Kraft. Mehrere Optionen dieser Art sind erlaubt. Standardmassig ist die Verarbeitung der Umgebung deaktiviert und wird mittels der Option PermitUserEnvironment gesteuert. expiry-time="Zeitangabe" Legt eine Zeit fest, nach der der Schlussel 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, ausser es wird ein >>Z<<-Zeichen angehangt, dann werden sie in der UTC-Zeitzone interpretiert. from="Musterliste" Legt fest, dass zusatzlich 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) fur weitere Informationen uber Muster. Zusatzlich zum Platzhaltervergleich, der fur 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 erhohen: asymmetrische Authentifizierung an sich vertraut dem Netzwerk oder den Name-Servern oder irgendetwas (ausser dem Schlussel) nicht. Falls allerdings jemand den Schlussel klaut, ermoglicht er es dem Eindringling, sich von uberall aus der Welt anzumelden. Diese zusatzliche Option erschwert den Einsatz eines gestohlenen Schlussels (es mussten Name-Server und/oder Router zusatzlich kompromittiert werden, nicht nur der Schlussel). no-agent-forwarding Verbietet die Vermittlerweiterleitung der Authentifizierung, wenn dieser Schlussel fur die Authentifizierung verwandt wird. no-port-forwarding Verbietet die TCP-Weiterleitung, wenn dieser Schlussel fur die Authentifizierung verwandt wird. Jede Port-Weiterleitungsanfrage durch den Client wird einen Fehler zuruckliefern. 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 Ausfuhrung von ~/.ssh/rc. no-X11-forwarding Verbietet X11-Weiterleitung, wenn dieser Schlussel zur Authentifizierung verwandt wird. Jede X11-Weiterleitungsanfrage vom Client wird einen Fehler zuruckliefern. permitlisten="[Rechner:]Port" Schrankt 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 konnen durch Einschluss der Adresse in eckige Klammern festgelegt werden. Mehrere Optionen permitlisten konnen durch Kommata getrennt angewandt werden. Rechnernamen konnen 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 einschranken 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" Beschrankt Port-Weiterleitungen mit der Option -L von ssh(1), so dass nur Verbindungen zu dem festgelegten Rechner und Port moglich sind. IPv6-Adressen konnen durch Einschluss der Adresse in eckige Klammern festgelegt werden. Mehrere Optionen permitopen konnen durch Kommata getrennt angewandt werden. Es erfolgt bei den festgelegten Rechnernamen kein Mustervergleich und Namensauflosung, sie mussen wortwortliche 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 fur 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 fur Schlussel, die nicht mit der Option cert-authority als vertrauenswurdige 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 fur Signaturen, die mittels dieses Schlussels erfolgten. Diese Option ergibt nur fur die FIDO-Authenticator-Algorithmen ecdsa-sk und ed25519-sk Sinn. verify-required Verlangt, dass mit diesem Schlussel erstellte Signaturen beglaubigen, dass sie vom Benutzer bestatigt wurden, z.B. uber eine PIN. Diese Option ergibt nur fur die FIDO-Authenticator- Algorithmen ecdsa-sk und ed25519-sk Sinn. restrict Aktiviert alle Beschrankungen, d.h. deaktiviert die Weiterleitung vom Port, Vermittler und X11, sowie deaktiviert die PTY-Zuweisung und die Ausfuhrung von ~/.ssh/rc. Falls zukunftig weitere Beschrankungsfahigkeiten zu den authorized_keys-Dateien hinzugefugt werden, werden sie in diese Menge aufgenommen. tunnel="n" Erzwingt ein tun(4) -Gerat auf dem Server. Ohne diese Option wird das nachste verfugbare Gerat verwandt, falls der Client einen Tunnel anfordert. user-rc Aktiviert die Ausfuhrung 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 fur eine authorized_keys-Datei: # Kommentare durfen am Zeilenanfang anfangen. Leere Zeilen sind erlaubt. # Einfacher Schlussel, keine Einschrankung ssh-rsa # Befehl erzwingen, deaktiviert PTY und samtliche Weiterleitung restrict,command="dump /home" ssh-rsa # >>ssh -L<<-Weiterleitungsziele beschranken permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa # Auf Anfrage wartende >>ssh -R<<-Weiterleitungen beschranken permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa # Konfiguration fur lokale Tunnel-Weiterleitung tunnel="0",command="sh /etc/netstart tun0" ssh-rsa # Ausserkraftsetzung der Beschrankung, um PTY-Zuweisungen zu erlauben restrict,pty,command="nethack" ssh-rsa # FIDO-Schlussel erlauben, ohne Beruhrung zu erzwingen no-touch-required sk-ecdsa-sha2-nistp256@openssh.com # Benutzer-Uberprufung (z.B. PIN oder Biometrie) fur FIDO-Schlussel verlangen verify-required sk-ecdsa-sha2-nistp256@openssh.com # CA-Schlussel vertrauen, beruhungsloses 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 offentliche Schlussel fur 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 Schlussel zu der benutzerbezogenen Datei hinzugefugt. Jede Zeile in diesen Dateien enthalt die folgenden Felder: Markierung (optional), Rechnername, Schlusseltyp, Base64-kodierter Schlussel, 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 Schlussel einer Zertifizierungsstelle (CA) ist, oder "@revoked", um anzuzeigen, dass der in der Zeile enthaltene Schlussel zuruckgezogen wurde und niemals akzeptiert werden darf. Auf einer Schlusselzeile 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 fur die Verneinung vorangestellt werden: falls der Rechner auf ein verneintes Muster passt, wird er (durch diese Zeile) uberhaupt 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 konnen 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 durfen nicht angewandt werden. Der Schlusseltyp und der Base64-kodierte Schlussel werden direkt aus dem Rechnerschlussel entnommen; sie konnen 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 Durchfuhrung von Rechner-Authentifizierung wird die Authentifizierung akzeptiert, falls auf einer Zeile der geeignete Schlussel steht; entweder einer, der genau passt oder, falls der Server ein Zertifikat fur die Authentifizierung prasentiert hat, der Schlussel der Zertifizierungsstelle, die das Zertifikat signierte. Damit einem Schlussel von einer Zertifizierungsstelle vertraut wird, muss er die oben beschriebene Markierung "@cert-authority" verwenden. Die Datei der bekannten Rechner bietet auch die Moglichkeit, Schlussel als widerrufen zu markieren, wenn beispielsweise bekannt ist, dass der zugehorige private Schlussel gestohlen wurde. Widerrufene Schlussel werden gekennzeichnet, indem die Markierung "@revoked" am Anfang der Schlusselzeile aufgenommen wird und diese werden fur die Autorisierung oder als Zertifizierungsstelle niemals akzeptiert sondern fuhren zu einer Warnung durch ssh(1), wenn sie angetroffen werden. Es ist erlaubt (wird aber nicht empfohlen), mehrere Zeilen oder verschiedene Rechnerschlussel fur den gleichen Namen zu haben. Dies wird zwangslaufig passieren, wenn Kurzformen von Rechnernamen von verschiedenen Domains in der Datei abgelegt werden. Es ist moglich, dass die Dateien widerspruchliche Informationen enthalten; Authentifizierung wird akzeptiert, falls gultige Informationen in einer der Dateien gefunden werden konnen. Beachten Sie, dass die Zeilen in diesen Dateien normalerweise Hunderte von Zeichen lang sind und sie garantiert nicht die Rechnerschlussel handisch 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 hinzufugen. ssh-keygen(1) bietet auch grundlegende automatische Bearbeitung von ~/.ssh/known_hosts an, einschliesslich dem Entfernen von Rechnern, die auf einen Rechnernamen passen und die Umwandlung aller Rechnernamen in ihre gehashte Darstellung. Beispiel fur 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 Schlussel @revoked * ssh-rsa AAAAB5W # Ein CA-Schlussel, akzeptiert fur jeden Rechner in *.mydomain.com oder *.mydomain.org @cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W DATEIEN ~/.hushlogin Diese Datei wird zum Unterdrucken der Ausgabe der letzten Anmeldezeit und von /etc/motd, falls PrintLastLog bzw. PrintMotd aktiviert wurden, verwandt. Es unterdruckt nicht die Ausgabe des durch Banner festgelegten Spruchtextes. ~/.rhosts Diese Datei wird fur Rechner-basierte Authentifizierung verwandt (siehe ssh(1) fur weitere Informationen). Auf einigen Maschinen muss diese Datei fur alle lesbar sein, falls sich das Home- Verzeichnis des Benutzers auf einer NFS-Partition befindet, da sshd es als Root liest. Zusatzlich muss diese Datei dem Benutzer gehoren und darf fur keinen anderen eine Schreibberechtigung enthalten. Die empfohlenen Berechtigungen fur die meisten Maschinen ist lesen/schreiben fur den Benutzer und keinen Zugriff fur 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 ermoglichen. ~/.ssh/ Das Verzeichnis ist der Standardort fur alle benutzerspezifischen Konfigurations- und Authentifizierungsinformationen. Es gibt keine allgemeine Anforderung, samtliche Informationen in diesem Verzeichnis geheim zu halten, aber die empfohlenen Berechtigungen sind Lesen/Schreiben/Ausfuhren fur den Benutzer und kein Zugriff fur andere. ~/.ssh/authorized_keys Listet die offentlichen Schlussel (DSA, ECDSA, Ed25519, RSA) auf, die fur die Anmeldung dieses Benutzers verwandt werden konnen. Das Format dieser Datei ist oben beschrieben. Der Inhalt der Datei ist nicht gross sensitiv, aber die empfohlenen Berechtigungen sind lesen/schreiben fur den Benutzer und kein Zugriff fur alle anderen. Falls diese Datei, das Verzeichnis ~/.ssh oder das Home- Verzeichnis des Benutzer fur andere Benutzer schreibbar sind, dann konnte diese Datei durch nicht berechtigte Benutzer verandert oder ausgetauscht werden. In diesem Fall wird sshd die Verwendung nicht erlauben, ausser die Option StrictModes 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 fur den Benutzer schreibbar sein; kein anderer Benutzer muss sie lesen konnen. Standardmassig ist die Verarbeitung der Umgebung deaktiviert und dies wird uber die Option PermitUserEnvironment gesteuert. ~/.ssh/known_hosts Enthalt eine Liste von Rechnerschlusseln fur alle Rechner, bei denen sich der Benutzer angemeldet hat und die nicht bereits in der systemweiten Liste der bekannten Rechner enthalten sind. Das Format dieser Datei ist oben beschrieben. Diese Datei sollte nur fur den Benutzer/root les-/schreibbar sein und muss nicht fur alle lesbar sein. ~/.ssh/rc Enthalt Initialisierungsroutinen, die ausgefuhrt werden sollen, bevor das Home-Verzeichnis des Benutzers zugreifbar wird. In diese Datei sollte nur der Benutzer schreiben konnen und sie muss nicht fur andere lesbar sein. /etc/hosts.equiv Diese Datei ist fur Rechner-basierte Authentifizierung (siehe ssh(1)). Sie sollte nur fur Root beschreibbar sein. /etc/ssh/moduli Enthalt Diffie-Hellman-Gruppen, die fur die >>Diffie-Hellman Group Exchange<<-Schlusselaustauschmethode 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 ausser Root ablehnen. Der Inhalt der Datei wird allen angezeigt, die eine Anmeldung versuchen und alle Anmeldungen ausser Root werden abgelehnt. Die Datei sollte fur 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 ermoglichen. /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 Rechnerschlussel. Diese Dateien sollten nur Root gehoren, 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 offentlichen Anteile der Rechnerschlussel. Diese Dateien sollten von jedem gelesen werden konnen, aber nur fur Root schreibbar sein. Ihre Inhalte sollten auf die entsprechenden privaten Teile passen. Diese Dateien werden nicht wirklich fur 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 Schlussel der bekannten Rechner. Diese Datei sollte durch den Systemadministrator zusammengestellt werden, um die Rechner-Schlussel aller Maschinen in der Organisation zu enthalten. Das Format der Datei wird oben beschrieben. Diese Datei sollte nur von Root/dem Eigentumer beschreibbar sein und von jedem gelesen werden konnen. /etc/ssh/sshd_config Enthalt Konfigurationsdaten fur sshd. Das Dateiformat und die Konfigurationsoptionen sind in sshd_config(5) beschrieben. /etc/ssh/sshrc Ahnlich 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. /var/empty Das von sshd wahrend der Privilegientrennung in der Vor- Authentifizierungsphase verwandte chroot(2) -Verzeichnis. Das Verzeichnis sollte keine Dateien enthalten und muss Root gehoren und nicht fur Gruppen oder alle anderen beschreibbar sein. /run/sshd.pid Enthalt die Prozesskennung des sshd, das auf Verbindungen wartet (falls es mehrere Daemons gibt, die gleichzeitig auf verschiedenen Ports laufen, enthalt dies die Prozesskennung des zuletzt gestarteten). Der Inhalt dieser Datei ist nicht sensitiv; sie kann fur 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), login.conf(5), moduli(5), sshd_config(5), inetd(8), sftp-server(8) AUTOREN OpenSSH ist eine Ableitung der ursprunglichen und freien SSH-1.2.12-Veroffentlichung durch Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt und Dug Song entfernten viele Fehler, fugten neue Funktionalitaten wieder hinzu und erstellten OpenSSH. Markus Friedl steuerte die Unterstutzung fur SSH-Protokollversion 1.5 und 2.0 bei. Niels Provos und Markus Friedl steuerten die Unterstutzung fur die Privilegientrennung bei. UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3: https://www.gnu.org/licenses/gpl-3.0.html oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer: debian-l10n-german@lists.debian.org Linux 6.8.2-arch2-1 $Mdocdate: 19. September 2023 $ Linux 6.8.2-arch2-1