Scroll to navigation

SSHD_CONFIG(5) File Formats Manual SSHD_CONFIG(5)

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. Für jedes Schlüsselwort wird 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:

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):

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 erbittet, 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.
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).
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.
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.

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

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

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.

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

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

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.
Legt die Algorithmen fest, die zum Signieren von Zertifikaten durch Zertifizierungsstellen (CAs) erlaubt sind. Die Vorgabe ist: 
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

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

Legt fest, ob die Challenge-Respones-Authentifizierung erlaubt ist (z.B. über PAM). Die Vorgabe ist yes.
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.

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.

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.

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.
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.
Legt fest, ob die Distributions-spezifische zusätzliche Versionsendung während des anfänglichen Protokoll-Handshakes eingebunden wird. Die Vorgabe ist yes.
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.

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.

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.
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.
Legt den zum Protokollieren von Schlüsselfingerabdrücken verwandten Hash-Algorithmus fest. Gültige Optionen sind md5 und sha256. Die Vorgabe ist sha256.
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.
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.
Legt fest, ob die GSSAPI-basierte Benutzerauthentifizierung erlaubt ist. Die Vorgabe ist no.
Legt fest, ob der Zwischenspeicher mit den Anmeldedaten des Benutzers beim Abmelden automatisch zerstört werden soll. Die Vorgabe ist yes.
Legt fest, ob auf GSSAPI basierender Schlüsselaustausch akzeptiert 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.
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.
Steuert, ob die GSSAPI-Anmeldedaten des Benutzer nach einer erfolgreichen Schlüsselneuaushandlung nach einer Verbindungsaufnahme aktualisert 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.

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.

Legt die Schlüsseltypen, als Liste von Kommata-getrennten Muster, die für Rechner-basierte Authentifizierung akzeptiert werden, fest. Falls alternativ die festgelegte Liste mit einem ‘+’ -Zeichen beginnt, werden die festgelegten Schlüsseltypen an die Vorgabemenge angehängt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem ‘-’ -Zeichen beginnt, dann werden die festgelegten Schlüsseltypen (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem ‘^’ -Zeichen beginnt, dann werden die festgelegten Schlüsseltypen an den Anfang der Vorgabemenge gestellt. Die Vorgabe für diese Option lautet: 
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
ssh-ed25519-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ecdsa-sha2-nistp256@openssh.com,
ssh-ed25519,sk-ssh-ed25519@openssh.com,
rsa-sha2-512,rsa-sha2-256,ssh-rsa

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

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

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.
Legt die vom Dienst angebotenen Rechner-Schlüssel-Algorithmen fest. Die Vorgabe für diese Option lautet: 
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
ssh-ed25519-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ecdsa-sha2-nistp256@openssh.com,
ssh-ed25519,sk-ssh-ed25519@openssh.com,
rsa-sha2-512,rsa-sha2-256,ssh-rsa

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

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.

Legt fest, ob sshd(8) die ~/.ssh/known_hosts während HostbasedAuthentication ignorieren und nur die systemweite Datei bekannter Rechner /etc/ssh/known_hosts verwenden soll. Die Vorgabe ist “no”.
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.
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.
Legt fest, ob interaktive Anmeldung über die Tastatur erlaubt wird. Das Argument für dieses Schlüsselwort muss yes oder no lauten. Die Vorgabe ist, den Wert zu verwenden, auf den ChallengeResponseAuthentication gesetzt ist (standardmäßig yes).
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.
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.
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.
Legt fest, ob die Ticket-Zwischenspeicherdatei des Benutzers beim Abmelden automatisch zerstört werden soll. Die Vorgabe ist yes.
Legt die verfügbaren KEX- (Schlüsselaustausch-)algorithmen fest. Falls alternativ die festgelegte Liste mit einem ‘+’ -Zeichen beginnt, werden die festgelegten Methoden an die Vorgabemenge angehängt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem ‘-’ -Zeichen beginnt, dann werden die festgelegten Methoden (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem ‘^’ -Zeichen beginnt, dann werden die festgelegten Methoden 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
  • sntrup4591761x25519-sha512@tinyssh.org

Die Vorgabe ist:

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.

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

Der optionale Kennzeichner rdomain bittet sshd(8), auf einer expliziten Routing-Domain auf Anfragen zu warten. 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 der aktuellen Standard-Routing-Domain auf Anfragen gewartet. Mehrere ListenAddress sind erlaubt. Für weitere Informationen über Routing-Domains, siehe rdomain(4).

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

Leitet einen Bedingungsblock ein. Falls sämtliche Kriterien auf der Zeile Match erfüllt sind, setzten 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, RDomain und Address (wobei RDomain die rdomain(4) darstellt, auf der die Verbindung empfangen wurde).

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, dürfen 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, ChrootDirectory, ClientAliveCountMax, ClientAliveInterval, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAcceptedKeyTypes, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, IgnoreRhosts, Include, IPQoS, KbdInteractiveAuthentication, KerberosAuthentication, LogLevel, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitListen, PermitOpen, PermitRootLogin, PermitTTY, PermitTunnel, PermitUserRC, PubkeyAcceptedKeyTypes, PubkeyAuthentication, RekeyLimit, RevokedKeys, RDomain, SetEnv, StreamLocalBindMask, StreamLocalBindUnlink, TrustedUserCAKeys, X11DisplayOffset, X11Forwarding und X11UseLocalhost.

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.
Legt die maximale Anazhl 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.
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 authorisierte Verbindungen gibt. Die Wahrscheinlichkeit wächst linear und alle Verbindungsversuche werden abgelehnt, falls die Anzahl der nicht authentifizierten Verbindungen voll erreicht (60).

Legt fest, ob Passwortauthentifizierung erlaubt ist. Die Vorgabe ist yes.
Wenn Passwortauthentifizierung erlaubt ist, legt dies fest, ob der Server Anmeldungen für Konten mit leeren Passwortzeichenketten erlaubt. Die Vorgabe ist no.
Legt die Adressen/Ports fest, auf denen ferne TCP-Portweiterleitungen auf Anfragen warten können. Diese Festlegung muss eine der folgenden Formen einnehmen:

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

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

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.

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

Legt fest, ob pty(4) -Zuweisung erlaubt ist. Die Vorgabe ist yes.
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 den Zugriff durch den Benutzer erlauben.

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.
Legt fest, ob irgendeine Datei ~/.ssh/rc ausgeführt wird. Die Vorgabe ist yes.
Legt die Datei fest, die die Prozesskennung des SSH-Daemons enthält oder none, um keine zu schreiben. Die Vorgabe ist /run/sshd.pid.
Legt die Port-Nummer fest, an der sshd(8) auf Anfragen warten soll. Die Vorgabe ist 22. Mehrere Optionen dieser Art sind erlaubt. Siehe auch ListenAddress.
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.
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.
Legt die Schlüsseltypen, als Liste von Kommata-getrennten Muster, die für asymetrische Authentifizierung akzeptiert werden, fest. Falls alternativ die festgelegte Liste mit einem ‘+’ -Zeichen beginnt, werden die festgelegten Schlüsseltypen an die Vorgabemenge angehängt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem ‘-’ -Zeichen beginnt, dann werden die festgelegten Schlüsseltypen (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen. Falls die festgelegte Liste mit einem ‘^’ -Zeichen beginnt, dann werden die festgelegten Schlüsseltypen an den Anfang der Vorgabemenge gestellt. Die Vorgabe für diese Option lautet: 
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
ssh-ed25519-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ecdsa-sha2-nistp256@openssh.com,
ssh-ed25519,sk-ssh-ed25519@openssh.com,
rsa-sha2-512,rsa-sha2-256,ssh-rsa

Die Liste der verfügbaren Schlüsseltypen kann auch mittels "ssh -Q PubkeyAcceptedKeyTypes" erhalten werden.

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

Legt fest, ob asymmetrische Authentifizierung erlaubt ist. Die Vorgabe ist yes.
Legt die maximale Datenmenge fest, die übertragen 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 jeder der im Abschnitt ZEITFORMATE dokumentierte Einheit 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.
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).
Legt eine explizite Routing-Domain fest, die nach Abschluss der Authentifizierung angewandt wird. Die Benutzersitzung sowie sämtliche weitergeleiteten oder auf Anfrage wartenden IP-Sockets werden an diese rdomain(4) gebunden. Falls die Routing-Domain auf %D gesetzt ist, dann wird die Domain angewandt, auf der die eingehende Verbindung empfangen wurde.
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.
Legt eine oder mehrere Umgebungsvariablen fest, die in durch sshd(8) gestarten 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.
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, auf die nur der Eigentümer lesen und schreiben kann. Beachten Sie, dass nicht alle Betriebssysteme den Dateimodus bei Unix-Domain-Socket-Dateien berücksichtigen.

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.

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

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

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).
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 sshd_config Match Host in ~/.ssh/authorized_keys verwandt.

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

Da die PAM-challenge-response-Authentifizierung normalerweise eine äquivalente Rolle zur Passwort-Authentifizierung spielt, sollten Sie entweder PasswordAuthentication oder ChallengeResponseAuthentication deaktiveren.

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

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.
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.
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 der 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 erbittet (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.

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.
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
|
Sekunden
|
Minuten
|
Stunden
|
Tage
|
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 ‘%’.
%D
Die Routing-Domain, in der die eingehende Verbindung empfangen wurde.
%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üssel.
%t
Der Typ des Schlüssels oder Zertifikats.
%U
Die numerische Benutzerkennung des Zielbenutzers.
%u
Der Benutzername.

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

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

AuthorizedPrincipalsCommand akzeptiert die Merkmale %%, %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.

RoutingDomain akzeptiert das Merkmal %D.

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.

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer

$Mdocdate: 27. August 2020 $ Debian