Provided by: manpages-de_4.26.0-1_all 
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)
Falls nicht anders angegeben wird für jeden Parameter 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, localnetwork, host, originalhost, tagged, 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.
Das Schlüsselwort localnetwork vergleicht die Adressen der aktiven lokalen Netzwerkschnittstellen
mit der bereitgestellten List von Netzwerken im CIDR-Format. Dies kann zur Überprüfung der
effektiven Konfiguration von Geräten, die sich zwischen Netzwerken hin- und herbewegen, nützlich
sein. Beachten Sie, dass eine Netzwerkadresse in vielen Situationen kein vertrauenswürdiges
Kriterium ist (z.B. wenn das Netzwerk automatisch mittels DHCP konfiguriert wird). Daher sollte
Vorsicht walten gelassen werden, falls dies zur Steuerung sicherheitsrelevanter Konfiguration
verwandt wird.
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 tagged passt auf den Markierungsnamen, der durch eine vorhergehende
Direktive Tag oder auf der Befehlszeile von ssh(1) mittels des Schalters -P 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 “ZEITFORMATE” 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.
ChannelTimeout
Gibt an, ob und wie schnell ssh(1) inaktive Kanäle schließen soll. Zeitüberschreitungen werden
als ein oder mehrere »Typ=Intervall«-Paare getrennt durch Leerraum angegeben, wobei »Typ« das
besondere Schlüsselwort »global« oder ein Kanaltypname aus der nachfolgenden Liste sein muss, der
optional Joker-Zeichen enthalten darf.
Der Zeitüberschreitungswert »interval« wird in Sekunden angegeben oder kann eine der im Abschnitt
“ZEITFORMATE” dokumentierten Einheiten verwenden. Beispielsweise würde »session=5m« dazu führen,
dass inaktive Sitzungen nach 5 Minuten Inaktivität beendet würden. Durch Angabe des Wertes Null
wird die Inaktivitätszeitüberschreitung deaktiviert.
Das besondere Schlüsselwort »global« gilt für alle aktiven Kanäle zusammengenommen. Verkehr auf
einem der aktiven Kanäle wird die Zeitüberschreitung zurücksetzen, aber wenn die
Zeitüberschreitung abläuft, dann werden alle offenen Kanäle geschlossen. Beachten Sie, dass diese
globale Zeitüberschreitung nicht mit Platzhalterzeichen übereinstimmt und explizit konfiguriert
werden muss.
Zu den verfügbaren Kanaltypnamen gehören:
agent-connection
Offene Verbindungen zu ssh-agent(1).
direct-tcpip, direct-streamlocal@openssh.com
Offene TCP- bzw. Unix-Socket-Verbindungen, die von einer lokalen Weiterleitung eines
ssh(1) etabliert wurden, d.h. LocalForward oder DynamicForward.
forwarded-tcpip, forwarded-streamlocal@openssh.com
Offene TCP- bzw. Unix-Socket-Verbindungen, die zu einem sshd(8) etabliert wurden, der im
Auftrag einer fernen Weiterleitung eines ssh(1) auf Anfragen warten, d.h. RemoteForward.
session
Die interaktive Hauptsitzung, einschließlich der Shell-Sitzung, Befehlsausführung,
scp(1), sftp(1), usw.
tun-connection
Offene TunnelForward -Verbindungen.
x11-connection
Offene X11-Weiterleitungssitzungen.
Beachten Sie, dass in allen obigen Fällen die Beendigung einer inaktiven Sitzung nicht
garantiert, dass alle der Sitzung zugeordnete Ressourcen entfernt werden, z.B. könnten Shell-
Prozesse oder X11-Clients mit Bezug zu der Sitzung weiterhin ausgeführt werden.
Desweiteren schließt das Beenden eines inaktiven Kanals oder einer inaktiven Sitzung nicht
notwendigerweise die SSH-Verbindung noch verhindert es einen Client daran, einen weiteren Kanal
des gleichen Typs anzufragen. Insbesondere verhindert das Ablaufen einer inaktiven Sitzung nicht,
dass eine andere, identische Weiterleitung nachfolgend erstellt wird.
Standardmäßig läuft kein Kanal irgendeines Typs aufgrund von Inaktivität ab.
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. SetupTimeOut ist ein Debian-spezifischer
Kompatibilitäts-Alias für diese Option.
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.
EnableEscapeCommandline
Aktiviert die Befehlszeilenoption in dem Menü EscapeChar für interaktive Sitzungen (standardmäßig
‘~C’). Standardmäßig ist die Befehlszeile deaktiviert.
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
“ZEITFORMATE” 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 ECDSA-, Authentifikator-basierte ECDSA-, Ed25519-,
Authentifikator-basierte Ed25519- oder RSA-Authentifizierungs-Identität gelesen wird. Sie können
auch eine öffentliche Schlüsseldatei festlegen, um den entsprechenden privaten Schlüssel zu
verwenden, der in ssh-agent(1) geladen ist, wenn die private Schlüsseldatei lokal nicht vorhanden
ist. Die Vorgabe ist ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 und
~/.ssh/id_ed25519_sk. 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. Alternativ kann ein
Argument none verwandt werden, um anzuzeigen, dass keine Identitätsdatei geladen werden soll.
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, Merkmale, wie im Abschnitt “MERKMALE” beschrieben,
Umgebungsvariablen, wie im Abschnitt “UMGEBUNGSVARIABLEN” beschrieben, 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 erlaubten KEX- (Schlüsselaustausch-) Algorithmen, die verwandt werden, und ihre
bevorzugte Reihenfolge fest. Der ausgewählte Algorithmus wird der erst Algorithmus aus dieser
Liste sein, die der Server unterstützt. 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,sntrup761x25519-sha512@openssh.com,
mlkem768x25519-sha256,
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 unterstützten 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 oder mehrerer Musterlisten, 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.
ObscureKeystrokeTiming
Legt fest, ob ssh(1) versuchen soll, den zeitlichen Ablauf von Tastaturanschlägen gegenüber
passiven Beobachtern des Netzwerkverkehrs zu verschleiern. Falls aktiviert, dann wird ssh(1) bei
interaktiven Sitzungen die Tastaturanschläge in festen Zeitintervallen von wenigen zehn
Mikrosekunden senden und fingierte Tastaturanschlagspakete einige Zeit nachdem das Tippen
aufhört. Das Argument für dieses Schlüsselwort muss yes, no oder ein Intervallkennzeichner der
Form interval:Millisekunden (z.B. interval:80 für 80 Millisekunden) sein. Standardmäßig werden
Tastaturanschläge mittels eines 20 ms Paketintervalls verschleiert. Beachten Sie, dass kleinere
Intervalle zu höheren Paketraten fingierter Tastaturanschläge führen werden.
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:
ssh-ed25519-cert-v01@openssh.com,
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
sk-ssh-ed25519-cert-v01@openssh.com,
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,
rsa-sha2-256-cert-v01@openssh.com,
ssh-ed25519,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ssh-ed25519@openssh.com,
sk-ecdsa-sha2-nistp256@openssh.com,
rsa-sha2-512,rsa-sha2-256
Die Liste der verfügbaren Signaturalgorithmen kann auch mittels "ssh -Q 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 oder empfangen 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).
RequiredRSASize
Legt die minimale RSA-Schlüsselgröße (in Bit) fest, die ssh(1) akzeptieren wird. Benutzer-
Authentifizierungsschlüssel, die kleiner als diese Begrenzung sind, werden ignoriert. Server, die
rechnerbasierte Schlüssel präsentieren, die kleiner als diese Begrenzung sind, führen dazu, dass
die Verbindung beendet wird. Die Vorgabe ist 1024 bit. Beachten Sie, dass diese Beschränkung von
der Vorgabe her nur angehoben werden kann.
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). Argumente für RevokedHostKeys können die Tilde-Syntax verwenden, um sich auf
das Home-Verzeichnis eines Benutzer, den im Abschnitt “MERKMALE” beschriebenen Merkmalen und den
in Abschnitt “UMGEBUNGSVARIABLEN” beschriebenen Umgebungsvariablen zu beziehen.
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 ist eine Debian-spezifischer Kompatibilitäts-Alias 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.
Tag Gibt ein Konfigurationsmerkmalnamen an, der später über eine Direktive Match zur Auswahl eines
Konfigurationsblocks verwandt werden kann.
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. Der Wert none führt dazu, dass ssh(1) alle benutzerspezifischen Dateien bekannter
Rechner ignoriert. 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%j.
%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.
%j Der Inhalt der Option ProxyJump oder die leere Zeichenkette, falls diese Option nicht gesetzt
ist.
%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, Include, KnownHostsCommand, LocalForward,
Match exec, RemoteCommand, RemoteForward, RevokedHostKeys und UserKnownHostsFile akzeptieren die Merkmale
%%, %C, %d, %h, %i, %j, %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 und ProxyJump akzeptieren die Merkmale %%, %h, %n, %p und %r.
Beachten Sie, dass einige dieser Direktiven Befehle zur Ausführung mittels der Shell zusammenbauen. Da
ssh(1) kein Filtern oder Maskieren der Zeichen, die eine besondere Bedeutung für Shell-Befehle haben
(z.B. Anführungszeichen), durchführt, unterliegt es der Verantwortung des Benutzer sicherzustellen, dass
die an ssh(1) übergebenen Argumente solche Zeichen nicht enthalten und das Merkmale entsprechend beim
Einsatz maskiert sind.
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, Include, 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 .
Debian 9. September, 2024 SSH_CONFIG(5)