Die unterschätzte SSH config

Ich kenne eine ganze Reihe von IT-Leuten, die täglich SSH nutzen. Doch die wenigsten nutzen eine ~/.ssh/config¹. Dabei ist sie ein durchaus mächtiges Werkzeug und kann den SSH-Workflow stark vereinfachen und bereichern.

Das fängt schon damit an dass - wenn man mit seinen SSH-Keys verantwortungsvoll umgeht, und pro Dienst und/oder Kunden einen eigenen Key nutzt - man schnell in die Situation kommt, dass die Anmeldung auf einigen Systemen nicht mehr funktioniert. Das liegt dann meist daran, dass beim Verbindungsaufbau alle Keys durchprobiert werden müssen, bis der gefunden wurde, der für das System mit dem man gerade spricht, passt. Viele SSH-Server beenden aber nach einer bestimmten Anzahl falscher Keys die Verbindung.

Umgehen kann man das mit indem man ssh -i ~/.ssh/$service -o IdentitiesOnly=yes gpkvt@example.org nutzt, statt einfach ssh gpkvt@example.org. Aber das ist durchaus nervig. Abhilfe schafft hier eine ~/.ssh/config, bei der Gelegenheit kann man auch noch gleich den Usernamen zuweisen, so dass sich der Aufruf auf ssh examle.org verkürzt. Wem das immer noch zu lang ist, kann auch einen neuen Bezeichner für den Host einführen und so z.B. ssh ex nutzen:

Host ex example.org
  HostName 93.184.216.34
  User gpkvt
  IdentityFile ~/.ssh/example_org
  IdentitiesOnly yes

Die Angabe Host können wir völlig frei gestalten, hierbei handelt es sich nur um lokale Bezeichner für die SSH Konfiguration. Wir können beliebig viele Bezeichner festlegen und diese als Host im ssh Aufruf nutzen. Durch die Angabe des HostName als IP Adresse können wir sogar dann eine Verbindung aufbauen, wenn unser DNS gerade einmal nicht funktionieren sollte. Die Angabe IdentityFile sorgt dafür, dass dem Server stets der korrekte SSH-Key präsentiert wird.

Aber damit sind die Möglichkeiten der config Datei noch lange nicht erschöpft. Oft stellen Kunden einem einen sog. JumpHost zur Verfügung. Von diesem aus kann man sich dann ggf. auf weitere Server im Kundennetzwerk verbinden. Ich finde sowas immer recht nervig. Aber auch hier hilft uns die SSH Config weiter:

Host 4711 kundenserver4711 kundenserver4711.kunde.com
  HostName 10.10.10.10
  User gpkvt
  ProxyJump jumphost.kunde.com
  IdentityFile ~/.ssh/kunde
  IdentitiesOnly yes

Durch die Angabe von ProxyJump können wir nun mittels ssh 4711 direkt auf den Server im internen Kundennetz zugreifen, statt wie bisher zunächst ssh -i ~/.ssh/kunde -o IdentitiesOnly=yes gpkvt@jumphost.kunde.com und dort dann ssh gpkvt@kundenserver4711.kunde.com ausführen zu müssen.

Anstatt Angaben für einzelne Hosts vorzunehmen, können wir auch mit Platzhaltern arbeiten:

Host kunde*
  IdentityFile ~/.ssh/kunde
  IdentitiesOnly yes

Oder auch generelle Settings für alle Systeme:

Host *
  IdentitiesOnly yes
  Compression yes

Auch bei eher speziellen Konfigurationen wie z.B. SSH Keys im TPM Chip des Rechners ist die SSH Config sehr hilfreich:

Host dns 192.168.178.2
  HostName 192.168.178.2
  PKCS11Provider /usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
  PasswordAuthentication no
  IdentitiesOnly yes
  User root

Sehr interessant ist auch die Option Tunnel mit der sich quasi ein ad-hoc VPN via SSH erzeugen lässt. Oder auch GatewayPorts mithilfe es dem Remote Host erlaubt werden kann, auf Ports auf der lokalen Maschine zuzugreifen. Ebenfalls sehr hilfreich kann ForwardAgent sein, hierbei wird der lokale Authentication Agent an den Remote Host weitergeleitet. Dies erlaubt es vom Remote Host aus auf weitere Systeme im Netz des Remote Hosts zuzugreifen, ohne auf diesem seinen SSH-Key hinterlegen zu müssen.

Es lohnt sich also, sich mit den SSH Optionen einmal genauer zu befassen. Wer sich hierzu ein paar Videos anschauen mag wird unter ² und ³ bestens versorgt.