Ubuntu Manpage: sshd — OpenSSH-Daemon

BEZEICHNUNG

     sshd — OpenSSH-Daemon

ÜBERSICHT

     sshd [-46DdeiqTt] [-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 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 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 Konfigurationsdirektive
HostKey festgelegt wird.

-D Wenn diese Option angegeben ist, wird sich sshd nicht abtrennen und kein Daemon
werden. Dies erlaubt das einfache Überwachen von sshd.

-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 Option ListenAddress 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 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.

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:

1. 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).

2. Falls die Anmeldung auf einem TTY erfolgt, wird die Anmeldezeit aufgezeichnet.

3. /etc/nologin wird überprüft; falls es existiert, wird der Inhalt ausgegeben und
die Verbindung beendet (außer bei root).

4. Die Ausführung 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 Ändern 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 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.

9. 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.

cert-authority
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 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"
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 oder eine Zeit YYYYMMDDHHMM[SS] in der Systemzeitzone festgelegt
werden.

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
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"
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 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-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
Option cert-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 und ed25519-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 und ed25519-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
        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…

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 durch Banner 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 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 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.

~/.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: https://www.gnu.org/licenses/gpl-3.0.html 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 .