Ubuntu Manpage: sshd — OpenSSH-Daemon

BEZEICHNUNG

       sshd — OpenSSH-Daemon

ÜBERSICHT

       sshd   [-46DdeGiqTtV]   [-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. Zusätzlich kann der Schalter »invalid-
user« angegeben werden (der kein Wert-Argument akzeptiert), um eine Verbindung von einem nicht
erkannten Benutzernamen zu simuliert.

-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 Konfigurationsdatei auswerten und ausgeben. 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.

-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. Dies ist ähnlich zum Schalter -G, schließt aber die durch den Schalter -t durchgeführten
zusätzlichen Tests ein.

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

-V Zeigt die Version an und beendet das Programm.

AUTHENTIFIZIERUNG

Der OpenSSH-SSH-Daemon unterstützt nur SSH-Protokoll 2. Jeder Rechner verfügt über einen Rechner-
spezifischen Schlüssel, der diesen Rechner identifiziert. Jedes Mal, wenn sich ein Client verbindet,
antwortet der Daemon mit seinem öffentlichen Rechnerschlüssel. Der Client vergleicht den Rechnerschlüssel
mit seiner eigenen Datenbank, um sicherzustellen, dass er sich nicht geändert hat. Durch eine Diffie-
Hellman-Schlüsselvereinbarung wird Vorwärtssicherheit bereitgestellt. Diese Schlüsselvereinbarung führt
zu einem gemeinsam benutzten Sitzungsschlüssel. Der Rest der Sitzung wird mit einer symmetrischen Chiffre
verschlüsselt. Der Client wählt aus den vom Server angebotenen Chiffren den Verschlüsselungsalgorithmus
aus. Zusätzlich wird die Sitzungsintegrität mittels eines kryptographischen
Nachrichtenauthentifizierungscodes (MAC) bereitgestellt.

Schließlich treten der Server und der Client in einen Authentifizierungsdialog. Der Client versucht sich
selbst mittels Rechner-basierter, asymmetrischer, challenge-response oder Passwort-basierter
Authentifizierung zu authentifizieren.

Unabhängig vom Authentifizierungstyp wird das Konto geprüft, um sicherzustellen, dass es zugreifbar ist.
Ein Konto ist nicht zugreifbar, falls es gesperrt, in DenyUsers oder seine Gruppe in in DenyGroups
aufgeführt ist. Die Definition eines gesperrten Kontos ist systemabhängig. Einige Plattformen haben ihre
eigene Kontendatenbank (z.B. AIX) und andere ändern das Passwd-Feld (›*LK*‹ auf Solaris und UnixWare, ›*‹
auf HP-UX, enthält ›NOLOGIN‹ auf Tru64, ein ›LOCKED‹ am Anfang auf FreeBSD und ein ›!‹ am Anfang bei den
meisten Linuxen). Falls die Notwendigkeit besteht, Passwort-basierende Authentifizierung zu deaktivieren,
aber weiterhin asymmetrische Authentifizierung zu erlauben, dann sollte das Passwd-Feld auf etwas anderes
als diese Werte gesetzt werden (z.B. ›NP‹ oder ›*NP*‹).

Falls sich der Client erfolgreich authentifiziert, wird ein Dialog zur Vorbereitung der Sitzung begonnen.
Zu diesem Zeitpunkt kann der Client Dinge wie die Zuweisung eines Pseudo-TTY, die Weiterleitung von
X11-Verbindungen, die Weiterleitung von TCP-Verbindungen oder die Weiterleitung der Verbindung des
Authentifizierungsvermittlers über den sicheren Kanal erbitten.

Danach erbittet 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-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_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[Z] oder eine Zeit YYYYMMDDHHMM[SS][Z] festgelegt werden. Daten und Zeiten werden in der
Zeitzone des Systems interpretiert, außer es wird ein »Z«-Zeichen angehängt, dann werden sie in
der UTC-Zeitzone interpretiert.

from="Musterliste"
Legt fest, dass zusätzlich zur asymmetrischen Authentifizierung entweder der kanonische Name des
fernen Rechners oder seine IP-Adresse in der Kommata-getrennten Liste der Muster vorhanden sein
muss. Siehe MUSTER in ssh_config(5) für weitere Informationen über Muster.

Zusätzlich zum Platzhaltervergleich, der für Rechnernamen oder Adressen angewandt werden kann,
kann ein from -Abschnitt auf IP-Adressen mit der CIDR address/masklen-Notation passen.

Der Zweck dieser Option besteht darin, optional die Sicherheit zu erhöhen: asymmetrische
Authentifizierung an sich vertraut dem Netzwerk oder den Name-Servern oder irgendetwas (außer dem
Schlüssel) nicht. Falls allerdings jemand den Schlüssel klaut, ermöglicht er es dem Eindringling,
sich von überall aus der Welt anzumelden. Diese zusätzliche Option erschwert den Einsatz eines
gestohlenen Schlüssels (es müssten Name-Server und/oder Router zusätzlich kompromittiert werden,
nicht nur der Schlüssel).

no-agent-forwarding
Verbietet die Vermittlerweiterleitung der Authentifizierung, wenn dieser Schlüssel für die
Authentifizierung verwandt wird.

no-port-forwarding
Verbietet die TCP-Weiterleitung, wenn dieser Schlüssel für die Authentifizierung verwandt wird.
Jede Port-Weiterleitungsanfrage durch den Client wird einen Fehler zurückliefern. Dies kann
beispielsweise bei Verbindungen mit der Option command verwandt werden.

no-pty Verhindert TTY-Zuweisung (eine Anfrage, ein PTY zuzuweisen, wird fehlschlagen).

no-user-rc
Deaktiviert die Ausführung von ~/.ssh/rc.

no-X11-forwarding
Verbietet X11-Weiterleitung, wenn dieser Schlüssel zur Authentifizierung verwandt wird. Jede
X11-Weiterleitungsanfrage vom Client wird einen Fehler zurückliefern.

permitlisten="[Rechner:]Port"
Schränkt ferne Port-Weiterleitung mit der Option -R von ssh(1) ein, so dass es nur auf dem
festgelegten Rechner (optional) und Port auf Anfragen wartet. IPv6-Adressen können durch
Einschluss der Adresse in eckige Klammern festgelegt werden. Mehrere 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
          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 (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 .

Debian                                         15. September, 2024                                       SSHD(8)