Ubuntu Manpage: sshd_config — OpenSSH-Daemon-Konfigurationsdatei

BEZEICHNUNG

       sshd_config — OpenSSH-Daemon-Konfigurationsdatei

BESCHREIBUNG

sshd(8) liest Konfigurationsdaten aus /etc/ssh/sshd_config (oder der mit -f auf der Befehlszeile
angegebenen Datei). Die Datei enthält Schlüsselwort-Argumente-Paare, eines pro Zeile. Falls nicht anders
angemerkt wird für jedes Schlüsselwort das erste erlangte verwandt. Zeilen, die mit ‘#’ beginnen und
leere Zeilen werden als Kommentare interpretiert. Argumente können optional in doppelte Anführungszeichen
(") eingeschlossen werden, um Argumente darzustellen, die Leerzeichen enthalten.

Beachten Sie, dass das Debian-Paket openssh-server eine Reihe von Optionen als Vorgabe in
/etc/ssh/sshd_config setzt, die in sshd(8) nicht die Vorgabe sind:

• Include /etc/ssh/sshd_config.d/*.conf
• KbdInteractiveAuthentication no
• X11Forwarding yes
• PrintMotd no
• AcceptEnv LANG LC_*
• Subsystem sftp /usr/lib/openssh/sftp-server
• UsePAM yes

Die Dateien /etc/ssh/sshd_config.d/*.conf werden am Anfang der Konfigurationsdatei eingebunden, daher
werden die dort gesetzten Optionen die in /etc/ssh/sshd_config außer Kraft setzen.

Die möglichen Schlüsselwörter und ihre Bedeutung sind wie folgt (beachten Sie, dass die
Groß-/Kleinschreibung bei Schlüsselwörtern egal, bei Argumenten dagegen relevant ist):

AcceptEnv
Legt fest, welche vom Client gesandten Umgebungsvariablen in die environ(7) der Sitzung kopiert
werden. Siehe SendEnv und SetEnv in ssh_config(5) für die Konfiguration des Clients. Die
Umgebungsvariable TERM wird immer akzeptiert, wenn der Client ein Pseudo-Terminal anfordert, da
sie vom Protokoll gefordert wird. Variablen werden durch den Namen, der Platzhalterzeichen ‘*’
und ‘?’ enthalten darf, festgelegt. Mehrere Umgebungsvariablen können durch Leerraum getrennt
oder auf mehrere AcceptEnv -Direktiven verteilt werden. Warnung: Einige Umgebungsvariablen können
zur Umgehung eingeschränkter Benutzerumgebungen verwandt werden. Daher sollten Sie beim Einsatz
dieser Direktive vorsichtig sein. Standardmäßig werden keine Umgebungsvariablen akzeptiert.

AddressFamily
Legt die von sshd(8) zu verwendende Adressfamilie fest. Gültige Argumente sind any (die Vorgabe),
inet (nur IPv4 verwenden) und inet6 (nur IPv6 verwenden).

AllowAgentForwarding
Legt fest, ob Weiterleitung mit ssh-agent(1) erlaubt ist. Die Vorgabe ist yes. Beachten Sie, dass
die Deaktivierung von Vermittlerweiterleitung die Sicherheit nicht verbessert, außer der Shell-
Zugriff wird auch verboten, da die Benutzer stets ihre eigenen Weiterleitungsprogramme
installieren können.

AllowGroups
Diesem Schlüsselwort kann eine Liste von Gruppennamenmustern, getrennt durch Leerzeichen, folgen.
Falls festgelegt, ist die Anmeldung nur für Benutzer erlaubt, deren primäre oder ergänzende
Gruppe auf eines der Muster passt. Nur Gruppennamen sind gültig; eine numerische Gruppenkennung
wird nicht erkannt. Standardmäßig ist die Anmeldung für alle Gruppen erlaubt. Die
Gruppendirektiven »allow/deny« werden in folgender Reihenfolge verarbeitet: DenyGroups,
AllowGroups.

Siehe MUSTER in ssh_config(5) für weitere Informationen über Muster. Dieses Schlüsselwort darf in
mehrfach auftauchen, wobei jede Instanz an die Liste anhängt wird.

AllowStreamLocalForwarding
Legt fest, ob StreamLocal-Weiterleitung (Unix-Domain-Socket) erlaubt ist. Die verfügbaren
Optionen sind yes (die Vorgabe), all (um StreamLocal-Weiterleitung zu erlauben), no (um alle
StreamLocal-Weiterleitungen zu verhindern), local (um nur lokale (aus Sicht von ssh(1))
Weiterleitung zu erlauben) und remote (um nur ferne Weiterleitung zu erlauben). Beachten Sie,
dass die Deaktivierung von StreamLocal-Weiterleitung die Sicherheit nicht verbessert, außer der
Shell-Zugriff wird auch verboten, da die Benutzer stets ihre eigenen Weiterleitungsprogramme
installieren können.

AllowTcpForwarding
Legt fest, ob TCP-Weiterleitung erlaubt ist. Die verfügbaren Optionen sind yes (die Vorgabe), all
(um TCP-Weiterleitung zu erlauben), no (um alle TCP-Weiterleitungen zu verhindern), local (um nur
lokale (aus Sicht von ssh(1)) Weiterleitung zu erlauben) und remote (um nur ferne Weiterleitung
zu erlauben). Beachten Sie, dass die Deaktivierung von TCP-Weiterleitung die Sicherheit nicht
verbessert, außer der Shell-Zugriff wird auch verboten, da die Benutzer stets ihre eigenen
Weiterleitungsprogramme installieren können.

AllowUsers
Diesem Schlüsselwort kann eine Liste von Benutzernamenmustern, getrennt durch Leerzeichen,
folgen. Falls festgelegt, ist die Anmeldung nur für Benutzer erlaubt, deren Namen auf eines der
Muster passen. Nur Benutzernamen sind gültig; eine numerische Benutzerkennung wird nicht erkannt.
Standardmäßig ist die Anmeldung für alle Benutzer erlaubt. Falls das Muster dem Aufbau
BENUTZER@RECHNER folgt, dann werden BENUTZER und RECHNER getrennt überprüft und schränken die
Anmeldungen für bestimmte Benutzer von bestimmten Rechnern ein. RECHNER-Kriterien können
zusätzlich Adressen enthalten, die auf das CIDR-Adressen/Maskenlängen-Format passen. Die
Benutzerdirektiven »allow/deny« werden in folgender Reihenfolge verarbeitet: DenyUsers,
AllowUsers.

Siehe MUSTER in ssh_config(5) für weitere Informationen über Muster. Dieses Schlüsselwort darf in
mehrfach auftauchen, wobei jede Instanz an die Liste anhängt wird.

AuthenticationMethods
Legt die Authentifizierungsmethoden fest, die erfolgreich durchlaufen werden müssen, damit einem
Benutzer Zugriff gewährt wird. Dieser Option muss eine oder mehrere Listen von durch Kommata-
getrennten Authentifizierungsmethodennamen oder die einzelnen Zeichenkette any folgen. any gibt
das Standardverhalten an, dass jede einzelne Authentifizierungsmethode akzeptiert wird. Falls die
Vorgabe außer Kraft gesetzt wird, verlangt die erfolgreiche Authentifizierung den Abschluss jeder
Methode in mindestens einer dieser Listen.

Beispielsweise würde "publickey,password publickey,keyboard-interactive" verlangen, dass der
Benutzer die Authentifizierung mittels asymmetrischem Schlüssel, gefolgt von entweder der
Passwort- oder der interaktiven Tastaturauthentifizierung abschließt. Es werden in jeder Stufe
nur die Methoden angeboten, die in einer der Listen nebeneinander sind, daher wäre es in diesem
Beispiel nicht möglich, die Passwort- oder interaktive Tastaturauthentifizierung vor der
asymmetrischen Schlüsselauthentifizierung zu versuchen.

Für interaktive Tastaturauthentifizierung ist es auch möglich, die Authentifizierung auf ein
bestimmtes Gerät zu beschränken, indem ein Doppelpunkt gefolgt von dem Gerätekennzeichner bsdauth
oder pam, abhängig von der Server-Konfiguration, angegeben wird. Beispielsweise würde
"keyboard-interactive:bsdauth" die interaktive Tastaturauthentifizierung auf das Gerät bsdauth
beschränken.

Falls die Methode »publickey« mehr als einmal aufgeführt ist, dann stellt sshd(8) sicher, dass
erfolgreich verwandte Schlüssel nicht erneut für nachfolgende Authentifizierungen verwandt
werden. Beispielsweise verlangt "publickey,publickey" eine erfolgreiche Authentifizierung mit
zwei verschiedenen öffentlichen Schlüsseln.

Beachten Sie, dass jede aufgeführte Authentifizierungsmethode auch explizit in der Konfiguration
aktiviert werden sollte.

Folgende Authentifizierungsmethoden sind verfügbar: "gssapi-with-mic", "hostbased",
"keyboard-interactive", "none" (wird zum Zugriff auf Konten ohne Passwort verwandt, wenn
PermitEmptyPasswords aktiviert ist), "password" und "publickey".

AuthorizedKeysCommand
Legt ein Programm fest, das zum Nachschlagen des öffentlichen Schlüssels des Benutzers verwandt
wird. Das Programm muss root gehören, darf von der Gruppe und anderen nicht schreibbar sein und
muss durch einen absoluten Pfad festgelegt werden. AuthorizedKeysCommand akzeptiert als Argumente
die im Abschnitt “MERKMALE” beschriebenen Merkmale. Falls keine Argumente festgelegt sind, dann
wird der Benutzername des Zielbenutzers verwandt.

Das Programm sollte auf der Standardausgabe keine oder mehrere Zeilen von autorisierter-
Schlüssel-Ausgabe erzeugen (siehe “AUTORISIERTE SCHLÜSSEL” in sshd(8)). AuthorizedKeysCommand
wird nach den gewöhnlichen Dateien aus AuthorizedKeysFile versucht und wird nicht ausgeführt,
falls dort bereits ein passender Schlüssel gefunden wurde. Standardmäßig wird kein
AuthorizedKeysCommand ausgeführt.

AuthorizedKeysCommandUser
Legt einen Benutzer fest, unter dessen Konto der AuthorizedKeysCommand ausgeführt wird. Es wird
empfohlen, einen dedizierten Benutzer zu verwenden, der keine weitere Aufgabe auf dem System hat,
außer die autorisierte-Schlüssel-Befehle auszuführen. Falls AuthorizedKeysCommand, aber nicht
AuthorizedKeysCommandUser festgelegt ist, wird sshd(8) den Start verweigern.

AuthorizedKeysFile
Legt die Datei fest, die die öffentlichen Schlüssel für die Benutzerauthentifizierung enthält.
Das Format wird im Abschnitt AUTHORIZED_KEYS-DATEIFORMAT von sshd(8) beschrieben.
AuthorizedKeysFile akzeptiert die im Abschnitt “MERKMALE” beschriebenen Merkmale. Nach der
Expandierung wird AuthorizedKeysFile als absoluter Pfad oder als relativ zum Home-Verzeichnis des
Benutzers eingesetzt. Es können mehrere, durch Leerraum getrennte Dateien aufgeführt werden.
Diese Option kann alternativ auch auf none gesetzt werden, um die Überprüfung von
Benutzerschlüsseldateien zu überspringen. Die Vorgabe ist ".ssh/authorized_keys
.ssh/authorized_keys2".

AuthorizedPrincipalsCommand
Legt ein Programm fest, das zur Erzeugung der Liste der erlaubten Zertifikatsprinzipalen gemäß
AuthorizedPrincipalsFile verwandt wird. Das Programm muss root gehören, darf von der Gruppe und
anderen nicht schreibbar sein und muss durch einen absoluten Pfad festgelegt werden.
AuthorizedPrincipalsCommand akzeptiert die im Abschnitt “MERKMALE” beschriebenen Merkmale. Falls
keine Argumente festgelegt sind, wird der Benutzername des Zielbenutzers verwandt.

Das Programm sollte auf der Standardausgabe keine oder mehrere Zeilen von
AuthorizedPrincipalsFile -Ausgabe erzeugen. Falls entweder AuthorizedPrincipalsCommand oder
AuthorizedPrincipalsFile festgelegt ist, dann müssen die vom Client angebotenen Zertifikate für
die Authentifizierung einen der aufgeführten Prinzipalen enthalten. Standardmäßig wird kein
AuthorizedPrincipalsCommand ausgeführt.

AuthorizedPrincipalsCommandUser
Legt einen Benutzer fest, unter dessen Konto der AuthorizedPrincipalsCommand ausgeführt wird. Es
wird empfohlen, einen dedizierten Benutzer zu verwenden, der keine weitere Aufgabe auf dem System
hat, außer die »authorized principals«-Befehle auszuführen. Falls AuthorizedPrincipalsCommand,
aber nicht AuthorizedPrincipalsCommandUser festgelegt ist, wird sshd(8) den Start verweigern.

AuthorizedPrincipalsFile
Legt eine Datei fest, die die Prinzipalnamen aufführt, die für Zertifikatsauthentifizierung
akzeptiert werden. Wird ein Zertifikat verwandt, das von einem in TrustedUserCAKeys aufgeführten
Schlüssel signiert wird, dann führt diese Datei Namen auf, von denen einer im Zertifikat
auftauchen muss, damit es für die Authentifizierung akzeptiert wird. Es wird ein Name pro Zeile
aufgeführt, davor können Schlüsseloptionen (wie in “AUTHORIZED_KEYS-DATEIFORMAT” in sshd(8)
beschrieben) angegeben werden. Leere Zeilen und Kommentare, die mit ‘#’ beginnen, werden
ignoriert.

AuthorizedPrincipalsFile akzeptiert die im Abschnitt “MERKMALE” beschriebenen Merkmale. Nach der
Expandierung wird AuthorizedPrincipalsFile als absoluter Pfad oder als relativ zum Home-
Verzeichnis des Benutzers eingesetzt. Die Vorgabe ist none, d.h. keine Verwendung einer
Prinzipalendatei – in diesem Fall muss der Benutzername des Benutzers in der Prinzipalenliste in
einem Zertifikat auftauchen, damit dieses akzeptiert wird.

Beachten Sie, dass AuthorizedPrincipalsFile nur verwandt wird, wenn die Authentifizierung mittels
einer in TrustedUserCAKeys aufgeführten CA durchgeführt wird und diese Datei wird nicht für
mittels ~/.ssh/authorized_keys vertrauten Zertifizierungsstellen berücksichtigt. Allerdings
stellt die Schlüsseloption principals= eine ähnliche Einrichtung bereit (siehe sshd(8) für
Details).

Banner Der Inhalt der festgelegten Datei wird an den fernen Benutzer gesandt, bevor die
Authentifizierung erlaubt wird. Falls das Argument none lautet, wird kein Spruchtext angezeigt.
Standardmäßig wird kein Spruchtext angezeigt.

CASignatureAlgorithms
Legt die Algorithmen fest, die zum Signieren von Zertifikaten durch Zertifizierungsstellen (CAs)
erlaubt sind. Die Vorgabe ist:

ssh-ed25519,ecdsa-sha2-nistp256,
ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ssh-ed25519@openssh.com,
sk-ecdsa-sha2-nistp256@openssh.com,
rsa-sha2-512,rsa-sha2-256

Falls die festgelegte Liste mit einem »+«-Zeichen beginnt, werden die festgelegten Algorithmen an
die Vorgabemenge angehängt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem
»-«-Zeichen beginnt, dann werden die festgelegten Algorithmen (einschließlich Platzhalter-
Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen.

Zertifikate, die mit anderen Algorithmen signiert wurden, werden für asymmetrische oder Rechner-
basierte Authentifizierung nicht akzeptiert.

ChannelTimeout
Legt fest, ob und wie schnell sshd(8) inaktive Kanäle schließen soll. Zeitüberschreitungen werden
als ein oder mehrere Paare »Typ=Interval«, getrennt durch Leerraum, festgelegt, wobei »Typ« der
Kanaltypname (wie in der nachfolgenden Tabelle beschrieben) sein muss, der optional Metazeichen
enthalten darf.

Der Zeitüberschreitungswert »Intervall« wird in Sekunden festgelegt oder kann eine der im
Abschnitt “ZEITFORMATE” beschriebenen Einheiten verwenden. Beispielsweise würde »session:*=5m«
dazu führen, dass alle Sitzungen nach 5 Minuten Inaktivität beendet würden. Durch Festlegen eines
Null-Wertes wird die Inaktivitätszeitüberschreitung deaktiviert.

Die verfügbaren Kanaltypen sind:

agent-connection
Offene Verbindungen zu ssh-agent(1).

direct-tcpip, direct-streamlocal@openssh.com
Offene TCP- bzw. Unix-Socket-Verbindungen, die von einer lokalen ssh(1) -Weiterleitung
etabliert wurden, d.h. LocalForward oder DynamicForward.

forwarded-tcpip, forwarded-streamlocal@openssh.com
Offene TCP- bzw. Unix-Socket-Verbindungen, die zu einem sshd(8) etabliert wurden, der im
Auftrag einer fernen ssh(1) -Weiterleitung, d.h. RemoteForward, auf Anfragen wartet.

session:command
Befehlsausführungssitzungen.

session:shell
Interaktive Shell-Sitzungen

session:subsystem:…
Subsystemsitzungen, z.B. für sftp(1), die als session:subsystem:sftp identifiziert werden
könnten.

x11-connection
Offene X11-Weiterleitungssitzungen.

Beachten Sie, dass in allen obigen Fällen die Beendigung einer aktiven Sitzung nicht garantiert,
dass alle der Sitzung zugeordneten Ressourcen entfernt werden, z.B. könnten Shell-Prozesse oder
X11-Clients, die Bezug zur Sitzung haben, weiterhin ausgeführt werden.

Desweiteren schließt das Beenden eines inaktiven Kanals oder Sitzung nicht notwendigerweise die
SSH-Verbindung, noch verhindert sie einen Client, einen anderen Kanal des gleichen Typs zu
erbitten. Insbesondere verhindert das Ablaufen einer inaktiven Weiterleitungssitzung nicht, dass
andere, identische Weiterleitungen nachfolgend erstellt werden. Siehe auch
UnusedConnectionTimeout, das zusammen mit dieser Option verwandt werden kann.

Standardmäßig verfällt kein Kanal irgendeiner Art aufgrund von Inaktivität.

ChrootDirectory
Legt den Pfadnamen fest, in dem nach der Authentifizierung ein chroot(2) erfolgen soll. Beim
Starten der Sitzung prüft sshd(8), dass alle Komponenten des Pfades Verzeichnisse sind, die root
gehören und von keinem anderen Benutzer oder keiner anderen Gruppe beschreibbar sind. Nach dem
Chroot wechselt sshd(8) das Arbeitsverzeichnis auf das Home-Verzeichnis des Benutzers. Argumente
von ChrootDirectory akzeptieren die im Abschnitt “MERKMALE” beschriebenen Merkmale.

Das ChrootDirectory muss die notwendigen Dateien und Verzeichnisse zur Unterstützung der Sitzung
des Benutzers enthalten. Für eine interaktive Sitzung benötigt dies mindestens eine Shell,
typischerweise sh(1) und grundlegende /dev -Knoten wie null(4), zero(4), stdin(4), stdout(4),
stderr(4) und tty(4) -Geräte. Für Dateiübertragungssitzungen mittels SFTP ist für die Umgebung
keine zusätzliche Konfiguration notwendig, falls der In-Prozess-SFTP-Server verwandt wird,
allerdings könnten Sitzungen, die Protokollierung verwenden, /dev/log auf einigen
Betriebssystemen innerhalb des Chroot-Verzeichnisses benötigen (siehe sftp-server(8) für
Details).

Zur Sicherheit ist es sehr wichtig, dass die Veränderungen an der Verzeichnishierarchie durch
andere Prozesse auf dem System (insbesondere außerhalb des Jails) verhindert werden. Fehlerhafte
Konfiguration kann zu unsicheren Umgebungen führen, die sshd(8) nicht erkennen kann.

Die Vorgabe ist none, was anzeigt, kein chroot(2) durchzuführen.

Ciphers
Legt die erlaubten Chiffren fest. Mehrere Chiffren müssen durch Kommata getrennt werden. Falls
die festgelegte Liste mit einem »+«-Zeichen beginnt, werden die festgelegten Chiffren an die
Vorgabemenge angehängt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem »-«-Zeichen
beginnt, dann werden die festgelegten Chiffren (einschließlich Platzhalter-Zeichen) aus der
Vorgabemenge entfernt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem »^«-Zeichen
beginnt, dann werden die festgelegten Chiffren an den Anfang der Vorgabemenge gestellt.

Die unterstützten Chiffren sind:

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

Die Vorgabe ist:

chacha20-poly1305@openssh.com,
aes128-ctr,aes192-ctr,aes256-ctr,
aes128-gcm@openssh.com,aes256-gcm@openssh.com

Die Liste der verfügbaren Chiffen kann auch mit "ssh -Q cipher" erhalten werden.

ClientAliveCountMax
Setzt die Anzahl der Client-Lebensmeldungen, die gesandt werden können, ohne dass sshd(8) eine
Nachricht vom Client zurückerhält. Falls dieser Schwellwert erreicht wird, während Client-
Lebensmeldungen gesandt werden, wird Sshd die Verbindung zum Client trennen und die Sitzung
beenden. Es ist sehr wichtig anzumerken, dass die Verwendung von Client-Lebensmeldungen sich
stark von TCPKeepAlive unterscheidet. Die Lebensmeldungen des Clients werden durch den
verschlüsselten Kanal gesandt und können daher nicht manipuliert werden. Die durch TCPKeepAlive
aktivierte Option »TCP keepalive« kann manipuliert werden. Der Client-Lebensmeldungsmechanismus
ist wertvoll, wenn der Client oder der Server davon abhängen zu wissen, wenn auf einer Verbindung
nicht mehr reagiert wird.

Der Vorgabewert ist 3. Falls ClientAliveInterval auf 15 gesetzt wird und ClientAliveCountMax bei
der Vorgabe verbleibt, wird die Verbindung zu SSH-Clients, die nicht mehr reagieren, nach
ungefähr 45 Sekunden getrennt. Die Beendigung der Verbindung wird deaktiviert, indem
ClientAliveCountMax auf 0 gesetzt wird.

ClientAliveInterval
Setzt ein Zeitüberschreitungsintervall, nachdem sshd(8) eine Nachricht durch den verschlüsselten
Kanal senden wird, um eine Antwort vom Client zu erbitten, falls keine Daten vom Client empfangen
wurden. Die Vorgabe ist 0, womit angezeigt wird, dass diese Nachrichten nicht an den Client
gesandt werden sollen.

Compression
Legt fest, ob Komprimierung aktiviert wird, nachdem der Benutzer sich authentifiziert hat. Das
Argument muss yes, delayed (ein veraltetes Synonym für yes) oder no sein. Die Vorgabe ist yes.

DebianBanner
Legt fest, ob die distributionsspezifische zusätzliche Versionsendung während des anfänglichen
Protokoll-Handshakes eingebunden wird. Die Vorgabe ist yes.

DenyGroups
Diesem Schlüsselwort kann eine Liste von Gruppennamenmustern folgen, die durch Leerzeichen
getrennt sind. Die Anmeldung ist für die Benutzer deaktiviert, deren primäre oder ergänzende
Gruppenliste auf eine der Muster passt. Nur Gruppennamen sind gültig; eine numerische
Gruppenkennung wird nicht erkannt. Standardmäßig ist die Anmeldung für alle Gruppen erlaubt. Die
Gruppendirektive »allow/deny« wird in der folgenden Reihenfolge verarbeitet: DenyGroups,
AllowGroups.

Siehe MUSTER in ssh_config(5) für weitere Informationen über Muster. Dieses Schlüsselwort darf in
mehrfach auftauchen, wobei jede Instanz an die Liste anhängt wird.

DenyUsers
Diesem Schlüsselwort kann eine Liste von Benutzernamenmustern folgen, die durch Leerzeichen
getrennt sind. Die Anmeldung ist für die Benutzer deaktiviert, deren Namen auf eines der Muster
passen. Nur Benutzernamen sind gültig; eine numerische Benutzerkennung wird nicht erkannt.
Standardmäßig ist die Anmeldung für alle Benutzer erlaubt. Falls das Muster der Form
BENUTZER@RECHNER folgt, dann werden BENUTZER und RECHNER getrennt überprüft und Anmeldungen auf
bestimmte Benutzer von bestimmten Rechnern beschränkt. RECHNER-Kriterien können zusätzlich
Adressen enthalten, die auf das CIDR-Adresse/Maskenlängenformat passen. Die Benutzerdirektive
»allow/deny« wird in der folgenden Reihenfolge verarbeitet: DenyUsers, AllowUsers.

Siehe MUSTER in ssh_config(5) für weitere Informationen über Muster. Dieses Schlüsselwort darf in
mehrfach auftauchen, wobei jede Instanz an die Liste anhängt wird.

DisableForwarding
Deaktiviert alle Weiterleitungsfunktionalitäten, einschließlich X11, ssh-agent(1), TCP und
StreamLocal. Diese Option setzt alle anderen Optionen mit Weiterleitungsbezug außer Kraft und
kann eingeschränkte Konfigurationen vereinfachen.

ExposeAuthInfo
Schreibt eine temporäre Datei, die eine Liste der authentifizierten Methoden und öffentlicher
Zugangsberechtigungen (z.B. Schlüssel), die zur Authentifizierung des Benutzers verwandt wurden,
enthält. Der Ort der Datei wird dem Benutzer mittels der Umgebungsvariablen SSH_USER_AUTH
offengelegt. Die Vorgabe ist no.

FingerprintHash
Legt den zum Protokollieren von Schlüsselfingerabdrücken verwandten Hash-Algorithmus fest.
Gültige Optionen sind md5 und sha256. Die Vorgabe ist sha256.

ForceCommand
Erzwingt die Ausführung des mittels ForceCommand festgelegten Befehls, vom Client und in
~/.ssh/rc bereitgestellte Befehle werden (falls vorhanden) ignoriert. Der Befehl wird mittels der
Anmelde-Shell des Benutzers mit der Option »-c« ausgeführt. Dies gilt für die Shell-, Befehls-
oder Subsystem-Ausführung. Dies ist innerhalb eines Match -Blocks am nützlichsten. Der vom Client
ursprünglich bereitgestellte Befehl ist in der Umgebungsvariablen SSH_ORIGINAL_COMMAND verfügbar.
Wird internal-sftp als Befehl festgelegt, dann wird die Benutzung des In-Prozess-SFTP-Servers
erzwungen, der keinerlei unterstützende Dateien benötigt, wenn er mit ChrootDirectory verwandt
wird. Die Vorgabe ist none.

GatewayPorts
Legt fest, ob fernen Rechnern die Verbindung zu Ports erlaubt wird, die für den Client
weitergeleitet sind. Standardmäßig bindet sshd(8) ferne Port-Weiterleitungen an die Loopback-
Adresse. Dies verhindert, dass andere ferne Rechner sich an den weitergeleiteten Port verbinden.
GatewayPorts kann zur Festlegung verwandt werden, dass Sshd die Anbindung der fernen
Portweiterleitung an nicht-Looback-Adressen erlauben soll und damit anderen Rechnern, sich damit
zu verbinden. Das Argument kann no sein, damit ferne Port-Weiterleitungen nur dem lokalen Rechner
zur Verfügung stehen, yes, damit ferne Port-Weiterleitungen an Platzhalter-Adressen erzwungen
werden oder clientspecified, um dem Client zu erlauben, die Adresse auszuwählen, an die die
Weiterleitung gebunden wird. Die Vorgabe ist no.

GSSAPIAuthentication
Legt fest, ob die GSSAPI-basierte Benutzerauthentifizierung erlaubt ist. Die Vorgabe ist no.

GSSAPICleanupCredentials
Legt fest, ob der Zwischenspeicher mit den Anmeldedaten des Benutzers beim Abmelden automatisch
zerstört werden soll. Die Vorgabe ist yes.

GSSAPIKeyExchange
Legt fest, ob auf GSSAPI basierender Schlüsselaustausch erlaubt ist. GSSAPI-Schlüsselaustausch
verlässt sich nicht auf SSH-Schlüssel, um die Identität von Rechnern zu prüfen. Die Vorgabe ist
no.

GSSAPIStrictAcceptorCheck
Bestimmt, ob die Identität des GSSAPI-Akzeptanten bei der Client-Authentifizierung strikt
erzwungen werden soll. Falls auf yes gesetzt, muss sich der Client gegen den Rechnerdienst auf
dem aktuellen Rechnernamen authentifizieren. Falls auf no gesetzt, kann sich der Client gegen
jeden Diensteschlüssel, der in dem Standardspeicher der Maschine abgelegt ist, authentifizieren.
Diese Einrichtung wird bereitgestellt, um bei Aktionen auf Maschinen mit mehreren Standorten zu
unterstützen. Die Vorgabe ist yes.

GSSAPIStoreCredentialsOnRekey
Steuert, ob die GSSAPI-Anmeldedaten des Benutzers nach einer erfolgreichen
Schlüsselneuaushandlung nach einer Verbindungsaufnahme aktualisiert werden sollen. Diese Option
kann dazu verwandt werden, erneuerte oder aktualisierte Anmeldedaten von einem kompatiblen Client
zu akzeptieren. Die Vorgabe ist “no”.

Damit dies funktioniert, muss GSSAPIKeyExchange auf dem Server aktiviert und auch vom Client
verwandt werden.

GSSAPIKexAlgorithms
Die Liste der durch den GSSAPI-Schlüsselaustausch akzeptierten Schlüsselaustausch-Algorithmen.
Mögliche Werte sind:

gss-gex-sha1-,
gss-group1-sha1-,
gss-group14-sha1-,
gss-group14-sha256-,
gss-group16-sha512-,
gss-nistp256-sha256-,

gss-curve25519-sha256-
Die Vorgabe ist
“gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-,gss-gex-sha1-,gss-group14-sha1-”.
Diese Option gilt nur bei Verbindungen, die GSSAPI verwenden.

HostbasedAcceptedAlgorithms
Legt die Signaturalgorithmen in Form einer Kommata-getrennten Liste von Mustern fest, die bei
rechnerbasierter Authentifizierung akzeptiert werden. Falls alternativ die festgelegte Liste mit
einem »+«-Zeichen beginnt, werden die festgelegten Signaturalgorithmen an die Vorgabemenge
angehängt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem »-«-Zeichen beginnt, dann
werden die festgelegten Signaturalgorithmen (einschließlich Platzhalter-Zeichen) aus der
Vorgabemenge entfernt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem »^«-Zeichen
beginnt, dann werden die festgelegten Signaturalgorithmen an den Anfang der Vorgabemenge
gestellt. Die Vorgabe für diese Option lautet:

ssh-ed25519-cert-v01@openssh.com,
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-ed25519,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ssh-ed25519@openssh.com,
sk-ecdsa-sha2-nistp256@openssh.com,
rsa-sha2-512,rsa-sha2-256

Die Liste der verfügbaren Signaturalgorithmen kann auch mittels "ssh -Q
HostbasedAcceptedAlgorithms" erhalten werden. Früher hieß dies HostbasedAcceptedKeyTypes.

HostbasedAuthentication
Legt fest, ob Rhosts- oder /etc/hosts.equiv-Authentifizierung zusammen mit erfolgreicher
asymmetrischer Client-Rechner-Authentifizierung erlaubt ist (Rechner-basierte Authentifizierung).
Die Vorgabe ist no.

HostbasedUsesNameFromPacketOnly
Legt fest, ob der Server versuchen wird, eine inverse Namensauflösung beim Vergleich des Namens
in den Dateien ~/.shosts, ~/.rhosts und /etc/hosts.equiv während der HostbasedAuthentication
durchzuführen. Eine Einstellung von yes bedeutet, dass sshd(8) den vom Client bereitgestellten
Namen verwenden wird, statt zu versuchen, den Namen aus der TCP-Verbindung selbst aufzulösen. Die
Vorgabe ist no.

HostCertificate
Legt eine Datei fest, die ein öffentliches Rechnerzertifikat enthält. Der öffentliche Schlüssel
muss auf den bereits mit HostKey festgelegten privaten Schlüssel passen. Standardmäßig lädt
sshd(8) keine Zertifikate.

HostKey
Legt eine Datei fest, die den von SSH verwandten privaten Rechnerschlüssel enthält. Die Vorgaben
sind /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key und /etc/ssh/ssh_host_rsa_key.

Beachten Sie, dass sshd(8) die Verwendung einer Datei ablehnen wird, falls sie Gruppe-/Welt-
zugreifbar ist und dass die Option HostKeyAlgorithms einschränkt, welcher der Schlüssel durch
sshd(8) tatsächlich verwandt wird.

Es ist möglich, mehrere Rechnerschlüsseldateien zu haben. Es ist auch möglich, stattdessen
öffentliche Rechnerschlüsseldateien festzulegen. In diesem Fall werden Aktionen an dem privaten
Schlüssel an ssh-agent(1) delegiert.

HostKeyAgent
Identifiziert das für die Kommunikation mit dem Vermittler, der Zugriff auf die privaten
Rechnerschlüssel hat, verwandte UNIX-Domain-Socket. Falls die Zeichenkette "SSH_AUTH_SOCK"
festgelegt ist, wird der Ort des Sockets aus der Umgebungsvariablen SSH_AUTH_SOCK ausgelesen.

HostKeyAlgorithms
Legt den vom Rechner angebotenen Rechnerschlüssel-Signaturalgorithmus fest. Die Vorgabe für diese
Option ist:

Die Liste der verfügbaren Signaturalgorithmen kann auch mittels "ssh -Q HostKeyAlgorithms"
erhalten werden.

IgnoreRhosts
Legt fest, ob benutzerbezogene Dateien .rhosts und .shosts während HostbasedAuthentication
ignoriert werden sollen. Unabhängig von dieser Einstellung werden die systemweiten
/etc/hosts.equiv und /etc/ssh/shosts.equiv weiterhin genutzt.

Akzeptierte Werte sind yes (die Vorgabe), um alle benutzerbezogenen Dateien zu ignorieren,
shosts-only, um nur die Verwendung von .shosts zu erlauben, aber .rhosts zu ignorieren und no, um
sowohl .shosts als auch rhosts zu erlauben.

IgnoreUserKnownHosts
Legt fest, ob sshd(8) die ~/.ssh/known_hosts während HostbasedAuthentication ignorieren und nur
die systemweite Datei bekannter Rechner /etc/ssh/ssh_known_hosts verwenden soll. Die Vorgabe ist
“no”.

Include
Bindet die festgelegte Konfigurationsdatei ein. Es können mehrere Pfadnamen festgelegt werden und
jeder Pfadname darf glob(7) -Platzhalter enthalten, die expandiert und in lexikalischer
Reihenfolge verarbeitet werden. Von Dateien ohne absolute Pfade wird vermutet, dass sie in
/etc/ssh liegen. Innerhalb eines Match -Blocks kann eine Include -Direktive auftauchen, um
bedingte Einbindung durchzuführen.

IPQoS Legt die IPv4-Diensteart oder DSCP-Klasse für die Verbindung fest. Akzeptierte Werte sind af11,
af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5,
cs6, cs7, ef, le, lowdelay, throughput, reliability, ein numerischer Wert und none, um die
Vorgabe des Betriebssystems zu verwenden. Diese Option kann ein oder zwei Argumente, getrennt
durch Leerraum, akzeptieren. Falls ein Argument festgelegt ist, wird es bedingungslos als
Paketklasse verwandt. Falls zwei Werte festgelegt sind, wird der erste automatisch für
interaktive Sitzungen ausgewählt und der zweite für nicht-interaktive Sitzungen. Die Vorgabe ist
lowdelay für interaktive Sitzungen und throughput für nicht-interaktive Sitzungen.

KbdInteractiveAuthentication
Legt fest, ob interaktive Anmeldung über die Tastatur erlaubt wird. Die Vorgabe ist yes. Das
Argument für dieses Schlüsselwort muss yes oder no lauten. ChallengeResponseAuthentication ist
ein veralteter Alias dafür.

KerberosAuthentication
Legt fest, ob das durch den Benutzer für PasswordAuthentication bereitgestellte Passwort mittels
des Kerberos KDCs validiert wird. Um diese Option zu verwenden, benötigt der Server eine
Kerberos-Servtab, die die Überprüfung der Identität des KDCs erlaubt. Die Vorgabe ist no.

KerberosGetAFSToken
Falls AFS aktiv ist und der Benutzer ein Kerberos-5-TGT hat, wird versucht, ein AFS-Token zu
erlangen, bevor auf das Home-Verzeichnis des Benutzers zugegriffen wird. Die Vorgabe ist no.

KerberosOrLocalPasswd
Falls Passwort-Authentifizierung mittels Kerberos fehlschlägt, dann wird das Passwort mittels
eines zusätzlichen lokalen Mechanismus wie /etc/passwd überprüft. Die Vorgabe ist yes.

KerberosTicketCleanup
Legt fest, ob die Ticket-Zwischenspeicherdatei des Benutzers beim Abmelden automatisch zerstört
werden soll. Die Vorgabe ist yes.

KexAlgorithms
Legt die verfügbaren KEX- (Schlüsselaustausch-)algorithmen fest. Falls alternativ die festgelegte
Liste mit einem »+«-Zeichen beginnt, werden die festgelegten Algorithmen an die Vorgabemenge
angehängt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem »-«-Zeichen beginnt, dann
werden die festgelegten Algorithmen (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge
entfernt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem »^«-Zeichen beginnt, dann
werden die festgelegten Algorithmen an den Anfang der Vorgabemenge gestellt. Die unterstützten
Algorithmen sind:

curve25519-sha256
curve25519-sha256@libssh.org
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
sntrup761x25519-sha512@openssh.com

Die Vorgabe ist:

sntrup761x25519-sha512@openssh.com,
curve25519-sha256,curve25519-sha256@libssh.org,
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
diffie-hellman-group-exchange-sha256,
diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,
diffie-hellman-group14-sha256

Die Liste der verfügbaren Schlüsselaustauschalgorithmen kann auch mittels "ssh -Q KexAlgorithms"
erlangt werden.

ListenAddress
Legt die lokale Adresse fest, auf der sshd(8) auf Anfragen warten soll. Die folgenden Formen
können verwandt werden:

ListenAddress Rechnername|Adresse
ListenAddress Rechner:Port
ListenAddress IPv4-Adresse:Port
ListenAddress [Rechnername|Adresse]:Port

Falls Port nicht angegeben ist, wird Sshd auf allen Adressen auf Anfragen warten und alle
Optionen Port sind festgelegt. Standardmäßig wird auf allen lokalen Adressen auf Anfragen
gewartet. Mehrere ListenAddress sind erlaubt.

LoginGraceTime
Der Server beendet die Verbindung nach dieser Zeit, falls sich der Benutzer nicht erfolgreich
angemeldet hat. Falls der Wert 0 ist, gibt es keine Zeitbeschränkung. Die Vorgabe ist 120
Sekunden.

LogLevel
Gibt die Ausführlichkeitsstufe an, die beim Protokollieren von Nachrichten von sshd(8) verwandt
wird. Mögliche Werte sind QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 und DEBUG3.
Die Vorgabe ist INFO. DEBUG und DEBUG1 sind äquivalent. DEBUG2 und DEBUG3 legen jeweils höhere
Stufen an Fehlerausgaben fest. Protokollierung mit einer DEBUG-Stufe verletzt die Privatsphäre
der Benutzer und wird nicht empfohlen.

LogVerbose
Legt eine oder mehrere Außerkraftsetzungen für LogLevel fest. Eine Außerkraftsetzung besteht aus
einer Musterliste, die auf die Quelldatei, Funktion und Zeilennummer passt, für die detaillierte
Protokollierung erzwungen werden soll. Beispielsweise würde ein Außerkraftsetzungsmuster

kex.c:*:1000,*:kex_exchange_identification():*,packet.c:*

detaillierte Protokollierung für Zeile 1000 von kex.c, alles in der Funktion
kex_exchange_identification() und allen Code in der Datei packet.c aktivieren. Diese Option ist
zur Fehlersuche gedacht und standardmäßig sind keine Außerkraftsetzungen aktiviert.

MACs Legt die verfügbaren MAC- (Codes für Nachrichtenauthentifizierung) Algorithmen fest. Der MAC-
Algorithmus wird für den Daten-Integritätsschutz verwandt. Mehrere Algorithmen müssen durch
Kommata getrennt werden. Falls die festgelegte Liste mit einem »+«-Zeichen beginnt, werden die
festgelegten Algorithmen an die Vorgabemenge angehängt, statt sie zu ersetzen. Falls die
festgelegte Liste mit einem »-«-Zeichen beginnt, dann werden die festgelegten Algorithmen
(einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen. Falls
die festgelegte Liste mit einem »^«-Zeichen beginnt, dann werden die festgelegten Algorithmen an
den Anfang der Vorgabemenge gestellt.

Die Algorithmen, die "-etm" enthalten, berechnen den MAC nach der Verschlüsselung (encrypt-then-
mac). Diese werden als sicherer betrachtet und ihr Einsatz wird empfohlen. Die unterstützten MACs
sind:

hmac-md5
hmac-md5-96
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
umac-64@openssh.com
umac-128@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Die Vorgabe ist:

umac-64-etm@openssh.com,umac-128-etm@openssh.com,
hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
hmac-sha1-etm@openssh.com,
umac-64@openssh.com,umac-128@openssh.com,
hmac-sha2-256,hmac-sha2-512,hmac-sha1

Die Liste der verfügbaren MAC-Algorithmen kann auch mittels "ssh -Q mac" erhalten werden.

Match Leitet einen Bedingungsblock ein. Falls sämtliche Kriterien auf der Zeile Match erfüllt sind,
setzen die Schlüsselwörter auf den folgenden Zeilen solche im globalen Abschnitt der
Konfigurationsdatei außer Kraft, bis entweder eine andere Zeile Match oder das Ende der Datei
auftaucht. Falls ein Schlüsselwort in mehreren erfüllten Match -Blöcken auftaucht, wird nur die
erste Instanz des Schlüsselwortes angewandt.

Die Argumente von Match sind eines oder mehrere Kriterium-Muster-Paare oder das einzelne Merkmal
All, das auf alle Kriterien passt. Die verfügbaren Kriterien sind User, Group, Host,
LocalAddress, LocalPort und Address.

Die »match«-Muster bestehen aus einzelnen Einträgen oder durch Kommata getrennten Listen und
können die im Abschnitt “MUSTER” von ssh_config(5) beschriebenen Platzhalter und
Verneinungsoperatoren verwenden.

Die Muster in einem Address -Kriterium können zusätzlich passende Adressen im CIDR-
address/masklen-Format enthalten, wie 192.0.2.0/24 oder 2001:db8::/32. Beachten Sie, dass die
bereitgestellte Maskenlänge zur der Adresse passen muss - es ist ein Fehler, wenn eine
Maskenlänge festgelegt wird, die für die Adresse zu lang ist oder eine, bei der Bits in diesem
Rechneranteil der Adresse gesetzt sind. Beispiel: 192.0.2.0/33 bzw. 192.0.2.0/8.

Auf den Zeilen, die einem Schlüsselwort Match folgen, darf nur eine Teilmenge der Schlüsselwörter
verwandt werden. Verfügbare Schlüsselwörter sind AcceptEnv, AllowAgentForwarding, AllowGroups,
AllowStreamLocalForwarding, AllowTcpForwarding, AllowUsers, AuthenticationMethods,
AuthorizedKeysCommand, AuthorizedKeysCommandUser, AuthorizedKeysFile,
AuthorizedPrincipalsCommand, AuthorizedPrincipalsCommandUser, AuthorizedPrincipalsFile, Banner,
CASignatureAlgorithms, ChannelTimeout, ChrootDirectory, ClientAliveCountMax, ClientAliveInterval,
DenyGroups, DenyUsers, DisableForwarding, ExposeAuthInfo, ForceCommand, GatewayPorts,
GSSAPIAuthentication, HostbasedAcceptedAlgorithms, HostbasedAuthentication,
HostbasedUsesNameFromPacketOnly, IgnoreRhosts, Include, IPQoS, KbdInteractiveAuthentication,
KerberosAuthentication, LogLevel, MaxAuthTries, MaxSessions, PasswordAuthentication,
PermitEmptyPasswords, PermitListen, PermitOpen, PermitRootLogin, PermitTTY, PermitTunnel,
PermitUserRC, PubkeyAcceptedAlgorithms, PubkeyAuthentication, PubkeyAuthOptions, RekeyLimit,
RevokedKeys, SetEnv, StreamLocalBindMask, StreamLocalBindUnlink, TrustedUserCAKeys,
UnusedConnectionTimeout, X11DisplayOffset, X11Forwarding und X11UseLocalhost.

MaxAuthTries
Legt die maximale Anzahl von Authentifizierungsversuchen fest, die pro Verbindung erlaubt sind.
Sobald die Anzahl der Fehlschläge die Hälfte dieses Wertes erreicht hat, werden zusätzliche
Fehlschläge protokolliert. Die Vorgabe ist 6.

MaxSessions
Legt die maximale Anzahl an offenen Shell-, Anmelde- oder Subsystem- (z.B. Sftp-)Sitzungen fest,
die pro Netzwerkverbindung erlaubt sind. Durch Clients, die Verbindungs-Multiplexen erlauben,
können mehrere Sitzungen etabliert werden. Durch Setzen von MaxSessions auf 1 wird Sitzung-
Multiplexen praktisch deaktiviert, wohingegen das Setzen auf 0 sämtliche Shell-, Anmelde- und
Subsystem-Sitzungen verhindern, aber weiterhin die Weiterleitung ermöglichen wird. Die Vorgabe
ist 10.

MaxStartups
Legt die maximale Anzahl an gleichzeitigen, nicht authentifizierten Verbindungen zum SSH-Server
fest. Zusätzliche Verbindungen werden verworfen, bis die Authentifizierung gelingt oder die
LoginGraceTime für eine Verbindung abläuft. Die Vorgabe ist 10:30:100.

Zusätzlich kann das frühe zufällige Verwerfen durch Angabe der drei durch Doppelpunkt getrennten
Werte Start:Rate:voll (z.B. »10:30:60«) festgelegt werden. sshd(8) wird Verbindungsversuche mit
einer Wahrscheinlichkeit von Rate/100 abweisen (30%), falls es derzeit Start (10) nicht
autorisierte Verbindungen gibt. Die Wahrscheinlichkeit wächst linear und alle Verbindungsversuche
werden abgelehnt, falls die Anzahl der nicht authentifizierten Verbindungen voll erreicht (60).

ModuliFile
Legt die moduli(5) -Datei fest, die die für die “diffie-hellman-group-exchange-sha1” und
“diffie-hellman-group-exchange-sha256” Schlüsselaustauschmethoden verwandten Diffie-Hellman-
Gruppen enthalten. Die Vorgabe ist /etc/ssh/moduli.

PasswordAuthentication
Legt fest, ob Passwortauthentifizierung erlaubt ist. Die Vorgabe ist yes.

PermitEmptyPasswords
Wenn Passwortauthentifizierung erlaubt ist, legt dies fest, ob der Server Anmeldungen für Konten
mit leeren Passwortzeichenketten erlaubt. Die Vorgabe ist no.

PermitListen
Legt die Adressen/Ports fest, auf denen ferne TCP-Portweiterleitungen auf Anfragen warten können.
Diese Festlegung muss eine der folgenden Formen einnehmen:

PermitListen Port
PermitListen Rechner:Port

Mehrere Erlaubnisse können angegeben werden, indem sie durch Leerraum getrennt werden. Ein
Argument any kann zur Entfernung aller Beschränkungen und der Erlaubnis jeder »listen«-Anfrage
verwandt werden. Ein Argument none kann zum Verbieten aller »listen«-Anfrage verwandt werden. Der
Rechnername darf Platzhalter enthalten, wie dies im Abschnitt MUSTER in ssh_config(5) beschrieben
ist. Der Platzhalter »*« kann auch anstelle einer Port-Nummer zum Erlauben aller Ports verwandt
werden. Standardmäßig werden alle Port-Weiterleitung »listen«-Anfragen erlaubt. Beachten Sie,
dass die Option GatewayPorts weiter einschränken kann, auf welchen Adressen auf Anfragen gewartet
werden kann. Beachten Sie auch, dass ssh(1) einen auf Anfragen wartenden Rechner als “localhost”
erbitten wird, falls in der »listen«-Anweisung kein auf Anfragen wartender Rechner speziell
erbeten wurde und dieser Name wird anders behandelt, um explizit Localhost-Adressen von
“127.0.0.1” und “::1”.

PermitOpen
Legt das Ziel fest, zu dem TCP-Port-Weiterleitung erlaubt ist. Die Weiterleitungsfestlegung muss
eine der folgenden Formen einnehmen:

PermitOpen Rechner:Port
PermitOpen IPv4-Adresse:Port
PermitOpen [IPv6-Adresse]:Port

Mehrere Weiterleitungen können angegeben werden, indem sie durch Leerraum getrennt werden. Ein
Argument any kann verwandt werden, um alle Beschränkungen zu entfernen und alle
Weiterleitungsanfragen zu erlauben. Ein Argument none kann verwandt werden, um alle
Weiterleitungsanfragen zu verbieten. Der Platzhalter »*« kann für Rechner oder Port verwandt
werden, um alle Rechner bzw. Ports zu erlauben. Darüber hinaus erfolgt kein Musterabgleich oder
Adressabfragen bei bereitgestellten Namen. Standardmäßig sind alle Port-Weiterleitungsanfragen
erlaubt.

PermitRootLogin
Legt fest, ob root sich mittels ssh(1) anmelden kann. Das Argument muss yes, prohibit-password,
forced-commands-only oder no sein. Die Vorgabe ist prohibit-password.

Falls diese Option auf prohibit-password (oder seinen veralteten Alias without-password) gesetzt
ist, wird Passwort- oder interaktive Anmeldung über die Tastatur für root deaktiviert.

Falls diese Option auf forced-commands-only gesetzt ist, wird die Anmeldung von root über
asymmetrische Authentifizierung erlaubt, aber nur falls die Option Befehl festgelegt wurde (was
nützlich für die Durchführung ferner Sicherungskopien ist, selbst falls die Anmeldung von root
normalerweise nicht erlaubt ist). Alle anderen Authentifizierungsmethoden für root sind
deaktiviert.

Falls diese Option auf no gesetzt ist, darf root sich nicht anmelden.

PermitTTY
Legt fest, ob pty(4) -Zuweisung erlaubt ist. Die Vorgabe ist yes.

PermitTunnel
Legt fest, ob tun(4) -Geräteweiterleitung erlaubt ist. Das Argument muss entweder yes,
point-to-point (Ebene 3), ethernet (Ebene 2) oder no sein. Festlegung von yes erlaubt sowohl
point-to-point als auch ethernet. Die Vorgabe ist no.

Unabhängig von dieser Einstellung muss die Berechtigung des ausgewählten tun(4) -Gerätes so
gesetzt sein, dass der Zugriff durch den Benutzer erlaubt ist.

PermitUserEnvironment
Legt fest, ob die Optionen ~/.ssh/environment und environment= in ~/.ssh/authorized_keys durch
sshd(8) verarbeitet werden. Gültige Optionen sind yes, no oder eine Muster-Liste, die angibt,
welche Umgebungsvariablennamen akzeptiert werden (beispielsweise "LANG,LC_*"). Die Vorgabe ist
no. Aktivierung der Verarbeitung der Umgebung kann Benutzer in die Lage versetzen, in einigen
Konfigurationen durch Verwendung von Mechanismen wie LD_PRELOAD die Zugriffsbeschränkungen zu
umgehen.

PermitUserRC
Legt fest, ob irgendeine Datei ~/.ssh/rc ausgeführt wird. Die Vorgabe ist yes.

PerSourceMaxStartups
Legt die Anzahl der nicht authentifizierten Verbindungen von der angegebenen Quelladresse fest
oder “none”, falls es keine Beschränkung gibt. Diese Beschränkung wird zusätzlich zu MaxStartups
angewandt, der niedrigere Wert wird benutzt. Die Vorgabe ist none.

PerSourceNetBlockSize
Legt die Anzahl an Bits der Quelladresse fest, die zum Zweck der Anwendung der Beschränkung
PerSourceMaxStartups zusammengruppiert werden. Es können Werte für IPv4 und optional IPv6
festgelegt werden, getrennt durch Doppelpunkt. Die Vorgabe ist 32:128, was bedeutet, dass jede
Adresse individuell betrachtet wird.

PidFile
Legt die Datei fest, die die Prozesskennung des SSH-Daemons enthält oder none, um keine zu
schreiben. Die Vorgabe ist /run/sshd.pid.

Port Legt die Nummer des Ports fest, an dem sshd(8) auf Anfragen warten soll. Die Vorgabe ist 22.
Mehrere Optionen dieser Art sind erlaubt. Siehe auch ListenAddress.

PrintLastLog
Legt fest, ob sshd(8) das Datum und die Uhrzeit der letzten Anmeldung des Benutzers ausgeben
soll, wenn sich ein Benutzer interaktiv anmeldet. Die Vorgabe ist yes.

PrintMotd
Legt fest, ob sshd(8) /etc/motd ausgeben soll, wenn sich ein Benutzer interaktiv anmeldet. (Auf
einigen Systemen wird sie auch von der Shell, /etc/profile oder äquivalenten Dateien ausgegeben.)
Die Vorgabe ist yes.

PubkeyAcceptedAlgorithms
Legt die Signaturalgorithmen, die für asymmetrische Authentifizierung akzeptiert werden, als eine
Liste von Kommata-getrennten Mustern fest. Falls alternativ die festgelegte Liste mit einem
»+«-Zeichen beginnt, werden die festgelegten Algorithmen an die Vorgabemenge angehängt, statt sie
zu ersetzen. Falls die festgelegte Liste mit einem »-«-Zeichen beginnt, dann werden die
festgelegten Algorithmen (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt,
statt sie zu ersetzen. Falls die festgelegte Liste mit einem »^«-Zeichen beginnt, dann werden die
festgelegten Algorithmen an den Anfang der Vorgabemenge gestellt. Die Vorgabe für diese Option
ist:

Die Liste der verfügbaren Signaturalgorithmen kann auch mittels "ssh -Q PubkeyAcceptedAlgorithms"
erhalten werden.

PubkeyAuthOptions
Setzt eine oder mehrere Optionen für asymmetrische Authentifizierung. Die unterstützten
Schlüsselwörter sind none (die Vorgabe; zeigt an, dass keine zusätzlichen Optionen aktiviert
sind), touch-required und verify-required.

Die Option touch-required führt dazu, dass asymmetrische Authentifizierung, die einen FIDO-
Authenticator-Algorithmus verwendet (d.h. ecdsa-sk oder ed25519-sk), immer verlangt, dass die
Signatur beglaubigt, dass der physisch anwesende Benutzer explizit die Authentifizierung
bestätigte (normalerweise durch Anfassen des Authenticators). Standardmäßig verlangt sshd(8) die
Anwesenheit des Benutzers, außer dies wird mit einer authorized_keys-Option außer Kraft gesetzt.
Der Schalter touch-required deaktiviert diese Außerkraftsetzung.

Die Option verify-required benötigt eine FIDO-Schlüsselsignatur-Beglaubigung, dass der Benutzer
verifiziert wurde, z.B. über eine PIN.

Weder die Option touch-required noch verify-required haben eine Auswirkung auf andere, nicht-FIDO
asymmetrische Schlüsseltypen.

PubkeyAuthentication
Legt fest, ob asymmetrische Authentifizierung erlaubt ist. Die Vorgabe ist yes.

RekeyLimit
Legt die maximale Datenmenge fest, die übertragen oder empfangen werden darf, bevor der
Sitzungsschlüssel neu ausgehandelt wird, optional von der maximalen Zeitdauer gefolgt, die
ablaufen darf, bevor der Sitzungsschlüssel neu ausgehandelt wird. Das erste Argument wird in Byte
festgelegt und ihm kann »K«, »M« oder »G« angehängt werden, um Kilobyte, Megabyte bzw. Gigabyte
anzuzeigen. Die Vorgabe liegt zwischen »1G« und »4G«, abhängig von der Chiffre. Der optionale
zweite Wert wird in Sekunden festgelegt und kann jede der im Abschnitt “ZEITFORMATE”
dokumentierten Einheiten verwenden. Der Vorgabewert für RekeyLimit ist default none, was
bedeutet, dass die Schlüsselneuaushandlung erfolgt, nachdem die Vorgabedatenmenge gesandt oder
empfangen wurde und keine Zeit-basierte Schlüsselneuaushandlung durchgeführt wird.

RequiredRSASize
Legt die minimale RSA-Schlüsselgröße (in Bit) fest, die sshd(8) akzeptieren wird. Benutzer- und
rechnerbasierte Authentifizierungsschlüssel, die kleiner als diese Begrenzung sind, werden
abgelehnt. Die Vorgabe ist 1024 bit. Beachten Sie, dass diese Beschränkung von der Vorgabe her
nur angehoben werden kann.

RevokedKeys
Legt die Datei zurückgezogener öffentlicher Schlüssel fest oder none, um keine zu verwenden. In
dieser Datei aufgeführte Schlüssel werden für asymmetrische Authentifizierung abgelehnt. Beachten
Sie, dass die asymmetrische Authentifizierung für alle Benutzer abgelehnt wird, falls diese Datei
nicht lesbar ist. Schlüssel können als Textdatei festgelegt werden, dabei wird ein Schlüssel pro
Zeile aufgeführt, oder als OpenSSH-Schlüsselsperrliste, wie sie von ssh-keygen(1) erstellt wird.
Für weitere Informationen über KRLs lesen Sie den Abschnitt SCHLÜSSELSPERRLISTEN in
ssh-keygen(1).

SecurityKeyProvider
Legt den Pfad zu einer Bibliothek fest, die zum Laden von FIDO-Schlüsseln auf Authenticatoren
verwandt wird. Dies setzt die eingebaute USB-HID-Unterstützung außer Kraft.

SetEnv Legt eine oder mehrere Umgebungsvariablen fest, die in durch sshd(8) gestarteten Kind-Sitzungen
als “NAME=WERT” gesetzt werden sollen. Die Umgebungsvariable kann in englische Anführungszeichen
gesetzt werden (z.B. falls sie Leerraumzeichen enthält). Durch SetEnv gesetzte Umgebungsvariablen
setzen die Vorgabe-Umgebung außer Kraft und alle durch den Benutzer mittels AcceptEnv oder
PermitUserEnvironment festgelegten Variablen.

StreamLocalBindMask
Setzt die oktale Dateierstellungsmaske (umask), die bei der Erstellung einer Unix-Domain-Socket-
Datei für lokale oder ferne Port-Weiterleitung verwandt werden soll. Diese Option wird nur für
Port-Weiterleitungen zu einer Unix-Domain-Socket-Datei verwandt.

Der Vorgabewert ist 0177. Dadurch wird eine Unix-Domain-Socket-Datei erstellt, die nur der
Eigentümer lesen und schreiben kann. Beachten Sie, dass nicht alle Betriebssysteme den Dateimodus
bei Unix-Domain-Socket-Dateien berücksichtigen.

StreamLocalBindUnlink
Legt fest, ob eine bestehende UNIX-Domain-Socket-Datei für lokale oder ferne Port-Weiterleitung
enfernt werden soll, bevor eine neue erstellt wird. Falls die Socket-Datei bereits existiert und
StreamLocalBindUnlink nicht aktiviert ist, wird sshd nicht in der Lage sein, den Port an die
UNIX-Domain-Socket-Datei weiterzuleiten. Diese Option wird nur für Port-Weiterleitungen an UNIX-
Domain-Socket-Dateien verwandt.

Das Argument muss yes oder no sein. Die Vorgabe ist no.

StrictModes
Legt fest, ob sshd(8) Dateimodi und Eigentümerschaft der Dateien des Benutzers und des Home-
Verzeichnisses prüfen soll, bevor es eine Anmeldung akzeptiert. Normalerweise ist dies
wünschenswert, da Anfänger manchmal versehentlich ihre Verzeichnisse und Dateien für alle
beschreibbar belassen. Die Vorgabe ist yes. Beachten Sie, dass dies nicht für ChrootDirectory
gilt, dessen Berechtigungen und Eigentümerschaft bedingungslos geprüft werden.

Subsystem
Konfiguriert ein externes Subsystem (z.B. einen Dateiübertragungs-Daemon). Argumente sollten ein
Subsystemname und ein Befehl sein (mit optionalen Argumenten), um eine Subsystem-Anfrage
auszuführen.

Der Befehl sftp-server implementiert das SFTP-Dateiübertragungs-Subsystem.

Alternativ implementiert der Name internal-sftp einen In-Prozess-SFTP-Server. Dies kann
Konfigurationen bei der Verwendung von ChrootDirectory vereinfachen, bei der eine andere
Dateisystemwurzel auf Clients erzwungen wird.

Standardmäßig sind keine Subsysteme definiert.

SyslogFacility
Gibt die beim Protokollieren von sshd(8) verwandte Einrichtung an. Mögliche Werte sind: DAEMON,
USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. Die Vorgabe ist AUTH.

TCPKeepAlive
Legt fest, ob das System TCP-Keepalive-Nachrichten zu der anderen Seite senden soll. Falls diese
gesandt werden, wird der Abbruch der Verbindung oder ein Absturz einer der Maschinen korrekt
bemerkt. Allerdings bedeutet dies, dass die Verbindung abgebrochen wird, falls die Route
vorübergehend nicht verfügbar ist, was einige Leute nervend finden. Andererseits können Sitzungen
unbegrenzt auf dem Server hängen, falls TCP-Keepalive-Nachrichten nicht gesandt werden, wodurch
"Geister" -Benutzer verbleiben und Server-Ressourcen verbraucht werden.

Die Vorgabe ist yes (TCP-Keepalive-Nachrichten werden gesandt) und der Server wird bemerken,
falls das Netzwerk unverfügbar wird oder der Rechner des Clients abstürzt. Dies verhindert
unbegrenzt hängende Sitzungen.

Um TCP-Keepalive-Nachrichten zu deaktivieren, sollte der Wert auf no gesetzt werden.

Diese Option hieß früher KeepAlive.

TrustedUserCAKeys
Legt eine Datei fest, die öffentliche Schlüssel von Zertifizierungsstellen enthält, denen
vertraut wird, Benutzerzertifikate zur Authentifizierung zu signieren, oder none, um keine zu
verwenden. Pro Zeile wird ein Schlüssel aufgeführt. Leere Zeilen und Kommentare, die mit ‘#’
beginnen, sind erlaubt. Falls zur Authentifizierung ein Zertifikat präsentiert wird und es über
eine in dieser Datei aufgeführte signierende CA verfügt, dann kann es zur Authentifizierung für
jeden Benutzer verwandt werden, der in der Liste der Prinzipalen für das Zertifikat aufgeführt
ist. Beachten Sie, dass Zertifikate, denen eine Liste der Prinzipalen fehlt, für die
Authentifizierung mittels TrustedUserCAKeys nicht erlaubt werden. Für weitere Details über
Zertifikate, lesen Sie den Abschnitt ZERTIFIKATE in ssh-keygen(1).

UnusedConnectionTimeout
Legt fest, ob und wie schnell sshd(8) Client-Verbindungen ohne offene Kanäle schließen soll.
Offene Kanäle sind unter anderem aktive Shells, Befehlesausführungen oder Subsystemsitzungen,
verbundene Netzwerk-, Socket-, Vermittler- oder X11-Weiterleitungen. Auf Anfragen wartende
Weiterleitungen, wie die des Schalters -R von ssh(1), werden nicht als offene Kanäle betrachtet
und verhindern nicht die Zeitüberschreitung. Der Zeitüberschreitungswert wird in Sekunden
festgelegt oder kann jede der im Abschnitt “ZEITFORMATE” dokumentierten Einheiten verwenden.

Beachten Sie, dass diese Zeitüberschreitung beginnt, wenn die Client-Verbindung die
Benutzerauthentifizierung abschließt, aber bevor der Client die Möglichkeit hat, einen Kanal zu
öffnen. Bei der Verwendung kurzer Zeitüberschreitungswerte sollte Vorsicht walten gelassen
werden, da sie dem Client nicht genug Zeit lassen könnten, um seine Kanäle anzufordern und zu
öffnen, bevor die Sitzung beendet wird.

Die Vorgabe ist none, wordurch Verbindungen niemals aufgrund fehlender offener Kanäle ablaufen.
Diese Option kann zusammen mit ChannelTimeout nützlich sein.

UseDNS Legt fest, ob sshd(8) den fernen Rechnernamen nachschlagen soll, um zu prüfen, ob der aufgelöste
Rechnername für die ferne IP-Adresse zu der gleichen IP-Adresse zurückabgebildet wird.

Falls diese Option auf (die Vorgabe) no gesetzt ist, dann werden nur Adressen und keine
Rechnernamen in den Direktiven from und Match Host in ~/.ssh/authorized_keys verwandt.

UsePAM Aktiviert die »Pluggable Authentication Module«-Schnittstelle. Falls auf yes gesetzt wird dies
zusätzlich zu der für alle Authentifizierungen erfolgenden PAM-Konten und
-Sitzungsmodulverarbeitungen die PAM-Authentifizierung mittels KbdInteractiveAuthentication und
PasswordAuthentication aktivieren.

Da die PAM-Authentifizierung mittels interaktiver Tastatureingabe normalerweise eine äquivalente
Rolle zur Passwort-Authentifizierung spielt, sollten Sie entweder PasswordAuthentication oder
KbdInteractiveAuthentication deaktivieren.

Falls UsePAM aktiviert ist, müssen Sie zwingend sshd(8) als Benutzer root ausführen. Die Vorgabe
ist no.

VersionAddendum
Legt optional zusätzlichen Text fest, der dem SSH-Protokoll-Spruchtext, der beim
Verbindungsaufbau durch den Server gesandt wird, angehängt wird. Die Vorgabe ist none.

X11DisplayOffset
Legt die für die X11-Weiterleitung von sshd(8)erste verfügbare Display-Nummer fest. Dies
verhindert, dass Sshd mit echten X11-Servern in Konflikt gerät. Die Vorgabe ist 10.

X11Forwarding
Legt fest, ob X11-Weiterleitung erlaubt ist. Das Argument muss entweder yes oder no sein. Die
Vorgabe ist no.

Wenn X11-Weiterleitung aktiviert ist, kann es eine zusätzliche Offenlegung des Servers und der
Client-Displays geben, falls das Proxy-Display von sshd(8) konfiguriert wird, auf der
Platzhalter-Adresse auf Anfragen zu warten (siehe X11UseLocalhost). Dies ist allerdings nicht die
Vorgabe. Zusätzlich erfolgt die Fälschung der Authentifizierung und die Überprüfung der
Authentifizierungsdaten und deren Ersetzung auf der Client-Seite. Das Sicherheitsrisiko bei der
Verwendung der X11-Weiterleitung besteht darin, das der X11-Display-Server des Clients Angriffen
unterworfen werden kann, wenn der SSH-Client eine Weiterleitung anfordert (siehe die Warnungen
für ForwardX11 in ssh_config(5)). Ein Systemadministrator kann die Haltung vertreten, dass sie
Clients schützen möchte, die sich Angriffen öffnen könnten, indem sie unbeabsichtigt
X11-Weiterleitung erbitten, wodurch dann eine Einstellung von no gerechtfertigt ist.

Beachten Sie, dass das Deaktivieren der X11-Weiterleitung die Benutzer nicht daran hindert,
X11-Verkehr weiterzuleiten, da die Benutzer immer ihre eigenen Weiterleitungsprogramme
installieren können.

X11UseLocalhost
Legt fest, ob sshd(8) den X11-Weiterleitungs-Server an die Loopback-Adresse oder an die
Platzhalter-Adresse binden soll. Standardmäßig bindet Sshd den Weiterleitungs-Server an die
Loopback-Adresse und setzt den Rechnernamen-Anteil der Umgebungsvariable DISPLAY auf localhost.
Dies verhindert, dass ferne Rechner sich mit dem Proxy-Display verbinden. Allerdings könnten
einige ältere X11-Clients mit dieser Konfiguration nicht funktionieren. X11UseLocalhost kann auf
no gesetzt werden, um festzulegen, dass der Weiterleitungs-Server an die Platzhalter-Adresse
gebunden werden soll. Das Argument muss entweder yes oder no sein. Die Vorgabe ist yes.

XAuthLocation
Legt den vollständigen Pfadnamen des Programms xauth(1) fest oder none, um keines zu verwenden.
Die Vorgabe ist /usr/bin/xauth.

ZEITFORMATE

       sshd(8) Befehlszeilenargumente und Konfigurationsdateioptionen, die eine Zeit festlegen,  können  mittels
       einer  Sequenz  der  folgenden  Form  ausgedrückt  werden: Zeit[Kennzeichner], , wobei Zeit ein positiver
       Ganzzahlwert ist und Kennzeichner eines der Folgenden:

             ⟨none⟩  Sekunden
             s | S   Sekunden
             m | M   Minuten
             h | H   Stunden
             d | D   Tage
             w | W   Wochen

       Jedes Mitglied der Sequenz wird aufaddiert, um den Gesamtzeitwert zu berechnen.

       Beispiele für Zeitformate:

             600     600 Sekunden (10 Minuten)
             10m     10 Minuten
             1h30m   1 Stunde 30 Minuten (90 Minuten)

MERKMALE

       Argumente für manche Schlüsselwörter können Merkmale verwenden, die zur Laufzeit expandiert werden:

             %%    Ein wörtliches »%«.
             %C    Identifiziert die Verbindungsendpunkte und enthält vier, durch Leerzeichen  getrennte  Werte:
                   Client-Adresse, Client-Port-Nummer, Server-Adresse und Server-Port-Nummer.
             %F    Der Fingerabdruck des CA-Schlüssels.
             %f    Der Fingerabruck des Schlüssels oder Zertifikates.
             %h    Das Home-Verzeichnis des Benutzers.
             %i    Die Schlüsselkennung im Zertifikat.
             %K    Der Base64-kodierte CA-Schlüssel.
             %k    Der Base64-kodierte Schlüssel oder das Zertifikat für die Authentifizierung.
             %s    Die Seriennummer des Zertifikats.
             %T    Der Typ des CA-Schlüssels.
             %t    Der Typ des Schlüssels oder Zertifikats.
             %U    Die numerische Benutzerkennung des Zielbenutzers.
             %u    Der Benutzername.

       AuthorizedKeysCommand akzeptiert die Merkmale %%, %C, %D, %f, %h, %k, %t, %U und %u.

       AuthorizedKeysFile akzeptiert die Merkmale %%, %h, %U und %u.

       AuthorizedPrincipalsCommand  akzeptiert  die  Merkmale %%, %C, %D, %F, %f, %h, %i, %K, %k, %s, %T, %t, %U
       und %u.

       AuthorizedPrincipalsFile akzeptiert die Merkmale %%, %h, %U und %u.

       ChrootDirectory akzeptiert die Merkmale %%, %h, %U und %u.

DATEIEN

       /etc/ssh/sshd_config
               Enthält Konfigurationsdaten für sshd(8). Diese Datei sollte nur für Root beschreibbar sein,  aber
               es wird empfohlen (ist aber nicht notwendig), dass sie alle lesen können.

SIEHE AUCH

       sftp-server(8), sshd(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                                           28. Juli, 2023                                   SSHD_CONFIG(5)