DOKK / manpages / debian 11 / manpages-de / ssh_config.5.de
SSH_CONFIG(5) File Formats Manual SSH_CONFIG(5)

ssh_config — OpenSSH-Client-Konfigurationsdatei

ssh(1) erhält Konfigurationsdaten aus den folgenden Quellen in der folgenden Reihenfolge:

  1. Befehlszeilenoptionen
  2. die Konfigurationsdatei des Benutzers (~/.ssh/config)
  3. die systemweite Konfigurationsdatei (/etc/ssh/ssh_config)

Für jeden Parameter wird der erste erhaltene Wert verwandt. Die Konfigurationsdateien enthalten durch Host -Spezifikationen getrennte Abschnitte und dieser Abschnitt wird nur für Rechner angewandt, die auf ein in der Spezifikation angegebenes Muster passen. Der passende Rechnername wird normalerweise auf der Befehlszeile übergeben (siehe beispielsweise die Option CanonicalizeHostname für Ausnahmen).

Da der erste erhaltene Wert für jeden Parameter verwandt wird, sollten die meisten Rechner-spezifischen Deklarationen in der Nähe des Anfangs der Datei und allgemeine Vorgaben am Ende angegeben werden.

Beachten Sie, dass das Debian-Paket openssh-client mehrere Optionen als Vorgabe in /etc/ssh/ssh_config setzt, die in ssh(1) nicht die Vorgabe sind:

Die Dateien /etc/ssh/ssh_config.d/*.conf werden am Anfang der systemweiten Konfigurationsdatei eingebunden, so dass dort gesetzte Optionen die in /etc/ssh/ssh_config gesetzten außer Kraft setzen werden.

Die Datei enthält Schlüsselwort-Argument-Paare, eines pro Zeile. Leere Zeilen und solche, die mit ‘#’ anfangen, werden als Kommentare interpretiert. Argumente können optional in englische doppelte Anführungszeichen (") eingeschlossen werden, um Argumente, die Leerzeichen enthalten, darzustellen. Konfigurationsoptionen können durch Leerraum oder optionalen Leerraum und genau ein ‘=’ abgetrennt werden; letzteres Format ist nützlich, um die Notwendigkeit von Anführungszeichen für Leerzeichen zu vermeiden, wenn Konfigurationsoptionen angegeben werden, die die Option ssh, scp und sftp -o enthalten.

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

Beschränkt die folgenden Deklarationen (bis zum nächsten Schlüsselwort Host oder Match) auf die Rechner, die auf eines der Muster passen, die nach dem Schlüsselwort angegeben sind. Falls mehr als ein Muster bereitgestellt wird, dann sollten sie durch Leerraum getrennt sein. Ein einzelnes ‘*’ als Muster kann zur Bereitstellung globaler Vorgaben für alle Rechner verwandt werden. Der Rechner ist normalerweise das auf der Befehlszeile übergebene Argument Rechnername (siehe das Schlüsselwort CanonicalizeHostname für Ausnahmen.

Ein Mustereintrag kann negiert werden, indem ihm ein Ausrufezeichen (‘!’) vorangestellt wird. Falls ein negierter Ausdruck passt, dann wird der Eintrag Host ignoriert, unabhängig davon, ob eines der anderen Muster auf der Zeile passt. Negierte Treffer sind daher nützlich, um Ausnahmen für Platzhalter-Treffer bereitzustellen.

Siehe MUSTER für weitere Informationen über Muster.

Beschränkt die folgenden Deklarationen (bis zum nächsten Schlüsselwort Host oder Match) auf die Fälle, bei denen die Bedingungen, die nach dem Schlüsselwort Match angegeben sind, erfüllt sind. Trefferbedingungen werden mittels einem oder mehreren Kriterien oder dem einzelnen Merkmal all, das immer zutrifft, festgelegt. Die verfügbaren Kriterienschlüsselwörter sind: canonical, final, exec, host, originalhost, user und localuser. Das Kriterium all muss alleine oder direkt nach canonical oder final auftauchen. Andere Kriterien können beliebig kombiniert werden. Alle Kriterien außer all, canonical und final benötigen ein Argument. Kriterien können negiert werden, in denen ihnen ein Ausrufezeichen (‘!’) vorangestellt wird.

Das Schlüsselwort canonical passt nur, wenn die Konfigurationsdatei nach der Umwandlung des Rechnernamens in eine kanonische Form (siehe die Option CanonicalizeHostname) erneut ausgewertet wird. Dies kann nützlich sein, um Bedingungen festzulegen, die nur mit kanonischen Rechnernamen funktionieren.

Das Schlüsselwort final erbittet, dass die Konfiguration neu ausgewertet werden soll (egal, ob CanonicalizeHostname aktiviert ist) und passt nur während des abschließenden Durchlaufs. Falls CanonicalizeHostname aktiviert ist, dann passen canonical und final während des gleichen Durchlaufs.

Das Schlüsselwort exec führt den angegebenen Befehl unter der Shell des Benutzers aus. Falls der Befehl einen Exit-Status Null zurückliefert, dann wird die Bedingung als wahr betrachtet. Befehle, die Leerraumzeichen enthalten, müssen in englische Anführungszeichen gesetzt werden. Argumente von exec akzeptieren die im Abschnitt MERKMALE beschriebenen Merkmale.

Die Kriterien der anderen Schlüsselwörter müssen einzelne Einträge oder Kommata-getrennte Listen sein und können die im Abschnitt MUSTER beschriebenen Platzhalter- und Negierungsoperatoren verwenden. Die Kriterien für das Schlüsselwort host werden mit dem Zielrechnernamen verglichen, nachdem alle Ersetzungen durch die Optionen Hostname oder CanonicalizeHostname erfolgt sind. Das Schlüsselwort originalhost passt auf den Rechnernamen, wie er auf der Befehlszeile angegeben wurde. Das Schlüsselwort user passt auf den Zielbenutzernamen auf dem fernen Rechner. Das Schlüsselwort localuser passt auf den Namen des lokalen Benutzers, der ssh(1) ausführt (dieses Schlüsselwort kann in systemweiten ssh_config -Dateien nützlich sein).

Gibt an, ob Schlüssel automatisch zu einem laufenden ssh-agent(1) hinzugefügt werden sollen. Falls diese Option auf yes gesetzt ist und ein Schlüssel aus einer Datei geladen wird, wird der Schlüssel und seine Passphrase zu dem Vermittler mit der Standard-Lebensdauer hinzugefügt, als ob ssh-add(1) verwandt worden wäre. Falls diese Option auf ask gesetzt ist, wird ssh(1) eine Bestätigung über das Programm SSH_ASKPASS benötigen, bevor ein Schlüssel hinzugefügt wird (siehe ssh-add(1) für Details). Falls diese Option auf confirm gesetzt ist, muss jede Verwendung eines Schlüssel bestätigt werden, als ob die Option -c bei ssh-add(1) festgelegt worden wäre. Falls diese Option auf no gesetzt wird, werden keine Schlüssel zum Vermittler hinzugefügt. Alternativ kann diese Option als Zeitintervall, in dem im Abschnitt TIME FORMATS von sshd_config(5) beschriebenen Format angegeben werden, um die Lebensdauer in ssh-agent(1) festzulegen, nach der er automatisch entfernt wird. Das Argument muss no (die Vorgabe), yes, confirm (optional gefolgt von einem Zeitintervall), ask oder ein Zeitintervall sein.
Legt die bei Verbindungen zu verwendende Adressfamilie fest. Gültige Argumente sind any (die Vorgabe), inet (nur IPv4 verwenden) und inet6 (nur IPv6 verwenden).
Falls auf yes gesetzt, wird die Benutzerinteraktion wie Passwortabfragen und Bestätigungen von Rechnerschlüsselabfragen deaktiviert. Zusätzlich wird die Option ServerAliveInterval standardmäßig auf 300 Sekunden gesetzt (Debian-spezifisch). Diese Option ist in Skripten und anderen Stapelverarbeitungsaufträgen nützlich, bei denen kein Benutzer zur Interaktion mit ssh(1) verfügbar ist, und wo die schnelle Erkennung von Netzwerkfehlern gewünscht ist. Das Argument muss yes oder no (die Vorgabe) sein.
Verwendet die festgelegte Adresse auf der lokalen Maschine als Quelladresse der Verbindung. Nur für Systeme mit mehr als einer Adresse nützlich.
Verwendet die Adresse der festgelegten Schnittstelle auf der lokalen Maschine als die Quelladresse der Verbindung.
Diese Option gibt die Liste der Domain-Endungen an, in denen nach den angegeben Ziel-Rechnern gesucht werden soll, wenn CanonicalizeHostname aktiviert ist.
Legt fest, ob bei fehlgeschlagener Kanonisierung des Rechnernamens mit einem Fehler beendet werden soll. Die Vorgabe, yes, wird versuchen, den nicht qualifizierten Rechnernamen mittels der Auflösungssuchregeln des Systems nachzuschlagen. Ein Wert von no führt dazu, dass ssh(1) sofort fehlschlägt, falls CanonicalizeHostname aktiviert ist und der Zielrechnername nicht in einer der mittels CanonicalDomains festgelegten Domains gefunden werden kann.
Steuert, ob explizite Kanonisierung von Rechnernamen durchgeführt wird. Bei der Vorgabe, no, erfolgt keine Umschreibung und die Auflösung des Rechnernamens erfolgt durch die Systemauflöserroutinen. Falls auf yes gesetzt, dann wird ssh(1) versuchen, auf der Befehlszeile angegebene Rechnernamen für Verbindungen, die nicht ProxyCommand oder ProxyJump verwenden, mittels der Endungen CanonicalDomains und der Regeln CanonicalizePermittedCNAMEs zu kanonisieren. Falls CanonicalizeHostname auf always gesetzt ist, dann wird die Kanonisierung auch auf Verbindungen über Proxys angewandt.

Falls diese Option aktiviert ist, dann werden die Konfigurationsdateien mittels der neuen Zielnamen erneut ausgewertet, um sämtliche neue Konfiguration aufgrund von passenden Abschnitten Host und Match einzusammeln.

Gibt die maximale Anzahl an Punkten im Rechnernamen an, bevor die Kanonisierung deaktiviert wird. Die Vorgabe, 1, erlaubt einen einzelnen Punkt (d.h. Rechnername.Subdomain).
Legt die Regeln fest, nach denen bestimmt wird, ob CNAMEs gefolgt werden soll, wenn Rechnernamen kanonisiert werden. Die Regeln bestehen aus einem oder mehreren Argumenten der Form Quell-Domain-Liste:Ziel-Domain-Liste, wobei Quell-Domain-Liste eine Musterliste von Domains ist, die CNAMEs bei der Kanonisierung folgen dürfen und Ziel-Domain-Liste eine Musterliste von Domains ist, auf den diese aufgelöst werden dürfen.

Beispielsweise wird es "*.a.example.com:*.b.example.com,*.c.example.com" erlauben, Rechnernamen, die auf "*.a.example.com" passen, auf Namen in den Domains "*.b.example.com" oder "*.c.example.com" kanonisiert zu werden.

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

ssh(1) wird keine Rechnerzertifikate akzeptieren, die mit anderen als den festgelegten Algorithmen signiert sind.

Legt eine Datei fest, aus der das Zertifikat des Benutzers gelesen wird. Ein entsprechender privater Schlüssel muss separat in einer Direktive IdentityFile oder einem Schalter an ssh(1), mittels ssh-agent(1) oder mittels einem PKCS11Provider oder einem SecurityKeyProvider bereitgestellt werden, um dieses Zertifikat zu benutzen.

Argumente von CertificateFile können die Tilde-Syntax, um sich auf das Home-Verzeichnis des Benutzers zu beziehen, die im Abschnitt MERKMALE beschriebenen Merkmale und die im Abschnitt UMGEBUNGSVARIABLEN beschriebenen Umgebungsvariablen verwenden.

Es ist möglich, dass mehrere Zertifikatsdateien in Konfigurationsdateien festgelegt werden; diese Zertifikate werden der Reihen nach ausprobiert. Mehrere Direktiven CertificateFile fügen zu der Zertifikatsliste hinzu, die für die Authentifizierung verwandt wird.

Legt fest, ob Challenge-Response-Authentifizierung verwandt werden soll. Das Argument für dieses Schlüsselwort muss yes (die Vorgabe) oder no sein.
Falls auf yes (die Vorgabe) gesetzt, wird ssh(1) zusätzlich die Rechner-IP-Adresse in der Datei known_hosts überprüfen. Dies ermöglicht die Erkennung, ob sich ein Rechnerschlüssel aufgrund von DNS-Fälschungen geändert hat und wird Adressen von Zielrechnern bei dem Prozess zu ~/.ssh/known_hosts hinzufügen, unabhängig von der Einstellung von StrictHostKeyChecking. Falls diese Option auf no gesetzt ist, wird die Prüfung nicht durchgeführt.
Legt die erlaubten Chiffren und deren Reihenfolge fest. Mehrere Chiffren müssen durch Kommata getrennt werden. Falls die festgelegte Liste mit einem ‘+’ beginnt, dann werden die angegebenen Chiffren an die Vorgabemenge angehängt, statt diese zu ersetzen. Falls die angegebene Liste mit einem ‘-’ beginnt, dann werden die angegebenen Chiffren (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen. Falls die angegebene Liste mit einem ‘^’ beginnt, dann werden die angegebenen Chiffren am Anfang der Vorgabemenge abgelegt.

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.

Gibt an, dass alle in den Konfigurationsdateien oder auf der Befehlszeile festgelegten lokalen, fernen und dynamischen Portweiterleitungen zurückgesetzt werden. Diese Option ist besonders nützlich, wenn sie von der Befehlszeile von ssh(1) verwandt wird, um alle Portweiterleitungen in den Konfigurationsdateien zurückzusetzen. Sie wird automatisch von scp(1) und sftp(1) gesetzt. Das Argument muss entweder yes oder no (die Vorgabe) sein.
Legt fest, ob Kompression verwandt wird. Das Argument muss entweder yes oder no (die Vorgabe) sein.
Legt die Anzahl der Versuche (einen pro Sekunde) fest, bevor beendet wird. Das Argument muss eine Ganzzahl sein. Dies kann in Skripten nützlich sein, wenn die Verbindung manchmal fehlschlägt. Die Vorgabe ist 1.
Legt die Zeitüberschreitung (in Sekunden) fest, die bei Verbindungen zum SSH-Server statt der Standard-System-TCP-Zeitüberschreitung verwandt werden soll. Diese Zeitüberschreitung wird sowohl auf den Aufbau der Verbindung als auch bei der Durchführung der initialen SSH-Protokoll-Datenflusssteuerung und dem Schlüsselaustausch verwandt.
Aktiviert die gemeinsame Benutzung von mehreren Sitzungen über eine einzelne Netzwerkverbindung. Falls auf yes gesetzt, wird ssh(1) auf Verbindungen auf einem Steuer-Socket warten, das mit dem Argument ControlPath festgelegt ist. Zusätzliche Sitzungen können sich mit diesem Socket über den gleichen ControlPath mit ControlMaster gesetzt auf no (die Vorgabe) verbinden. Diese Sitzungen werden versuchen, die Netzwerkverbindungsinstanz des Masters mit zu benutzen, statt neue aufzubauen. Falls das Steuer-Socket nicht existiert oder nicht auf Anfragen wartet, werden sie aber auf normalen Verbindungsaufbau zurückfallen.

Wird dies auf ask gesetzt, dann wartet ssh(1) auf Steuerverbindungen, benötigt aber die Bestätigung mittels ssh-askpass(1). Falls der ControlPath nicht geöffnet werden kann, wird ssh(1) fortfahren, ohne sich mit der Master-Instanz zu verbinden.

Die Weiterleitung von X11 und ssh-agent(1) über diese multiplexten Verbindungen wird unterstützt, allerdings werden die weitergeleiteten Display und Vermittler zu denen der Master-Verbindung gehören, d.h. es ist nicht möglich, mehrere Displays oder Vermittler weiterzuleiten.

Zwei zusätzliche Optionen ermöglichen opportunistisches Multiplexing: es wird versucht, eine Master-Verbindung zu verwenden, aber auf die Erstellung einer neuen zurückgefallen, falls eine solche noch nicht existiert. Diese Optionen sind: auto und autoask. Letztere verlangt Bestätigung wie bei der Option ask.

Legt den Pfad zu dem Steuer-Socket fest, das für die gemeinsame Benutzung von Verbindungen, wie weiter oben in ControlMaster beschrieben oder der Zeichenkette none, um gemeinsame Benutzung von Verbindungen zu deaktiveren, verwandt wird. Argumente für ControlPath können die Tilde-Syntax, um sich auf das Home-Verzeichnis des Benutzers zu beziehen, die im Abschnitt MERKMALE beschriebenen Merkmale und die im Abschnitt UMGEBUNGSVARIABLEN beschrieben Umgebungsvariablen verwenden. Es wird empfohlen, dass alle ControlPath, die für opportunistische gemeinsame Verwendung von Verbindungen verwandt werden, mindestens %h, %p und %r (oder alternativ %C) enthalten und in einem Verzeichnis abgelegt werden, das von anderen Benutzern nicht beschreibbar ist. Dies stellt sicher, dass gemeinsam benutzte Verbindungen eindeutig identifiziert sind.
Wenn dies im Zusammenhang mit ControlMaster verwandt wird, legt dies fest, dass die Master-Verbindung im Hintergrund offen bleiben (und auf zukünftige Client-Verbindungen warten) soll, nachdem die anfängliche Client-Verbindung geschlossen wurde. Falls auf die Vorgabe no gesetzt, dann wird die Master-Verbindung nicht in den Hintergrund gelegt und geschlossen, sobald die anfängliche Verbindung geschlossen wird. Falls auf yes oder 0 gesetzt, wird die Master-Verbindung zeitlich unbegrenzt im Hintergrund verbleiben (bis sie beendet oder über einen Mechanismus wie "ssh -O exit" geschlossen wird). Falls sie auf eine Zeit in Sekunden oder Zeit in einem der in sshd_config(5) dokumentierten Formate gesetzt wird, dann wird die im Hintergrund befindliche Master-Verbindung automatisch beendet, nachdem sie für die festgelegte Zeit (ohne Client-Verbindungen) im Leerlauf gewesen ist.
Legt einen TCP-Port auf der lokalen Maschine fest, der über den sicheren Kanal weitergeleitet werden kann. Dann wird das Anwendungsprotokoll verwandt, um festzustellen, wo auf der fernen Maschine die Verbindung erfolgen soll.

Das Argument muss [Anbindeadresse:]Port sein. IPv6-Adressen können durch Einschluss in eckige Klammern angegeben werden. Standardmäßig wird der lokale Port in Übereinstimmung mit der Einstellung GatewayPorts angebunden. Allerdings kann eine explizite Anbindeadresse verwandt werden, um die Verbindung an eine bestimmte Adresse anzubinden. Die Verwendung von localhost als Anbindeadresse zeigt an, dass der Port, der auf Anfragen wartet, nur für die lokale Verwendung angebunden wird, während eine leere Adresse oder ‘*’ anzeigt, dass der Port von allen Schnittstellen aus verfügbar sein soll.

Derzeit werden die Protokolle SOCKS4 und SOCKS5 unterstützt und ssh(1) agiert als ein SOCKS-Server. Es können mehrere Weiterleitungen festgelegt werden und zusätzliche Weiterleitungen können auf der Befehlszeile übergeben werden. Nur der Systemadministrator kann privilegierte Ports weiterleiten.

Wird diese Option in der globalen Client-Konfigurationsdatei /etc/ssh/ssh_config auf yes gesetzt, dann werden die Helfer-Programme ssh-keysign(8) während HostbasedAuthentication aktiviert. Das Argument muss yes oder no (die Vorgabe) lauten. Die Option sollte außerhalb der Rechner-spezifischen Optionen abgelegt werden. Siehe ssh-keysign(8) für weitere Informationen.
Setzt das Maskierzeichen (Vorgabe: ‘~’). Das Maskierzeichen kann auch auf der Befehlszeile gesetzt werden. Das Argument sollte ein einzelnes Zeichen, ‘^’, gefolgt von einem Buchstaben oder none, um das Maskierzeichen komplett zu deaktivieren (um die Verbindung transparent für Binärdaten zu machen), sein.
Legt fest, ob ssh(1) die Verbindung beenden soll, falls es nicht alle dynamischen, Tunnel-, lokalen und fernen Port-Weiterleitungen einrichten kann (z.B. falls es an einem der Enden nicht gelingt, auf einem bestimmten Port anzubinden und dort auf Anfragen zu warten). Beachten Sie, dass ExitOnForwardFailure nicht auf Verbindungen angewandt wird, die über Port-Weiterleitungen erstellt wurden und beispielsweise nicht dazu führt, dass ssh(1) sich beendet, falls TCP-Verbindungen zum endgültigen Weiterleitungsziel fehlschlagen. Das Argument muss yes oder no (die Vorgabe) sein.
Legt den Hash-Algorithmus fest, der bei der Anzeige der Fingerabdrücke verwandt wird. Gültige Optionen sind md5 und sha256 (die Vorgabe).
Legt fest, ob die Verbindung zum Authentifizierungsvermittler (falls vorhanden) auf die ferne Maschine weitergeleitet wird. Das Argument kann yes, no (die Vorgabe), ein expliziter Pfad zu einem Socket des Vermittlers oder der Name einer Umgebungsvariablen (beginnend mit ‘$’), in der der Pfad gefunden werden kann, sein.

Die Weiterleitung des Vermittlers sollte mit Vorsicht aktiviert werden. Benutzer mit der Fähigkeit, auf dem fernen Rechner Dateiberechtigungen zu umgehen (für das Unix-Domain-Socket des Vermittlers), können über die weitergeleitete Verbindung auf den lokalen Vermittler zugreifen. Ein Angreifer kann vom Vermittler kein Schlüsselmaterial erlangen, er kann allerdings Aktionen auf den Schlüssel ausführen, die es ihm ermöglichen, sich mittels der im Vermittler geladenen Identitäten zu authentifizieren.

Gibt an, ob X11-Verbindungen automatisch über den sicheren Kanal umgeleitet werden und DISPLAY gesetzt wird. Das Argument muss yes oder no (die Vorgabe) sein.

Die X11-Weiterleitung sollte mit Vorsicht aktiviert werden. Benutzer mit der Fähigkeit, auf dem fernen Rechner Dateiberechtigungen zu umgehen (für die Autorisierungsdatenbank von X11) können auf die lokale X11-Anzeige durch die weitergeleitete Verbindung zugreifen. Ein Angreifer könnte dann in der Lage sein, Aktivitäten wie die Überwachung der Tastatureingaben durchzuführen, falls auch die Option ForwardX11Trusted aktiviert ist.

Legt eine Zeitüberschreitung für nicht vertrauenswürdige X11-Weiterleitung in dem im Abschnitt TIME FORMATS von sshd_config(5) beschriebenen Format fest. X11-Verbindungen, die von ssh(1) nach dieser Zeit empfangen werden, werden abgelehnt. Wird ForwardX11Timeout auf 0 gesetzt, dann wird die Zeitüberschreitung deaktiviert und X11-Weiterleitung für die Lebensdauer der Verbindung erlaubt. Standardmäßig wird nicht vertrauenswürdige X11-Weiterleitung nach dem Ablauf von 20 Minuten deaktiviert.
Falls diese Option auf yes (die Debian-spezifische Vorgabe) gesetzt wird, werden ferne X11-Clients Vollzugriff auf die ursprüngliche X11-Anzeige haben.

Falls diese Option auf no (die Vorgabe der Originalautoren) gesetzt ist, werden X11-Clients als nicht vertrauenswürdig betrachtet und sie daran gehindert, Daten, die zu vertrauenswürdigen X11-Clients gehören, zu stehlen oder zu verändern. Desweiteren wird das für die Sitzung verwandte Merkmal xauth(1) auf einen Ablauf nach 20 Minuten gesetzt. Fernen Clients wird danach der Zugriff verweigert.

Siehe die Spezifikation der X11-SECURITY-Erweiterungen für vollständige Details über die für nicht vertrauenswürdige Clients eingeführten Beschränkungen.

Legt fest, ob es fernen Rechnern erlaubt ist, sich mit lokal weitergeleiteten Ports zu verbinden. Standardmäßig bindet ssh(1) lokale Port-Weiterleitungen an die Loopback-Adresse an. Dies hindert andere ferne Rechner am Verbinden mit weitergeleiteten Ports. GatewayPorts kann dazu verwandt werden, anzugeben, dass Ssh lokale Port-Weiterleitungen an die Platzhalter-Adressen anbindet, und es damit fernen Rechnern erlaubt, sich mit weitergeleiteten Ports zu verbinden. Das Argument muss yes oder no (die Vorgabe) sein.
Legt eine oder mehrere, durch Leerraum getrennte Dateien fest, die als globale Schlüsseldatenbank verwandt werden sollen. Die Vorgabe ist /etc/ssh/ssh_known_hosts, /etc/ssh/ssh_known_hosts2.
Legt fest, ob die GSSAPI-basierte Benutzerauthentifizierung erlaubt ist. Die Vorgabe ist no.
Legt, falls gesetzt, die GSSAPI-Client-Identität fest, die Ssh bei Verbindungen zum Server verwenden sollte. Die Vorgabe ist »nicht gesetzt«, wodurch die Vorgabe-Identität verwandt wird.
Leitet Anmeldedaten an den Server weiter (delegieren). Die Vorgabe ist no.
Legt fest, ob ein auf GSSAPI basierendere Schlüsselaustausch durchgeführt werden darf. Bei der Verwendung des GSSAPI-Schlüsselaustausches benötigt der Server keinen Rechnerschlüssel. Die Vorgabe ist “no”.
Falls auf “yes” gesetzt, wird die Erneuerung der GSSAPI-Anmeldedaten des Clients eine Schlüsselneuaushandlung der SSH-Verbindung erzwingen. Mit einem kompatiblen Server wird dies die erneuerten Anmeldedaten an eine Sitzung des Servers delegieren.

Es erfolgen Überprüfungen, um sicherzustellen, dass die Anmeldedaten nur weitergeleitet werden, wenn die neuen Anmeldedaten auf die alten auf dem Ursprungs-Client passen und bei denen der empfangende Server immer noch den alten Satz in seinem Zwischenspeicher hat.

Die Vorgabe ist “no”.

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

Falls gesetzt gibt dies die GSSAPI-Server-Identität an, die Ssh beim Verbinden mit dem Server erwarten soll. Die Vorgabe ist »nicht gesetzt«, was bedeutet, dass die erwartete GSSAPI-Server-Identität aus dem Ziel-Rechnernamen bestimmt wird.
Auf “yes” gesetzt zeigt dies an, dass dem DNS vertraut wird, die Namen der Rechner, zu denen verbunden wird, sicher zu kanonisieren. Falls “no” wird der auf der Befehlszeile eingegebene Rechnername unverändert an die GSSAPI-Bibliothek übergeben. Die Vorgabe ist “no”.
Die Liste der möglichen Schlüsselaustauschalgorithmen, die für GSSAPI-Schlüsselaustausch angeboten werden. 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.

Zeigt an, dass ssh(1) Rechnernamen und Adressen hashen soll, wenn sie zu ~/.ssh/known_hosts hinzugefügt werden. Diese gehashten Namen können normal mit ssh(1) und sshd(8) verwandt werden, aber sie legen visuell keine kennzeichnenden Informationen offen, falls die Inhalte der Datei offengelegt werden. Die Vorgabe ist no. Beachten Sie, dass bestehende Namen und Adressen in Dateien mit bekannten Namen nicht automatisch konvertiert werden, aber manuell mittels ssh-keygen(1) gehasht werden können. Die Verwendung dieser Option könnte Einrichtungen beschädigen, die von dem Auslesen von Klartext-Rechnernamen aus ~/.ssh/known_hosts abhängen. Ein Beispiel hierfür ist die Tab-Vervollständigung.
Legt fest, ob ob asymmetrische Authentifizierung über Rhosts versucht werden soll. Das Argument muss yes oder no (die Vorgabe) sein.
Legt die für Rechner-basierte Authentifizierung zu verwendenden Schlüsseltypen als Komma-getrennte Liste von Mustern 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 ist: 
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 Option -Q von ssh(1) kann zur Anzeige unterstützter Schlüsseltypen verwandt werden.

Legt die Rechnerschlüsselalgorithmen fest, die der Client benutzen möchte (der Präferenz nach sortiert). Falls die Liste alternativ mit ‘+’ beginnt, dann werden die festgelegten Schlüsseltypen an die Vorgabemenge angehängt, statt diese zu ersetzen. Falls die festgelegte Liste mit einem ‘-’ beginnt, dann werden die festgelegten Schlüsseltypen (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt diese zu ersetzen. Falls die festgelegte Liste mit einem ‘^’ beginnt, dann werden die festgelegten Schlüsseltypen an den Anfang der Vorgabeliste gesetzt. 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

Falls die Rechnerschlüssel für den Zielrechner bekannt sind, dann wird diese Vorgabe verändert, um dessen Algorithmen zu bevorzugen.

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

Legt einen Alias fest, der statt des echten Rechnernamens beim Nachschlagen oder Speichern des Rechnerschlüssels in den Rechnerschlüsseldatenbankdateien und beim Überprüfen von Rechnerzertifikaten verwandt werden soll. Diese Option ist zum Tunneln von SSH-Verbindungen oder für mehrere Server, die auf dem gleichen Rechner laufen, nützlich.
Legt den echten Rechnernamen, bei dem angemeldet werden soll, fest. Dies kann zur Angabe von Spitznamen oder Abkürzungen für Rechner verwandt werden. Argumente für Hostname akzeptieren die im Abschnitt MERKMALE beschriebenen Merkmale. Auch numerische Adressen sind erlaubt (sowohl auf der Befehlszeile als auch in Hostname -Angaben). Die Vorgabe ist der auf der Befehlszeile übergebene Name.
Legt fest, dass ssh(1) nur die konfigurierten Authentifizierungsidentitäten und Zertifikatsdateien (entweder die Vorgabedateien oder solche, die explizit in den ssh_config -Dateien konfiguriert oder auf der Befehlszeile von ssh(1) übergeben wurden) verwenden soll, selbst falls ssh-agent(1) oder ein PKCS11Provider oder SecurityKeyProvider mehrere Identitäten anbieten. Das Argument für dieses Schlüsselwort muss yes oder no (die Vorgabe). Diese Option ist für Situationen gedacht, bei denen der Ssh-Vermittler viele verschiedene Identitäten anbietet.
Legt das zur Kommunikation mit dem Authentifizierungsvermittler verwandte UNIX-domain -Socket fest.

Diese Option setzt die Umgebungsvariable SSH_AUTH_SOCK außer Kraft und kann zur Auswahl eines bestimmten Vermittlers verwandt werden. Durch Setzen des Socket-Namens auf none wird die Verwendung des Authentifizierungsvermittlers deaktiviert. Falls die Zeichenkette "SSH_AUTH_SOCK" festgelegt wird, wird der Ort des Sockets aus der Umgebungsvariablen SSH_AUTH_SOCK gelesen. Andernfalls, falls der festgelegte Wert mit einem ‘$’ beginnt, wird er als eine Umgebungsvariable behandelt, die den Ort des Sockets enthält.

Argumente für IdentityAgent können die Tilde-Syntax zur Referenz auf das Home-Verzeichnis des Benutzers, die im Abschnitt MERKMALE beschriebenen Merkmale und die im Abschnitt UMGEBUNGSVARIABLEN beschriebenen Umgebungsvariablen verwenden.

Legt eine Datei fest, aus der die DSA-, ECDSA-, Authentifikator-basierte ECDSA-, Ed25519-, Authentifikator-basierte Ed25519- oder RSA-Authentifizierungs-Identität gelesen wird. Die Vorgabe ist ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk und ~/.ssh/id_rsa. Zusätzlich werden alle im Authentifizierungsvermittler dargestellten Identitäten für die Authentifizierung verwandt, außer IdentitiesOnly ist gesetzt. Falls durch CertificateFile keine Zertifikate explizit festgelegt wurden, wird ssh(1) versuchen, Zertifikatsinformationen aus dem Dateinamen zu erlangen, der durch Anhängen von -cert.pub an den Pfad des festgelegten IdentityFile erhalten wird.

Argumente für IdentityFile können die Tilde-Syntax zur Referenz auf das Home-Verzeichnis des Benutzers oder die im Abschnitt MERKMALE beschriebenen Merkmale verwenden.

Es ist möglich, in Konfigurationsdateien mehrere Identitäten festgelegt zu haben. Alle diese Identitäten werden nacheinander versucht. Mehrere Direktiven IdentityFile fügen zu der Liste der versuchten Identitäten hinzu (dieses Verhalten unterscheidet sich von dem anderer Konfigurationsdirektiven).

IdentityFile kann zusammen mit IdentitiesOnly verwandt werden, um auszuwählen, welche Identitäten im Vermittler während der Authentifizierung angeboten werden. IdentityFile kann auch zusammen mit CertificateFile verwandt werden, um alle Zertifikate bereitzustellen, die auch für die Authentifizierung mit der Identität benötigt werden.

Legt eine Musterliste von unbekannten Optionen fest, die ignoriert werden sollen, falls sie beim Auswerten von Konfigurationen angetroffen werden. Dies kann zur Unterdrückung von Fehlern verwandt werden, falls ssh_config Optionen enthält, die von ssh(1) nicht erkannt werden. Es wird empfohlen, dass IgnoreUnknown im Anfangsbereich der Konfigurationsdatei aufgeführt wird, da es nicht auf unbekannte Optionen angewandt wird, die davor stehen.
Bindet die festgelegten Konfigurationsdatei(en) ein. Es können mehrere Pfadnamen angegeben werden und jeder Pfadname kann glob(7) -Platzhalter enthalten und für Benutzerkonfigurationen auch Shell-artige ‘~’ -Referenzen auf Home-Verzeichnisse von Benutzern. Platzhalter werden expandiert und in lexikalischer Reihenfolge verarbeitet. Dateien ohne absoluten Pfadnamen werden im Verzeichnis ~/.ssh angenommen, falls sie Teil einer Benutzerkonfigurationsdatei sind, oder in /etc/ssh, falls sie von einer Systemkonfigurationsdatei eingebunden werden. Die Direktive Include kann innerhalb eines Match - oder Host -Blocks auftauchen, um bedingte Einbindung durchzuführen.
Legt die IPv4-Dienstetyp- oder DSCP-Klasse für Verbindungen 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 akzeptiert ein oder zwei, durch Leerraum getrennte Argumente. Falls ein Argument festgelegt ist, wird es bedingungslos als Paketklasse verwandt. Falls zwei Argumente festgelegt sind, wird das erste automatisch für interaktive Sitzungen ausgewählt und das zweite für nichtinteraktive Sitzungen. Die Vorgabe ist lowdelay für interaktive Sitzungen und throughput für nichtinteraktive Sitzungen.
Legt fest, ob interaktive Authentifizierung mit der Tastatur verwandt wird. Das Argument für dieses Schlüsselwort muss yes (die Vorgabe) oder no sein.
Legt die Liste der Methoden fest, die bei interaktiver Authentifizierung mit der Tastatur verwandt werden. Mehrere Methodennamen müssen durch Kommata getrennt werden. Die Vorgabe ist die Verwendung der vom Server festgelegten Liste. Die verfügbaren Methoden hängen von der Unterstützung durch den Server ab. Für einen OpenSSH-Server kann diese eines oder mehrere aus bsdauth und pam sein.
Legt die verfügbaren KEX- (Schlüsselaustausch-) Algorithmen fest. Mehrere Algorithmen müssen durch Kommata getrennt werden. Falls die festgelegte Liste mit einem ‘+’ beginnt, dann werden die angegebenen Methoden an die Vorgabemenge angehängt, statt diese zu ersetzen. Falls die angegebene Liste mit einem ‘-’ beginnt, dann werden die angegebenen Methoden (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen. Falls die angegebene Liste mit einem ‘^’ beginnt, dann werden die angegebenen Methoden am Anfang der Vorgabemenge abgelegt. 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 kex" erhalten werden.

Legt einen Befehl fest, der nach erfolgreicher Verbindung zum Server auf der lokalen Maschine ausgeführt werden soll. Die Befehlszeichenkette geht bis zum Zeilenende und wird in der Shell des Benutzers ausgeführt. Die Argumente von LocalCommand akzeptieren die im Abschnitt MERKMALE beschriebenen Merkmale.

Der Befehl wird synchron ausgeführt und muss keinen Zugriff auf die Sitzung von ssh(1) haben, die ihn erzeugte. Er sollte nicht für interaktive Befehle verwandt werden.

Diese Direktive wird ignoriert, außer PermitLocalCommand wurde aktiviert.

Legt fest, dass ein TCP-Port auf der lokalen Maschine über den sicheren Kanal zu dem festgelegten Rechner und Port auf der fernen Maschine weitergeleitet wird. Das erste Argument legt den auf Anfragen Wartenden fest und kann [Anbindeadresse:]Port oder ein Unix-Domain-Socket-Pfad sein. Das zweite Argument ist das Ziel und kann Rechner:Rechnerport oder ein Unix-Domain-Socket-Pfad sein, falls dies der ferne Rechner unterstützt.

IPv6-Adressen können durch Einschluss in eckige Klammern festgelegt werden. Es können mehrere Weiterleitungen festgelegt werden und zusätzliche Weiterleitungen können auf der Befehlszeile übergeben werden. Nur der Administrator kann privilegierte Ports weiterleiten. Standardmäßig ist der lokale Port gemäß der Einstellung GatewayPorts angebunden. Allerdings kann eine explizite Anbindeadresse verwandt werden, um die Verbindung an eine bestimmte Adresse anzubinden. Wird localhost als Anbindeadresse verwandt, so zeigt dies an, dass der Port, an dem auf Anfragen gewartet werden soll, nur für die lokale Verwendung angebunden ist, während eine leere Adresse oder ‘*’ anzeigt, dass der Port von allen Schnittstellen aus verfügbar sein soll. Unix-Domain-Sockets können die im Abschnitt MERKMALE beschriebenen Merkmale und die im Abschnitt UMGEBUNGSVARIABLEN beschriebenen Umgebungsvariablen verwenden.

Gibt die Ausführlichkeitsstufe an, die beim Protokollieren von Nachrichten von ssh(1) verwandt werden soll. Die möglichen Werte sind: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. Die Vorgabe ist INFO. DEBUG und DEBUG1 sind äquivalent. DEBUG2 und DEBUG3 geben jeweils eine höhere Stufe der Ausführlichkeit der Ausgabe an.
Legt die MAC- (Nachrichtenauthentifizierungscode-)Algorithmen fest, in der Reihenfolge der Präferenz. Der MAC-Algorithmus wird für den Datenintegritätsschutz verwandt. Mehrere Algorithmen müssen durch Kommata getrennt werden. Beginnt die festgelegte Liste mit einem ‘+’, dann werden die festgelegten Algorithmen an die Vorgabemenge angehängt, statt diese zu ersetzen. Beginnt die festgelegte Liste mit einem ‘-’, dann werden die festgelegten Algorithmen (einschließlich Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt diese zu ersetzen. Beginnt die festgelegte Liste mit einem ‘^’, dann werden die festgelegten Algorithmen an den Anfang der Vorgabemenge gelegt.

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

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.

Deaktiviert Rechner-basierte Authentifizierung für Localhost (Loopback-Adresse). Das Argument für dieses Schlüsselwort muss yes oder no (die Vorgabe) sein.
Legt die Anzahl der Passworteingabeaufforderungen fest, bevor aufgegeben wird. Das Argument für dieses Schlüsselwort muss eine Ganzzahl sein. Die Vorgabe ist 3.
Legt fest, ob Passwort-Authentifizierung verwandt werden soll. Das Argument für dieses Schlüsselwort muss yes (die Vorgabe) oder no sein.
Erlaubt die Ausführung lokaler Befehle mittels der Option LocalCommand oder mittels der Maskiersequenz !Befehl in ssh(1). Das Argument muss yes oder no (die Vorgabe) sein.
Legt fest, welcher PKCS#11-Anbieter verwandt werden soll oder none (die Vorgabe), dass kein Anbieter verwandt werden soll. Das Argument für dieses Schlüsselwort ist ein Pfad zu einer dynamischen PKCS#11-Bibliothek, die ssh(1) zur Kommunikation mit einem PKCS#11-Token verwenden soll, der Schlüssel für die Benutzerauthentifizierung bereitstellt.
Legt die Nummer des Ports fest, mit dem auf dem fernen Rechner verbunden werden soll. Die Vorgabe ist 22.
Legt die Reihenfolge fest, in der die Clients Authentifizierungsmethoden ausprobieren sollen. Dies erlaubt es Clients, eine bestimmte Methode (z.B. keyboard-interactive) gegenüber anderen Methoden (z.B. password) zu bevorzugen. Die Vorgabe lautet: 
gssapi-with-mic,hostbased,publickey,
keyboard-interactive,password
Legt den für Verbindungen zum Server zu verwendenden Befehl fest. Die Befehlszeichenkette geht bis zum Zeilenende und wird mittels der ‘exec’ -Direktive der Shell des Benutzers ausgeführt, um einen schleppenden Shell-Prozess zu vermeiden.

Argumente für ProxyCommand akzeptieren die im Abschnitt MERKMALE beschriebenen Merkmale. Der Befehl kann im Prinzip alles sein, und sollte von seiner Standardeingabe einlesen und zur Standardausgabe schreiben. Er sollte sich schließlich mit einem sshd(8) -Server verbinden, der auf irgendeiner Maschine läuft, oder sshd -i irgendwo ausführen. Die Schlüsselverwaltung erfolgt mittels des Hostname des Rechners, zu dem verbunden wird (standardmäßig der Name, den der Benutzer eingegeben hat). Durch Setzen des Befehl auf none wird diese Option komplett deaktiviert. Beachten Sie, dass CheckHostIP für Verbindungen mit einem Proxy-Befehl nicht verfügbar ist.

Diese Direktive ist im Zusammenspiel mit nc(1) und seiner Proxy-Unterstützung nützlich. Die folgende Direktive würde sich beispielsweise mittels eines HTTP-Proxys zu 192.0.2.0 verbinden:

ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
Legt einen oder mehrere Sprung-Proxys als entweder [Benutzer@]Rechner[:Port] oder als eine SSH-URI fest. Mehrere Proxys können durch Kommata getrennt werden. Diese werden der Reihe nach besucht. Durch Setzen dieser Option wird sich ssh(1) mit dem Zielrechner verbinden, indem es zuerst eine ssh(1) -Verbindung zu dem festgelegten ProxyJump -Rechner aufbaut und dann eine TCP-Weiterleitung zu dem endgültigen Ziel von dort aus aufbaut.

Beachten Sie, dass diese Option im Wettstreit mit der Option ProxyCommand steht - die zuerst angegebene wird die nachfolgende nicht wirksam werden lassen.

Beachten Sie auch, dass die Konfiguration für den Zielrechner (entweder auf der Befehlszeile übergeben oder aus der Konfigurationsdatei) im Allgemeinen für Sprung-Rechner nicht angewandt wird. Verwenden Sie ~/.ssh/config, falls für den Sprungrechner spezielle Konfiguration notwendig ist.

Legt fest, dass ProxyCommand einen verbundenen Dateideskriptor an ssh(1) zurückgeben wird, statt weiter auszuführen und Daten zu übergeben. Die Vorgabe ist no.
Legt die Schlüsseltypen als Kommata-getrennte Liste von Mustern fest, die für asymmetrische Authentifizierung verwandt werden sollen. Falls die festgelegte Liste mit einem ‘+’ beginnt, dann werden die danach festgelegten Schlüsseltypen an die Vorgabemenge angehängt, statt diese zu ersetzen. Falls die festgelegte Liste mit einem ‘-’ 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 ‘^’ beginnt, dann werden die festgelegten Schlüsseltypen am Anfang der Vorgabemenge abgelegt. 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.

Legt fest, ob asymmetrische Authentifizierung versucht werden soll. Das Argument für dieses Schlüsselwort muss yes (die Vorgabe) oder no sein.
Legt die maximale Menge an Daten fest, die übetragen werden dürfen, bevor der Sitzungsschlüssel neu ausgehandelt wird. Optional kann eine maximale Zeitdauer angehängt werden, die vergehen darf, bevor der Sitzungsschlüssel neu ausgehandelt wird. Das erste Argument wird in Bytes angegeben und darf die Endungen ‘K’ (für Kilobyte), ‘M’ (für Megabyte) oder ‘G’ (für Gigabyte) tragen. 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 TIME FORMATS von sshd_config(5) angegebenen Einheiten verwenden. Der Vorgabewert für RekeyLimit ist default none. Dies bedeutet, dass Schlüsselneuaushandlung durchgeführt wird, wenn die Vorgabemenge der Chiffre von Daten gesandt oder empfangen wurde und keine zeitbasierte Schlüsselneuaushandlung erfolgt.
Legt einen Befehl fest, der nach erfolgreicher Anmeldung am Server auf der fernen Maschine ausgeführt werden soll. Die Befehlszeichenkette geht bis zum Zeilenende und wird mit der Shell des Benutzers ausgeführt. Argumente für RemoteCommand akzeptieren die im Abschnitt MERKMALE beschriebenen Merkmale.
Legt fest, dass ein TCP-Port auf der fernen Maschine über den sicheren Kanal weitergeleitet wird. Der ferne Port kann entweder zu einem festgelegten Rechner und Port von der lokalen Maschine weitergeleitet werden oder er kann als SOCKS-4/5-Proxy agieren, der es einem fernen Client erlaubt, sich zu beliebigen Zielen von der lokalen Maschine zu verbinden. Das erste Argument ist die Festlegung für das Warten auf Anfragen. Dieses kann entweder [Anbindeadresse:]Port oder ein Unix-Domain-Socketpfad sein, falls der ferne Rechner dies unterstützt. Falls zu einem bestimmten Ziel weitergeleitet wird, dann muss das zweite Argument Rechner:Rechnerport oder ein Unix-Domain-Socketpfad sein. Andernfalls wird das ferne Weiterleiten als ein SOCKS-Proxy realisiert, falls kein Zielargument festgelegt ist.

Durch Einschluss der Adresse in eckigen Klammern werden IPv6-Adressen festgelegt. Mehrere Weiterleitungen können festgelegt werden und zusätzliche Weiterleitungen können auf der Befehlszeile übergeben werden. Privilegierte Ports können nur nach Anmeldung als root auf der fernen Maschine weitergeleitet werden. Unix-Domain-Socketpfade können die im Abschnitt MERKMALE beschriebenen Merkmale und die im Abschnitt UMGEBUNGSVARIABLEN beschriebenen Umgebungsvariablen verwenden.

Falls das Argument Port 0 ist, dann wird der Port, an dem auf Anfragen gewartet wird, dynamisch vom Server zugewiesen und dem Client zur Laufzeit übermittelt.

Falls die Anbindeadresse nicht festgelegt ist, dann wird standardmäßig nur an die Loopback-Adresse angebunden. Falls die Anbindeadresse ‘*’ oder die leere Zeichenkette ist, dann wird die Weiterleitung gebeten, auf allen Schnittstellen auf Anfragen zu warten. Die Festlegung einer fernen Anbindeadresse wird nur erfolgreich sein, falls die Option GatewayPorts des Servers aktiviert ist (siehe sshd_config(5)).

Legt fest, ob ein Pseudo-TTY für die Sitzung erbeten werden soll. Das Argument kann entweder no (niemals ein TTY erbeten), yes (immer ein TTY erbeten, wenn die Standardeingabe ein TTY ist), force (immer ein TTY erbeten) oder auto (ein TTY erbeten, wenn eine Anmeldesitzung eröffnet wird) sein. Diese Option spiegelt die Schalter -t und -T von ssh(1).
Legt gesperrte öffentliche Rechnerschlüssel fest. Bei denen in dieser Datei aufgeführten Schlüsseln wird Rechner-Authentifizierung abgelehnt. Beachten Sie, dass Rechner-Authentifizierung für alle Rechner abgelehnt wird, falls diese Datei nicht existiert oder nicht lesbar ist. Schlüssel müssen als Textdatei festgelegt werden, wobei ein öffentlicher Schlüssel pro Zeile aufgeführt wird, oder als eine OpenSSH-Schlüsselsperrliste (KRL), wie sie von ssh-keygen(1) erstellt wird. Für weitere Informationen über KRLs lesen Sie den Abschnitt SCHLÜSSELSPERRLISTEN in ssh-keygen(1).
Gibt einen Pfad zu einer Bibliothek an, die beim Laden jedes FIDO-Authentifikator-basierten Schlüssels verwandt wird. Dies setzt die standardmäßige, eingebaute USB-HID-Unterstützung außer Kraft.

Falls der festgelegte Wert mit einem ‘$’ beginnt, dann wird er als Umgebungsvariable behandelt, die den Pfad zu der Bibliothek enthält.

Legt fest, welche Variablen von der lokalen environ(7) zum Server gesendet werden sollen. Der Server muss dies unterstützen und zu deren Empfang konfiguriert sein. Beachten Sie, dass die Umgebungsvariable TERM immer gesandt wird, wenn ein Pseudo-Terminal erbeten wird, da sie vom Protokoll benötigt wird. Zur Konfiguration des Servers lesen Sie AcceptEnv in sshd_config(5). Variablen werden durch den Namen festgelegt und können Platzhalterzeichen enthalten. Mehrere Umgebungsvariablen können durch Leerraum getrennt oder über mehrere SendEnv -Direktiven verteilt werden.

Siehe MUSTER für weitere Informationen über Muster.

Vorher gesetzte SendEnv -Variablen können zurückgesetzt werden, indem ihnen - vorangestellt wird. Standardmäßig werden keine Umgebungsvariablen gesandt.

Setzt die Anzahl der (nachfolgend beschriebenen) Lebensmeldungen, die gesendet werden können, ohne dass ssh(1) eine Nachricht vom Server zurück erhält. Falls diese Schwelle erreicht wird, während die Lebensmeldungen des Servers gesandt werden, wird Ssh die Verbindung zum Server trennen und die Sitzung beenden. Es ist wichtig anzumerken, dass der Einsatz der Lebensmeldungen sich sehr von TCPKeepAlive (siehe unten) unterscheidet. Die Server-Lebensmeldungen werden durch den verschlüsselten Kanal übersandt und können daher nicht gefälscht werden. Die mittels TCPKeepAlive aktivierte TCP-Keepalive-Option kann gefälscht werden. Der Server-Lebensmechanismus ist wertvoll, wenn der Client oder Server davon abhängen, zu wissen, wann die Verbindung aufhörte, zu reagieren.

Der Vorgabewert ist 3. Falls beispielsweise ServerAliveInterval (siehe unten) auf 15 gesetzt ist und ServerAliveCountMax auf der Vorgabe verbleibt, dann wird Ssh nach ca. 45 Sekunden die Verbindung trennen, falls der Server nicht mehr reagiert.

Setzt ein Zeitüberschreitungsintervall in Sekunden, nach der ssh(1) eine Nachricht durch den verschlüsselten Kanal senden und um eine Reaktion vom Server bitten wird, falls keine Daten vom Server empfangen wurden. Die Vorgabe ist 0, was anzeigt, dass diese Nachrichten nicht an den Server gesandt werden, oder 300, falls die Option BatchMode gesetzt ist (Debian-spezifisch). ProtocolKeepAlives und SetupTimeOut sind Debian-spezifische Kompatibilitäts-Aliase für diese Option.
Legt das Senden von einer oder mehrerer Umgebungsvariablen und ihren Inhalt an den Server direkt fest. Ähnlich zu SendEnv muss der Server bereit sein, Umgebungsvariablen zu akzeptieren.
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 entfernt werden soll, bevor eine neue erstellt wird. Falls die Socket-Datei bereits existiert und StreamLocalBindUnlink nicht aktiviert ist, wird ssh nicht in der Lage sein, den Port zu der Unix-Domain-Socket-Datei weiterzuleiten. Diese Option wird nur für Port-Weiterleitungen zu einer Unix-Domain-Socket-Datei verwandt.

Das Argument muss yes oder no (die Vorgabe) sein.

Falls dieser Schalter auf yes gesetzt ist, wird ssh(1) niemals automatisch Rechnerschlüssel zu der Datei ~/.ssh/known_hosts hinzufügen und es ablehnen, sich zu Rechnern zu verbinden, deren Rechner-Schlüssel sich geändert hat. Dies bietet einen maximalen Schutz gegen Man-in-the-middle- (MITM-)Angriffe. Es kann aber auch nervend sein, wenn die Datei /etc/ssh/ssh_known_hosts schlecht gepflegt wird oder wenn häufig Verbindungen zu neuen Rechnern erfolgen. Diese Option zwingt den Benutzer, alle neuen Rechner manuell hinzuzufügen.

Falls dieser Schalter auf “accept-new” gesetzt ist, dann wird Ssh neue Rechnerschlüssel automatische zu den Dateien der bekannten Rechner der Benutzer hinzufügen, wird aber keine Verbindungen zu Rechnern mit geänderten Rechnerschlüsseln erlauben. Falls dieser Schalter auf “no” oder “off” gesetzt ist, wird Ssh automatisch neue Rechnerschlüssel zu den Dateien der bekannten Rechner der Benutzer hinzufügen und mit dem Aufbau von Verbindungen zu Rechnern, deren Rechnerschlüssel sich geändert hat, fortfahren, allerdings unter ein paar Einschränkungen. Falls dieser Schalter auf ask (die Vorgabe) gesetzt ist, werden neue Rechnerschlüssel zu den Dateien der bekannten Rechner der Benutzer erst hinzugefügt, wenn der Benutzer bestätigt hat, dass er dies wirklich möchte. Auch wird Ssh Verbindungen zu Rechnern verweigern, deren Rechnerschlüssel sich geändert hat. Die Rechnerschlüssel aller bekannten Rechner werden automatisch in allen Fällen überprüft.

Gibt den Code der Einrichtung an, die beim Protokollieren von Nachrichten durch ssh(1) verwandt wird. Die möglichen Werte sind: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. Die Vorgabe ist USER.
Legt fest, ob das System TCP-Keepalive-Meldungen zu der anderen Seite senden soll. Falls diese gesandt werden, wird der Tod der Verbindung oder der Absturz einer der beiden Maschinen korrekt bemerkt. Diese Option verwendet nur TCP-Keepalives (im Gegensatz zur Verwendung von Keepalives auf Ebene von SSH), und benötigt daher eine längere Zeit, um den Absturz von Verbindungen zu erkennen. Daher möchten Sie wahrscheinlich auch die Option ServerAliveInterval verwenden. Allerdings bedeutet dies, dass die Verbindung abstürzt, falls die Route temporär nicht existiert und einige Leute finden das nervend.

Die Vorgabe ist yes (TCP-Keepalive-Meldungen senden) und der Client wird es bemerken, wenn das Netzwerk ausfällt oder der ferne Rechner stirbt. Dies ist für Skripte wichtig, und viele Benutzer möchten es ebenfalls.

Um TCP-Keepalive-Meldungen zu deaktivieren, sollte der Wert auf no gesetzt werden. Siehe auch ServerAliveInterval für Keepalives auf Protokoll-Ebene.

Erbittet die tun(4) -Geräteweiterleitung zwischen dem Client und dem Server. Das Argument muss yes, point-to-point (Layer 3), ethernet (Layer 2) oder no (die Vorgabe) sein. Festlegung von yes erbittet den Standard-Tunnelmodus ( point-to-point).
Legt die auf dem Client (lokaler_Tun) und dem Server (ferner_Tun) zu öffnenden tun(4) -Geräte fest.

Das Argument muss lokaler_Tun[:ferner_Tun] sein. Die Geräte können über die numerische Kennung oder das Schlüsselwort any, das das nächste verfügbare Tunnel-Gerät verwendet, festgelegt sein. Falls ferner_Tun nicht festgelegt ist, ist die Vorgabe any. Die Vorgabe ist any:any.

Legt fest, ob ssh(1) Benachrichtigungen vom Server über zusätzliche Rechnerschlüssel akzeptieren soll, die gesandt werden, nachdem die Authentifizierung abgeschlossen wurde, und diese dann zu UserKnownHostsFile hinzufügen soll. Das Argument muss yes, no oder ask sein. Diese Option erlaubt das Kennenlernen alternativer Rechnerschlüssel für einen Server und unterstützt taktvolle Schlüsselrotation, indem dem Server ermöglicht wird, den Ersatz für den öffentlichen Schlüssel zu senden, bevor die alten entfernt werden. Zusätzliche Rechnerschlüssel werden nur akzeptiert, falls dem zur Authentifizierung verwandten Schlüssel bereits vertraut oder dieser vom Benutzer explizit akzeptiert wurde.

UpdateHostKeys ist standardmäßig aktiviert, falls der Benutzer nicht die Vorgabeeinstellung UserKnownHostsFile außer Kraft gesetzt hat. Andernfalls wird UpdateHostKeys auf ask gesetzt.

Falls UpdateHostKeys auf ask gesetzt ist, wird der Benutzer um Bestätigungen bei Veränderungen an der Datei »known_hosts« gebeten. Bestätigungen sind derzeit mit ControlPersist inkompatibel und werden deaktiviert, falls das aktiviert ist.

Derzeit unterstützen nur sshd(8) von OpenSSH 6.8 und neuere die "hostkeys@openssh.com" -Protokollerweiterung für die Information der Clients über alle Rechnerschlüssel des Servers.

Legt den Benutzernamen fest, der bei der Anmeldung verwandet werden soll. Dies kann nützlich sein, wenn sich der Benutzername auf verschiedenen Maschinen unterscheidet. Dies erspart den Aufwand, daran zu denken, den Benutzernamen auf der Befehlszeile anzugeben.
Legt eine oder mehrere, durch Leerraum getrennte, Dateien fest, die für die Rechnerschlüsseldatenbank des Benutzer verwandt werden sollen. Jeder Dateiname kann die Tilde-Notation, um sich auf das Home-Verzeichnis des Benutzers zu beziehen, die im Abschnitt MERKMALE beschriebenen Merkmale und die im Abschnitt UMGEBUNGSVARIABLEN beschriebenen Umgebungsvariablen verwenden. Die Vorgabe ist ~/.ssh/known_hosts, ~/.ssh/known_hosts2.
Legt fest, ob der ferne Schlüssel mittels DNS- und SSHFP-Ressourcen-Datensätzen verifiziert werden soll. Falls diese Option auf yes gesetzt ist, wird der Client implizit Schlüsseln vertrauen, die auf einen sicheren Fingerabdruck aus dem DNS passen. Unsichere Fingerabdrücke werden so gehandhabt, als ob die Option auf ask gesetzt worden wäre. Falls diese Option auf ask gesetzt ist, werden Informationen über Fingerabruck-Übereinstimmungen angezeigt, aber der Benutzer muss dennoch den neuen Rechnerschlüssel gemäß der Option StrictHostKeyChecking bestätigen. Die Vorgabe ist no.

Siehe auch RECHNERSCHLÜSSEL ÜBERPRÜFEN in ssh(1).

Falls dieser Schalter auf yes gesetzt ist, wird eine ASCII-Darstellung des Fingerabdrucks des fernen Rechners zusätzlich zur Zeichenkette mit dem Fingerabdruck selbst bei der Anmeldung und bei unbekannten Rechnerschlüsseln angezeigt. Falls dieser Schalter auf no (die Vorgabe) gesetzt ist, werden keine Fingerabdruck-Zeichenketten beim Anmelden angezeigt und die Fingerabdruck-Zeichenkette wird nur für unbekannte Rechnerschlüssel dargestellt.
Legt den vollständigen Pfadnamen des Programms xauth(1) fest. Die Vorgabe ist /usr/bin/xauth.

Ein besteht aus keinem oder mehreren, von Leerraum verschiedenen Zeichen, ‘*’ (einem Platzhalter, der auf keines odere mehrere Zeichen passt) und ‘?’ (einem Platzhalter, der auf genau ein Zeichen passt). Um beispielsweise eine Gruppe von Deklarationen für alle Rechner in der Menge der ".co.uk" -Domains festzulegen, könnte folgendes Muster verwandt werden:

Host *.co.uk

Das folgende Muster würde auf jeden Rechner in dem Netzwerkbereich 192.168.0.[0-9] passen:

Host 192.168.0.?

Eine ist eine durch Kommata getrennte Liste von Mustern. Muster innerhalb von Musterlisten können negiert werden, indem ihnen ein Anführungszeichen (‘!’) vorangestellt wird. Um beispielsweise einem Schlüssel zu erlauben, von überall innerhalb der Organisation, außer aus dem "dialup" -Bereich verwandt zu werden, könnte folgender Eintrag (in »authorized_keys«) verwandt werden:

from="!*.dialup.example.com,*.example.com"

Beachten Sie, dass ein negierter Treffer niemals selbst positive Ergebnisse erzeugen wird. Wird beispielsweise versucht, "host3" mit der folgenden Musterliste zu vergleichen, so wird dies fehlschlagen:

from="!host1,!host2"

Die Lösung besteht darin, einen Ausdruck aufzunehmen, der zu einem positiven Vergleich führt, wie z.B. mit einem Platzhalter:

from="!host1,!host2,*"

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

%%
Ein wörtliches ‘%’.
%C
Hash von %l%h%p%r.
%d
Das lokale Home-Verzeichnis des Benutzers.
%h
Der ferne Rechnername.
%i
Die lokale Benutzerkennung.
%k
Der Rechnerschlüssel-Alias, falls festgelegt, andernfalls der ursprünglich auf der Befehlszeile übergebene ferne Rechnername.
%L
Der lokale Rechnername.
%l
Der lokale Rechnername, einschließlich des Domain-Namens.
%n
Der ursprüngliche ferne Rechnername, wie auf der Befehlszeile übergeben.
%p
Der ferne Port.
%r
Der ferne Benutzername.
%T
Die zugewiesene lokale tun(4) - oder tap(4) -Netzwerkschnittstelle, falls Tunnel-Weiterleitung erbeten wurde. Andernfalls "NONE".
%u
Der lokale Benutzername.

CertificateFile, ControlPath, IdentityAgent, IdentityFile, LocalForward, Match exec, RemoteCommand, RemoteForward und UserKnownHostsFile akzeptieren die Merkmale %%, %C, %d, %h, %i, %L, %l, %n, %p, %r und %u.

Hostname akzeptiert die Merkmale %% und %h.

LocalCommand akzeptiert alle Merkmale.

ProxyCommand akzeptiert die Merkmale %%, %h, %n, %p und %r.

Argumente für einige Schlüsselwörter können zur Laufzeit aus Umgebungsvariablen auf dem Client expandiert werden, indem sie in ${} eingeschlossen werden. Beispielsweise würde sich ${HOME}/.ssh auf das .ssh-Verzeichnis des Benutzers beziehen. Falls eine festgelegte Umgebungsvariable nicht existiert, wird ein Fehler zurückgeliefert und die Einstellung für dieses Schlüsselwort wird ignoriert.

Die Schlüsselwörter CertificateFile, ControlPath, IdentityAgent, IdentityFile und UserKnownHostsFile unterstützen Umgebungsvariablen. Die Schlüselwörter LocalForward und RemoteForward unterstützen Umgebungsvariablen nur für Unix-Domain-Socket-Pfade.

~/.ssh/config
Dies ist die benutzerbezogene Konfigurationsdatei. Das Format dieser Datei ist weiter oben beschrieben. Diese Datei wird vom SSH-Client verwandt. Aufgrund der Gefahr des Missbrauchs muss diese Datei strengen Berechtigungen unterliegen: Lesen/Schreiben für den Benutzer und nicht schreibbar für andere. Sie darf durch die Gruppe beschreibbar sein, falls die in Frage kommende Gruppe nur den Bnutzer enthält.
/etc/ssh/ssh_config
Systemweite Konfigurationsdatei. Diese Datei stellt Vorgaben für die Werte bereit, die in der Konfigurationsdatei des Benutzers nicht festgelegt sind, und für die Benutzer, die keine Konfigurationsdatei haben. Die Datei muss für alle lesbar sein.

ssh(1)

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.

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: 11. August 2020 $ Debian