So konfigurieren Sie benutzerdefinierte Verbindungsoptionen für Ihren SSH-Client

Einführung

SSH oder Secure Shell ist die häufigste Methode, um eine Verbindung zu Linux-Hosts für die Remoteverwaltung herzustellen. Obwohl die Grundlagen für das Herstellen einer Verbindung zu einem einzelnen Host oft recht einfach sind, kann dies unhandlich und eine viel kompliziertere Aufgabe werden, wenn Sie mit einer großen Anzahl von Remotesystemen arbeiten.

Glücklicherweise können Sie mit OpenSSH benutzerdefinierte clientseitige Verbindungsoptionen bereitstellen. Diese können in einer Konfigurationsdatei gespeichert werden, in der Werte pro Host definiert werden können. Dies kann dazu beitragen, die verschiedenen Verbindungsoptionen, die Sie für jeden Host verwenden, getrennt und organisiert zu halten und Sie daran zu hindern, umfangreiche Optionen in der Befehlszeile bereitzustellen, wenn Sie eine Verbindung herstellen müssen.

In diesem Handbuch werden die Grundlagen der SSH-Client-Konfigurationsdatei erläutert und einige allgemeine Optionen erläutert.

Voraussetzungen

Um dieses Handbuch zu vervollständigen, benötigen Sie Kenntnisse über SSH und einige der Optionen, die Sie beim Herstellen einer Verbindung bereitstellen können. Möglicherweise möchten Sie auch die SSH-Schlüssel-basierte Authentifizierung für einige Ihrer Benutzer oder Hosts konfigurieren, zumindest zu Testzwecken.

Der SSH-Konfigurationsdateistruktur- und Interpretationsalgorithmus

Jeder Benutzer auf Ihrem lokalen System kann eine clientseitige SSH-Konfigurationsdatei verwalten. Diese können alle Optionen enthalten, die Sie in der Befehlszeile zum Angeben von Verbindungsparametern verwenden würden. Auf diese Weise können Sie Ihre allgemeinen Verbindungselemente speichern und sie automatisch bei der Verbindung verarbeiten. Es ist immer möglich, die zum Zeitpunkt der Verbindung in der Konfigurationsdatei definierten Werte durch normale Flags zum Befehl + ssh + zu überschreiben.

Der Speicherort der SSH-Client-Konfigurationsdatei

Die clientseitige Konfigurationsdatei heißt "+ config " und befindet sich im Ausgangsverzeichnis Ihres Benutzers im Konfigurationsverzeichnis " .ssh +". Häufig wird diese Datei nicht standardmäßig erstellt, daher müssen Sie sie möglicherweise selbst erstellen:

touch ~/.ssh/config

Struktur der Konfigurationsdatei

Die + config + Datei ist nach Hosts organisiert. Jede Hostdefinition kann Verbindungsoptionen für den jeweiligen passenden Host definieren. Platzhalter sind ebenfalls verfügbar, um Optionen zuzulassen, die einen breiteren Bereich haben sollten.

Jeder Abschnitt beginnt mit einem Header, der die Hosts definiert, die den folgenden Konfigurationsoptionen entsprechen sollen. Die spezifischen Konfigurationselemente für diesen passenden Host werden nachfolgend definiert. Es müssen nur Elemente angegeben werden, die von den Standardwerten abweichen, da der Host die Standardwerte für nicht definierte Elemente übernimmt. Ein Abschnitt wird vom Header "+ Host " bis zum folgenden Header " Host +" definiert.

Aus organisatorischen Gründen und zur besseren Lesbarkeit werden die für jeden Host festgelegten Optionen eingerückt. Dies ist keine zwingende Voraussetzung, sondern eine nützliche Konvention, die eine einfachere Interpretation auf einen Blick ermöglicht.

Das allgemeine Format sieht ungefähr so ​​aus:

Host




Host


Host


Host *

Hier haben wir vier Abschnitte, die bei jedem Verbindungsversuch angewendet werden, je nachdem, ob der betreffende Host übereinstimmt.

Interpretationsalgorithmus

Es ist sehr wichtig zu verstehen, wie SSH die Datei interpretiert, um die darin definierten Konfigurationswerte anzuwenden. Dies hat große Auswirkungen auf die Verwendung von Platzhaltern und der generischen Hostdefinition "+ Host * +".

SSH vergleicht den in der Befehlszeile angegebenen Hostnamen mit jedem der "+ Host" -Header, die Konfigurationsabschnitte definieren. Dies geschieht von oben nach unten, daher ist die Reihenfolge unglaublich wichtig.

Dies ist ein guter Zeitpunkt, um darauf hinzuweisen, dass die Muster in der "+ Host +" - Definition nicht mit dem tatsächlichen Host übereinstimmen müssen, mit dem Sie eine Verbindung herstellen werden. Sie können diese Definitionen im Wesentlichen verwenden, um Aliase für Hosts einzurichten, die anstelle des tatsächlichen Hostnamens verwendet werden können.

Betrachten Sie zum Beispiel diese Definition:

Host devel
   HostName devel.example.com
   User tom

Dieser Host ermöglicht es uns, eine Verbindung als "+ tom @ devel.example.com +" herzustellen, indem wir Folgendes in die Befehlszeile eingeben:

ssh devel

Vor diesem Hintergrund können wir nun diskutieren die Art und Weise, in der SSH jede Konfigurationsoption gilt, da es die Datei bewegt sich nach unten. Es beginnt oben und überprüft jede "+ Host +" - Definition, um festzustellen, ob sie mit dem in der Befehlszeile angegebenen Wert übereinstimmt.

Wenn die erste übereinstimmende "+ Host +" - Definition gefunden wird, wird jede der zugeordneten SSH-Optionen auf die bevorstehende Verbindung angewendet. Die Interpretation endet hier jedoch nicht.

SSH verschiebt die Datei dann nach unten und prüft, ob auch andere + Host + - Definitionen übereinstimmen. Wenn eine andere Definition gefunden wird, die mit dem in der Befehlszeile angegebenen aktuellen Hostnamen übereinstimmt, werden die mit dem neuen Abschnitt verknüpften SSH-Optionen berücksichtigt. Es werden dann alle SSH-Optionen angewendet, die für den neuen Abschnitt definiert wurden, die * nicht bereits in vorherigen Abschnitten definiert wurden *.

Dieser letzte Punkt ist äußerst wichtig für die Internalisierung. SSH interpretiert jeden der "+ Host +" - Abschnitte, die dem in der Befehlszeile angegebenen Hostnamen entsprechen, in der angegebenen Reihenfolge. Während dieses Vorgangs wird immer der erste Wert verwendet, der für jede Option angegeben wurde. Es gibt keine Möglichkeit, einen Wert zu überschreiben, der bereits von einem zuvor übereinstimmenden Abschnitt angegeben wurde.

Das bedeutet, dass Ihre "+ config +" - Datei der einfachen Regel folgen sollte, dass die spezifischsten Konfigurationen oben stehen. Allgemeinere Definitionen sollten später erfolgen, um Optionen anzuwenden, die in den vorherigen übereinstimmenden Abschnitten nicht definiert wurden.

Schauen wir uns noch einmal die Modelldatei "+ config +" an, die wir im letzten Abschnitt verwendet haben:

Host




Host


Host


Host *

Hier können wir sehen, dass die ersten beiden Abschnitte durch wörtliche Hostnamen (oder Aliase) definiert sind, was bedeutet, dass sie keine Platzhalter verwenden. Wenn wir eine Verbindung mit + ssh firsthost + herstellen, wird der allererste Abschnitt zuerst angewendet. Dadurch werden für diese Verbindung "+ SSH_OPTION_1 ", " SSH_OPTION_2 " und " SSH_OPTION_3 +" festgelegt.

Es überprüft den zweiten Abschnitt und stellt fest, dass er nicht übereinstimmt und fährt fort. Es findet dann den dritten Abschnitt und stellt fest, dass er übereinstimmt. Es wird "+ ANOTHER_OPTION " überprüft, um festzustellen, ob es bereits einen Wert für diesen aus den vorherigen Abschnitten enthält. Wenn Sie feststellen, dass dies nicht der Fall ist, wird der Wert aus diesem Abschnitt angewendet. Es stimmt dann mit dem letzten Abschnitt überein, da die " Host * " - Definition mit jeder Verbindung übereinstimmt. Da es keinen Wert für die Scheinoption " CHANGE_DEFAULT +" aus anderen Abschnitten gibt, wird der Wert aus diesem Abschnitt übernommen. Die Verbindung wird dann mit den aus diesem Prozess gesammelten Optionen hergestellt.

Versuchen wir es noch einmal und geben vor, "+ ssh secondhost +" von der Kommandozeile aus aufzurufen.

Wieder beginnt es mit dem ersten Abschnitt und prüft, ob es passt. Da dies nur einer Verbindung zu "+ firsthost " entspricht, wird dieser Abschnitt übersprungen. Es wird mit dem zweiten Abschnitt fortgefahren. Wenn festgestellt wird, dass dieser Abschnitt mit der Anforderung übereinstimmt, wird der Wert von " ANOTHER_OPTION +" für diese Verbindung erfasst.

SSH überprüft dann die dritte Definition und stellt fest, dass der Platzhalter mit der aktuellen Verbindung übereinstimmt. Es wird dann geprüft, ob es bereits einen Wert für "+ ANOTHER_OPTION +" hat. Da diese Option im zweiten Abschnitt definiert wurde, der bereits abgeglichen wurde, wird der Wert aus dem dritten Abschnitt gelöscht und hat keine Auswirkung.

SSH überprüft dann den vierten Abschnitt und wendet die Optionen an, die nicht durch zuvor übereinstimmende Abschnitte definiert wurden. Anschließend versucht es die Verbindung mit den gesammelten Werten herzustellen.

Grundlegende Verbindungsoptionen

Nachdem Sie sich ein Bild über das allgemeine Format gemacht haben, das Sie beim Entwerfen Ihrer Konfigurationsdatei verwenden sollten, wollen wir einige allgemeine Optionen und das Format erläutern, in dem sie in der Befehlszeile angegeben werden sollen.

Die ersten, die wir behandeln, sind die grundlegenden Informationen, die zum Herstellen einer Verbindung zu einem Remote-Host erforderlich sind. Der Hostname, der Benutzername und der Port, auf dem der SSH-Dämon ausgeführt wird.

Um als Benutzer mit dem Namen "+ apollo " eine Verbindung zu einem Host mit dem Namen " example.com " herzustellen, auf dem der SSH-Daemon über den Port " 4567 +" über die Befehlszeile ausgeführt wird, können Sie die variablen Informationen auf verschiedene Arten angeben. Das häufigste wäre wahrscheinlich:

ssh -p 4567 [email protected]

Wir könnten jedoch auch die vollständigen Optionsnamen mit dem Flag "+ -o +" verwenden, wie folgt:

ssh -o "User=apollo" -o "Port=4567" -o "HostName=example.com" anything

Hier haben wir alle Optionen festgelegt, die wir mit dem + -o + Flag verwenden möchten. Wir haben sogar den Host als "irgendetwas" als Alias ​​angegeben, so wie wir es in der Konfigurationsdatei könnten, wie wir es oben beschrieben haben. Der tatsächliche Hostname wird aus der von uns eingestellten Option "+ Hostname +" übernommen.

Die großgeschriebenen Optionsnamen, die wir im zweiten Formular verwenden, sind die gleichen, die wir in unserer + config + - Datei verwenden müssen. Sie finden eine vollständige Liste der verfügbaren Optionen, indem Sie Folgendes eingeben:

man ssh_config

Um diese in unserer + config + - Datei festzulegen, müssen wir zuerst entscheiden, für welche Hosts diese Optionen verwendet werden sollen. Da wir Optionen diskutieren, die für den betreffenden Host spezifisch sind, sollten wir wahrscheinlich eine wörtliche Host-Übereinstimmung verwenden.

Wir haben an dieser Stelle auch die Möglichkeit, einen Alias ​​für diese Verbindung zu vergeben. Lassen Sie uns dies nutzen, damit wir nicht jedes Mal den gesamten Hostnamen eingeben müssen. Wir werden den Alias ​​"home" verwenden, um auf diese Verbindung und die damit verbundenen Optionen zu verweisen:

Host home

Jetzt können wir die Verbindungsdetails für diesen Host definieren. Wir können das zweite Format verwenden, das wir oben verwendet haben, um uns darüber zu informieren, was wir in diesen Abschnitt einfügen sollen.

Host home
   HostName example.com
   User apollo
   Port 4567

Wir definieren Optionen mit einem Schlüsselwertsystem. Jedes Paar sollte sich in einer separaten Zeile befinden. Schlüssel können entweder durch Leerzeichen oder durch ein Gleichheitszeichen mit optionalem Leerzeichen von den zugehörigen Werten getrennt werden. Somit sind diese alle identisch wie von unserem SSH-Client interpretiert:

Port 4567
Port=4567
Port = 4567

Der einzige Unterschied besteht darin, dass Sie bei Verwendung des Gleichheitszeichens ohne Leerzeichen in Abhängigkeit von der Option und dem Wert eine Option in der Befehlszeile angeben können, ohne sie in Anführungszeichen zu setzen. Da wir uns auf unsere + config + - Datei konzentrieren, liegt dies ganz bei Ihren Vorlieben.

Gemeinsame Optionen konfigurieren

Bisher ist die von uns entworfene Konfiguration unglaublich einfach. In seiner Gesamtheit sieht es so aus:

Host home
   HostName example.com
   User apollo
   Port 4567

Was ist, wenn wir auf unseren Arbeits- und Heimcomputern denselben Benutzernamen verwenden? Wir könnten redundante Optionen mit unserem Abschnitt hinzufügen, der die Arbeitsmaschine wie folgt definiert:

Host home
   HostName example.com
   User apollo
   Port 4567

Host work
   HostName company.com
   User apollo

Das funktioniert, aber wir wiederholen Werte. Dies ist nur eine einzelne Option, es ist also keine große Sache, aber manchmal möchten wir eine große Anzahl von Optionen gemeinsam nutzen. Der beste Weg, dies zu tun, besteht darin, die gemeinsam genutzten Optionen in separate Abschnitte aufzuteilen.

Wenn wir auf allen Maschinen, mit denen wir eine Verbindung herstellen, den Benutzernamen "apollo" verwenden, können wir diesen in unsere generische "Host" -Definition aufnehmen, die durch ein einzelnes "+ * +" gekennzeichnet ist, das zu jeder Verbindung passt. Denken Sie daran, dass die allgemeineren Abschnitte weiter unten liegen sollten:

Host home
   HostName example.com
   Port 4567

Host work
   HostName company.com

Host *
   User apollo

Dies behebt das Problem der Wiederholung in unserer Konfiguration und funktioniert, wenn "apollo" Ihr Standardbenutzername für die meisten neuen Systeme ist, mit denen Sie eine Verbindung herstellen.

Was ist, wenn es Systeme gibt, die diesen Benutzernamen nicht verwenden? Es gibt verschiedene Möglichkeiten, wie Sie dies angehen können, je nachdem, wie häufig der Benutzername geteilt wird.

Wenn der "apollo" -Nutzername für fast alle Ihre Hosts verwendet wird, ist es wahrscheinlich am besten, ihn im allgemeinen Abschnitt "+ Host * +" zu belassen. Dies gilt für alle Hosts, die keinen Benutzernamen aus den obigen Abschnitten erhalten haben. Für unsere anomalen Maschinen, die einen anderen Benutzernamen verwenden, können wir den Standardwert durch Angabe einer Alternative überschreiben. Dies hat Vorrang, solange es vor dem generischen Abschnitt definiert ist:

Host home
   HostName example.com
   Port 4567

Host work
   HostName company.com

Host oddity
   HostName weird.com
   User zeus

Host *
   User apollo

Für den Host "+ oddity " stellt SSH eine Verbindung mit dem Benutzernamen "zeus" her. Alle anderen Verbindungen erhalten ihren Benutzernamen erst, wenn sie die generische " Host * +" - Definition erreicht haben.

Was passiert, wenn der "apollo" -Nutzername von einigen Verbindungen geteilt wird, aber nicht häufig genug ist, um als Standardwert verwendet zu werden? Wenn wir bereit sind, die von uns verwendeten Aliase umzubenennen, um ein allgemeineres Format zu verwenden, können wir nur diesen beiden Hosts mit einem Platzhalter zusätzliche Optionen zuweisen.

Wir können den Alias ​​"+ home " in " hapollo " und die Arbeitsverbindung in " wapollo " ändern. Auf diese Weise teilen sich beide Hosts den " apollo +" - Teil ihres Alias ​​und können ihn mit Platzhaltern in einem anderen Bereich ausrichten:

Host hapollo
   HostName example.com
   Port 4567

Host wapollo
   HostName company.com

Host *apollo
   User apollo

Host *
   User diffdefault

Hier haben wir die geteilte "+ User " - Definition in einen Hostabschnitt verschoben, der SSH-Verbindungen entspricht, die versuchen, eine Verbindung zu Hosts herzustellen, die mit " apollo " enden. Jede Verbindung, die nicht mit " apollo " endet (und keine eigene " Host " - Sektion hat, die einen " User" definiert), erhält den Benutzernamen "+ diff default".

Beachten Sie, dass wir die Reihenfolge in unserer Datei von der spezifischsten bis zur am wenigsten spezifischen Reihenfolge beibehalten haben. Es ist am besten, weniger spezifische Host-Abschnitte als Ausweichmanöver zu betrachten als Standardeinstellungen, die auf die Reihenfolge zurückzuführen sind, in der die Datei interpretiert wird.

Allgemeine SSH-Konfigurationsoptionen

Bisher haben wir einige der grundlegenden Optionen erörtert, die zum Herstellen einer Verbindung erforderlich sind. Wir haben diese Optionen abgedeckt:

  • * Hostname *: Der tatsächliche Hostname, der zum Herstellen der Verbindung verwendet werden soll. Dadurch werden alle im Header "+ Host " definierten Aliasnamen ersetzt. Diese Option ist _nicht_ erforderlich, wenn die ` Host +` - Definition den tatsächlich gültigen Hostnamen angibt, zu dem eine Verbindung hergestellt werden soll.

  • * Benutzer *: Der Benutzername, der für die Verbindung verwendet werden soll.

  • * Port *: Der Port, auf dem der Remote-SSH-Dämon ausgeführt wird. Diese Option ist nur erforderlich, wenn die Remote-SSH-Instanz nicht auf dem Standardport "+ 22 +" ausgeführt wird.

Es gibt viele andere nützliche Optionen, die es wert sind, erkundet zu werden. Wir werden einige der gebräuchlichsten Optionen diskutieren, die nach Funktionen getrennt sind.

Allgemeine Änderungen und Verbindungselemente

Einige andere Verbesserungen, die Sie möglicherweise allgemein konfigurieren möchten, beispielsweise im Abschnitt "+ Host * +", sind unten aufgeführt.

  • * + ServerAliveInterval + *: Diese Option kann so konfiguriert werden, dass SSH weiß, wann ein Paket gesendet werden muss, um auf eine Antwort vom Server zu testen. Dies kann nützlich sein, wenn Ihre Verbindung unzuverlässig ist und Sie wissen möchten, ob sie noch verfügbar ist.

  • * + LogLevel + *: Hiermit wird der Detaillierungsgrad konfiguriert, in dem sich SSH auf der Clientseite anmeldet. Dies kann zum Deaktivieren der Protokollierung in bestimmten Situationen oder zum Erhöhen der Ausführlichkeit beim Debuggen verwendet werden. Die Levels sind von am wenigsten bis am ausführlichsten QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG1, DEBUG2 und DEBUG3.

  • * + StrictHostKeyChecking + *: Mit dieser Option wird konfiguriert, ob SSH jemals automatisch Hosts zur Datei + ~ / .ssh / known_hosts + hinzufügt. Standardmäßig ist dies auf "ask" gesetzt, was bedeutet, dass Sie gewarnt werden, wenn der vom Remote-Server empfangene Host-Schlüssel nicht mit dem in der Datei "+ known_hosts +" gefundenen übereinstimmt. Wenn Sie ständig eine Verbindung zu einer großen Anzahl von kurzlebigen Hosts herstellen, können Sie dies auf "Nein" setzen. SSH fügt dann automatisch alle Hosts zur Datei hinzu. Dies kann Auswirkungen auf die Sicherheit haben. Überlegen Sie daher sorgfältig, bevor Sie es aktivieren.

  • * + UserKnownHostsFile + *: Diese Option gibt den Speicherort an, an dem SSH die Informationen zu den Hosts speichert, mit denen eine Verbindung hergestellt wurde. Normalerweise müssen Sie sich keine Gedanken über diese Einstellung machen, aber Sie können dies auf "+ / dev / null +" setzen, wenn Sie die strikte Host-Prüfung oben deaktiviert haben.

  • * + VisualHostKey + *: Mit dieser Option wird SSH angewiesen, beim Verbindungsaufbau eine ASCII-Darstellung des Schlüssels des Remote-Hosts anzuzeigen. Wenn Sie diese Option aktivieren, können Sie sich auf einfache Weise mit dem Schlüssel Ihres Hosts vertraut machen. So können Sie ihn leicht erkennen, wenn Sie zu einem späteren Zeitpunkt eine Verbindung von einem anderen Computer aus herstellen müssen.

  • * + Komprimierung + *: Das Aktivieren der Komprimierung kann bei sehr langsamen Verbindungen hilfreich sein. Die meisten Benutzer werden dies nicht benötigen.

In Anbetracht der obigen Konfigurationselemente können wir eine Reihe nützlicher Konfigurationsänderungen vornehmen.

Wenn wir beispielsweise Hosts bei einem Cloud-Anbieter sehr schnell erstellen und löschen, kann Folgendes hilfreich sein:

Host home
   VisualHostKey yes

Host cloud*
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel QUIET

Host *
   StrictHostKeyChecking ask
   UserKnownHostsFile ~/.ssh/known_hosts
   LogLevel INFO
   ServerAliveInterval 120

Dadurch wird Ihr visueller Host-Schlüssel für Ihre Heimverbindung aktiviert, sodass Sie sich mit ihm vertraut machen können, damit Sie erkennen können, ob er sich ändert oder wenn Sie eine Verbindung von einem anderen Computer herstellen. Wir haben auch alle Hosts eingerichtet, die mit Cloud * beginnen, um Hosts nicht zu überprüfen und Fehler nicht zu protokollieren. Für andere Hosts haben wir vernünftige Fallback-Werte.

Verbindungsweiterleitung

Eine häufige Verwendung von SSH ist das Weiterleiten von Verbindungen, indem entweder eine lokale Verbindung über den Remotehost getunnelt wird oder der Remotecomputerzugriff über den lokalen Computer getunnelt wird. SSH kann auch dynamische Weiterleitungen mithilfe von Protokollen wie SOCKS5 durchführen, die die Weiterleitungsinformationen für den Remote-Host enthalten.

Folgende Optionen steuern dieses Verhalten:

  • * + LocalForward + *: Diese Option wird verwendet, um eine Verbindung anzugeben, die den Datenverkehr eines lokalen Ports an den Remotecomputer weiterleitet und ihn an das Remotenetzwerk weiterleitet. Das erste Argument sollte der lokale Port sein, an den Sie den Datenverkehr leiten möchten, und das zweite Argument sollte die Adresse und der Port sein, an den Sie den Datenverkehr auf der Remote-Seite leiten möchten.

  • * + RemoteForward + *: Mit dieser Option wird ein Remote-Port definiert, an den Datenverkehr geleitet werden kann, um den lokalen Computer auszutunneln. Das erste Argument sollte der Remote-Port sein, über den der Datenverkehr auf das Remote-System geleitet wird. Das zweite Argument sollte die Adresse und der Port sein, auf die der Datenverkehr beim Eintreffen auf dem lokalen System verweisen soll.

  • * + DynamicForward + *: Hiermit wird ein lokaler Port konfiguriert, der mit einem dynamischen Weiterleitungsprotokoll wie SOCKS5 verwendet werden kann. Der Datenverkehr, der das dynamische Weiterleitungsprotokoll verwendet, kann dann auf diesen Port auf dem lokalen Computer und auf dem entfernten Ende geleitet werden. Er wird gemäß den enthaltenen Werten weitergeleitet.

Diese Optionen können verwendet werden, um Ports in beide Richtungen weiterzuleiten, wie Sie hier sehen können:

# This will allow us to use port 8080 on the local machine
# in order to access example.com at port 80 from the remote machine
Host local_to_remote
   LocalForward 8080 example.com:80

# This will allow us to offer access to internal.com at port 443
# to the remote machine through port 7777 on the other side
Host remote_to_local
   RemoteForward 7777 internal.com:443

Andere Weiterleitung

Neben der Verbindungsweiterleitung ermöglicht SSH auch andere Weiterleitungstypen.

Wir können alle SSH-Schlüssel, die in einem Agenten auf unserem lokalen Computer gespeichert sind, weiterleiten. Auf diese Weise können wir vom fernen System aus eine Verbindung herstellen, indem wir die auf unserem lokalen System gespeicherten Anmeldeinformationen verwenden. Wir können Anwendungen auch auf einem Remote-System starten und die grafische Anzeige mithilfe der X11-Weiterleitung an unser lokales System weiterleiten.

Dies sind die Anweisungen, die mit diesen Funktionen verknüpft sind:

  • * + ForwardAgent + *: Mit dieser Option können auf unserem lokalen Computer gespeicherte Authentifizierungsschlüssel an das System weitergeleitet werden, zu dem Sie eine Verbindung herstellen. Auf diese Weise können Sie mit Ihren Home-Schlüsseln von Host zu Host springen.

  • * + ForwardX11 + *: Wenn Sie einen grafischen Bildschirm einer auf dem Remote-System ausgeführten Anwendung weiterleiten möchten, können Sie diese Option aktivieren.

Diese beiden Optionen sind "Ja" oder "Nein".

Schlüssel angeben

Wenn für Ihre Hosts SSH-Schlüssel konfiguriert sind, können Sie mithilfe dieser Optionen verwalten, welche Schlüssel für die einzelnen Hosts verwendet werden sollen.

  • * + IdentityFile + *: Mit dieser Option kann der Speicherort des Schlüssels angegeben werden, der für jeden Host verwendet werden soll. Befinden sich Ihre Schlüssel an den Standardpositionen, wird jeder ausprobiert, und Sie müssen dies nicht anpassen. Wenn Sie eine Reihe von Schlüsseln haben, die jeweils unterschiedlichen Zwecken dienen, können Sie hiermit den genauen Pfad angeben, unter dem der richtige Schlüssel gefunden werden kann.

  • * + IdentitiesOnly + *: Mit dieser Option kann SSH gezwungen werden, sich nur auf die in der + config + - Datei angegebenen Identitäten zu verlassen. Dies kann erforderlich sein, wenn ein SSH-Agent alternative Schlüssel im Speicher hat, die für den betreffenden Host nicht gültig sind.

Diese Optionen sind besonders nützlich, wenn Sie eine große Anzahl von Schlüsseln für verschiedene Hosts verwalten und einen oder mehrere SSH-Agenten zur Unterstützung verwenden müssen.

Multiplexing von SSH über eine einzelne TCP-Verbindung

SSH bietet die Möglichkeit, eine einzelne TCP-Verbindung für mehrere SSH-Verbindungen zu demselben Hostcomputer zu verwenden. Dies kann nützlich sein, wenn es eine Weile dauert, bis ein TCP-Handshake zum Remote-Ende hergestellt ist, da dieser Overhead von zusätzlichen SSH-Verbindungen entfernt wird.

Die folgenden Optionen können zum Konfigurieren von Multiplexing mit SSH verwendet werden:

  • * + ControlMaster + *: Diese Option teilt SSH mit, ob Multiplexing möglich ist. Wenn Sie diese Option verwenden möchten, sollten Sie sie im Allgemeinen entweder in der langsam zu verbindenden Host-Sektion oder in der generischen Sektion "+ Host * +" auf "auto" setzen.

  • * + ControlPath + *: Mit dieser Option wird die Socket-Datei angegeben, mit der die Verbindungen gesteuert werden. Es sollte sich an einem Ort im Dateisystem befinden. Im Allgemeinen wird dies mit SSH-Variablen angegeben, um den Socket einfach nach Host zu kennzeichnen. Um den Socket anhand des Benutzernamens, des Remote-Hosts und des Ports zu benennen, können Sie "+ / path / to / socket / +" verwenden.

  • * + ControlPersist + *: Diese Option legt in Sekunden fest, wie lange die TCP-Verbindung geöffnet bleiben soll, nachdem die letzte SSH-Verbindung geschlossen wurde. Wenn Sie diesen Wert auf einen hohen Wert einstellen, können Sie nach dem Schließen der ersten Verbindung neue Verbindungen herstellen. In der Regel können Sie diesen Wert jedoch auf einen niedrigen Wert wie „1“ einstellen, um zu vermeiden, dass eine nicht verwendete TCP-Verbindung geöffnet bleibt.

Im Allgemeinen können Sie dies in einem Abschnitt einrichten, der ungefähr so ​​aussieht:

Host *
   ControlMaster auto
   ControlPath ~/.ssh/multiplex/%r@%h:%p
   ControlPersist 1

Anschließend sollten Sie sicherstellen, dass das Verzeichnis erstellt wird:

mkdir -p ~/.ssh/multiplex

Wenn Sie für eine bestimmte Verbindung kein Multiplexing verwenden möchten, können Sie in der Befehlszeile kein Multiplexing wie folgt auswählen:

ssh -S none @

Fazit

Inzwischen sollte klar sein, dass Sie die Optionen, die Sie für die Verbindung mit Remote-Hosts verwenden, stark anpassen können. Solange Sie die Art und Weise berücksichtigen, in der SSH die Werte interpretiert, können Sie umfangreiche Mengen spezifischer Werte mit angemessenen Ausweichmöglichkeiten erstellen.