Ubuntu Manpage: ssh_config — OpenSSH-Client-Konfigurationsdatei

BEZEICHNUNG

     ssh_config — OpenSSH-Client-Konfigurationsdatei

BESCHREIBUNG

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:

• Include /etc/ssh/ssh_config.d/*.conf
• SendEnv LANG LC_*
• HashKnownHosts yes
• GSSAPIAuthentication yes

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

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

Match 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 fordert, 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).

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

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

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

BindAddress
Verwendet die festgelegte Adresse auf der lokalen Maschine als Quelladresse der
Verbindung. Nur für Systeme mit mehr als einer Adresse nützlich.

BindInterface
Verwendet die Adresse der festgelegten Schnittstelle auf der lokalen Maschine als
die Quelladresse der Verbindung.

CanonicalDomains
Diese Option gibt die Liste der Domain-Endungen an, in denen nach den angegeben
Ziel-Rechnern gesucht werden soll, wenn CanonicalizeHostname aktiviert ist.

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

CanonicalizeHostname
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. Der Wert none deaktiviert die
Verwendung des ProxyJump -Rechners.

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

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

Ein einzelnes Argument "none" führt dazu, dass keine CNAMEs für die Kanonisierung
berücksichtigt werden. Dies ist das Standardverhalten.

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

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

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

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

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

CheckHostIP
Falls auf yes 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 (die Vorgabe) gesetzt ist, wird die
Prüfung nicht durchgeführt.

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

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

Compression
Legt fest, ob Kompression verwandt wird. Das Argument muss entweder yes oder no (die
Vorgabe) sein.

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

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

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

ControlPath
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 deaktivieren, 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.

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

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

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

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

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

FingerprintHash
Legt den Hash-Algorithmus fest, der bei der Anzeige der Fingerabdrücke verwandt
wird. Gültige Optionen sind md5 und sha256 (die Vorgabe).

ForkAfterAuthentication
Bittet ssh direkt vor der Ausführung des Befehls in den Hintergrund zu gehen. Dies
ist nützlich, falls ssh nach Passwörtern oder Passphrasen fragen wird, aber der
Benutzer es im Hintergrund möchte. Dies impliziert, dass die Konfigurationsoption
StdinNull auf “yes” gesetzt ist. Die empfohlene Art, X-Programme auf einem fernen
Rechner zu starten, ist etwas wie ssh -f Rechner xterm, was identisch zu ssh Rechner
xterm ist, falls die Konfigurationsoption ForkAfterAuthentication auf “yes” gesetzt
ist.

Falls die Konfigurationsoption ExitOnForwardFailure auf “yes” gesetzt ist, dann wird
ein Client, bei dem die Konfigurationsoption ForkAfterAuthentication auf “yes”
gesetzt ist, darauf warten, dass alle fernen Port-Weiterleitungen erfolgreich
etabliert wurden, bevor er sich selbst in den Hintergrund bringt. Das Argument für
dieses Schlüsselwort muss yes (identisch zu der Option -f) oder no (die Vorgabe)
sein.

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

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

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

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

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

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

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

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

GSSAPIDelegateCredentials
Leitet Anmeldedaten an den Server weiter (delegieren). Die Vorgabe ist no.

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

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

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

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

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

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

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

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

Die Option -Q von ssh(1) kann zur Anzeige unterstützter Signaturalgorithmen verwandt
werden. Dies wurde früher HostbasedKeyTypes genannt.

HostbasedAuthentication
Legt fest, ob ob asymmetrische Authentifizierung über Rhosts versucht werden soll.
Das Argument muss yes oder no (die Vorgabe) sein.

HostKeyAlgorithms
Legt die Rechnerschlüsselsignaturalgorithmen fest, die der Client benutzen möchte
(der Präferenz nach sortiert). Falls die Liste alternativ mit »+« beginnt, dann
werden die festgelegten Signaturalgorithmen an die Vorgabemenge angehängt, statt
diese zu ersetzen. Falls die festgelegte Liste mit einem »-« beginnt, dann werden
die festgelegten Signaturalgorithmen (einschließlich Platzhalter-Zeichen) aus der
Vorgabemenge entfernt, statt diese zu ersetzen. Falls die festgelegte Liste mit
einem »^« beginnt, dann werden die festgelegten Signaturalgorithmen an den Anfang
der Vorgabeliste gesetzt. Die Vorgabe für diese Option lautet:

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

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 Signaturalgorithmen kann auch mittels "ssh -Q
HostKeyAlgorithms" erhalten werden.

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

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

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

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

IdentityFile
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_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk,
~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk und ~/.ssh/id_dsa. 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.

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

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

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

KbdInteractiveAuthentication
Legt fest, ob interaktive Authentifizierung mit der Tastatur verwandt wird. Das
Argument für dieses Schlüsselwort muss yes (die Vorgabe) oder no sein.
ChallengeResponseAuthentication ist ein veralteter Alias hierfür.

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

KexAlgorithms
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 Algorithmen an die Vorgabemenge
angehängt, statt diese zu ersetzen. Falls die angegebene Liste mit einem »-«
beginnt, dann werden die angegebenen Algorithmen (einschließlich Platzhalter-
Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen. Falls die angegebene
Liste mit einem »^« beginnt, dann werden die angegebenen Algorithmen am Anfang der
Vorgabemenge abgelegt. Die Vorgabe ist:

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

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

KnownHostsCommand
Legt einen Befehl fest, der zum Erlangen des Rechnerschlüssels verwandt werden soll,
zusätzlich zu den in UserKnownHostsFile und GlobalKnownHostsFile aufgeführten.
Dieser Befehl wird ausgeführt, nachdem diese Dateien gelesen wurden. Er kann
Rechnerschlüsselzeilen auf die Standardausgabe schreiben, in einem Format, das
identisch zu gewöhnlichen Dateien ist (beschrieben im Abschnitt RECHNERSCHLÜSSEL
ÜBERPRÜFEN in ssh(1)). Argumente für KnownHostsCommand akzeptieren die in MERKMALE
beschriebenen Merkmale. Dieser Befehl kann mehrfach pro Verbindung aufgerufen
werden; einmal bei der Vorbereitung der Vorzugsliste der zu verwendenden
Rechnerschlüsselalgorithmen, dann wieder, um den Rechnerschlüssel für den
angeforderten Rechnernamen zu erlangen und, falls CheckHostIP aktiviert ist, noch
einmal, um den Rechnerschlüssel zu erlangen, der auf die Adresse des Servers passt.
Falls der Befehl sich nicht normal beendet oder ein von Null verschiedenen Exit-
Status zurückliefert, wird die Verbindung beendet.

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

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

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

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

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

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

MACs Legt die 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.

NoHostAuthenticationForLocalhost
Deaktiviert Rechner-basierte Authentifizierung für Localhost (Loopback-Adresse). Das
Argument für dieses Schlüsselwort muss yes oder no (die Vorgabe) sein.

NumberOfPasswordPrompts
Legt die Anzahl der Passworteingabeaufforderungen fest, bevor aufgegeben wird. Das
Argument für dieses Schlüsselwort muss eine Ganzzahl sein. Die Vorgabe ist 3.

PasswordAuthentication
Legt fest, ob Passwort-Authentifizierung verwandt werden soll. Das Argument für
dieses Schlüsselwort muss yes (die Vorgabe) oder no sein.

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

PermitRemoteOpen
Legt das Ziel fest, zu dem TCP-Port-Weiterleitung erlaubt ist, wenn RemoteForward
als SOCKS-Proxy verwandt wird. Die Weiterleitungsfestlegung muss eine der folgenden
Formen annehmen:

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

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

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

Port Legt die Nummer des Ports fest, mit dem auf dem fernen Rechner verbunden werden
soll. Die Vorgabe ist 22.

PreferredAuthentications
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

ProxyCommand
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

ProxyJump
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. Durch Setzen des Rechners auf none wird diese Option komplett
deaktiviert.

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.

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

PubkeyAcceptedAlgorithms
Legt die Signaturalgorithmen 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 Algorithmen an die
Vorgabemenge angehängt, statt diese zu ersetzen. Falls die festgelegte Liste mit
einem »-« beginnt, dann werden die festgelegten Algorithmen (einschließlich
Platzhalter-Zeichen) aus der Vorgabemenge entfernt, statt sie zu ersetzen. Falls die
festgelegte Liste mit einem »^« beginnt, dann werden die festgelegten Algorithmen am
Anfang der Vorgabemenge abgelegt. Die Vorgabe für diese Option lautet:

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

PubkeyAuthentication
Legt fest, ob asymmetrische Authentifizierung versucht werden soll. Das Argument
dieses Schlüsselwortes muss yes (die Vorgabe), no, unbound oder host-bound sein. Die
letzteren zwei Optionen aktivieren asymmetrische Authentifizierung bei
gleichzeitiger Deaktivierung bzw. Aktivierung der rechnergebundenen
Authentifizierungsprotokollerweiterung von OpenSSH, die zur Beschränkung der
ssh-agent(1) -Weiterleitung benötigt wird.

RekeyLimit
Legt die maximale Menge an Daten fest, die übetragen werden dürfen, bevor der
Sitzungsschlüssel neu ausgehandelt wird. Optional kann eine maximale Zeitdauer
anhä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.

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

RemoteForward
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. Wird als SOCKS-Proxy
agiert, dann kann das Ziel der Verbindung mittels PermitRemoteOpen eingeschränkt
werden.

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

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

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

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

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

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

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

SessionType
Kann zur Erbitten eines Subsystems auf dem fernen Rechner oder zur kompletten
Verhinderung eines fernen Befehlsaufrufs verwandt werden. Letzteres ist nützlich, um
nur Ports weiterzuleiten. Das Argument für dieses Schlüsselwort muss none (wie bei
der Option -N), subsystem (wie bei der Option -s) oder default (Shell oder
Befehlsausführung) sein.

SetEnv Legt das Senden von einer oder mehrerer Umgebungsvariablen und ihren Inhalt an den
Server direkt fest. Ähnlich zu SendEnv, mit Ausnahme der Variable TERM, muss der
Server bereit sein, Umgebungsvariablen zu akzeptieren.

StdinNull
Leitet Stdin von /dev/null um (verhindert tatsächlich das Lesen von Stdin). Entweder
dies oder die äquivalente Option -n muss verwandt werden, wenn ssh im Hintergrund
ausgeführt wird. Das Argument für dieses Schlüsselwort muss yes (wie bei der Option
-n) oder no (die Vorgabe) sein.

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

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

StreamLocalBindUnlink
Legt fest, ob eine bestehende Unix-Domain-Socket-Datei für lokale oder ferne Port-
Weiterleitung 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.

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

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

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

Tunnel Fordert die tun(4) -Geräteweiterleitung zwischen dem Client und dem Server an. Das
Argument muss yes, point-to-point (Layer 3), ethernet (Layer 2) oder no (die
Vorgabe) sein. Festlegung von yes fordert den Standard-Tunnelmodus ( point-to-point)
an.

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

UpdateHostKeys
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
des Rechners verwandten Schlüssel bereits vertraut oder dieser vom Benutzer explizit
akzeptiert wurde, der Rechner mittels UserKnownHostsFile (d.h. nicht
GlobalKnownHostsFile) authentifiziert wurde und der Rechner mittels einfachem
Schlüssel und nicht einem Zertifikat authentifiziert wurde.

UpdateHostKeys ist standardmäßig aktiviert, falls der Benutzer nicht die
Vorgabeeinstellung UserKnownHostsFile außer Kraft gesetzt und nicht VerifyHostKeyDNS
aktiviert hat. Andernfalls wird UpdateHostKeys auf no 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.

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

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

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

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

XAuthLocation
Legt den vollständigen Pfadnamen des Programms xauth(1) fest. Die Vorgabe ist
/usr/bin/xauth.

MUSTER

     Ein Muster 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 Musterliste 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,*"

MERKMALE

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.
%f Der Fingerabdruck des Rechnerschlüssels des Servers.
%H Der known_hosts Rechnername oder Adresse, nach der gesucht wird.
%h Der ferne Rechnername.
%I Eine Zeichenkette, die den Grund für eine KnownHostsCommand -Ausführung
beschreibt: entweder ADDRESS, bei der Suche nach einem Rechner über die Adresse
(nur wenn CheckHostIP aktiviert ist), HOSTNAME, bei der Suche über Rechnernamen
oder ORDER, bei der Vorbereitung der Liste der bevorzugten Rechnerschlüssel-
Algorithmen, die für den Zielrechner verwandt werden soll.
%i Die lokale Benutzerkennung.
%K Der Base64-kodierte Rechnerschlüssel.
%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".
%t Die Art des Server-Rechner-Schlüssels, z.B. ssh-ed25519.
%u Der lokale Benutzername.

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

KnownHostsCommand akzeptiert zusätzlich die Merkmale %f, %H, %I, %K und %t.

Hostname akzeptiert die Merkmale %% und %h.

LocalCommand akzeptiert alle Merkmale.

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

UMGEBUNGSVARIABLEN

     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,
     KnownHostsCommand und UserKnownHostsFile unterstützen Umgebungsvariablen. Die Schlüselwörter
     LocalForward und RemoteForward unterstützen Umgebungsvariablen nur für Unix-Domain-Socket-
     Pfade.

DATEIEN

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

SIEHE AUCH

     ssh(1)

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.

ÜBERSETZUNG

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

     Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version
     3: https://www.gnu.org/licenses/gpl-3.0.html oder neuer bezüglich der Copyright-Bedingungen.
     Es wird KEINE HAFTUNG übernommen.

     Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
     Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org .