Benutzer-Werkzeuge

Webseiten-Werkzeuge


howtos:sshstepstone
Übersetzungen dieser Seite:

SSH - Stepping Stones

Was soll das sein, ein Stepping Stone. Mein Unternehmen stellt mir einen Rechner zur Verfügung, der als Einsprungspunkt ins Firmennetz dient. Auf diesem Rechner sind erweiterte Authentifizierungsinformationen erforderlich, z.B. ein OATH (One Time Authorisation Token). Eine Anmeldung nur durch einen Private Keys ist unterbunden. Der Rechner ist also quasi der Einstiegspunkt in das Firmennetzwerk.
Das tägliche Problem ist es zig-mal das OATH herauszugraben, sobald einer der Server meine Aufmerksamkeit verlangt. Das muss auch einfacher gehen. Wie gehe ich vor? Ich melde mich auf hop.example.com an und wechsele von dort via ssh zu database.example.com, ich brauche also zwei Commands

Client: ssh hop.example.com # Damit bekomme ich eine Shell auf dem Stepping Stone, muss aber das OATH benutzen
Hop: ssh database.example.com # Nun bin ich auf dem Datenbank Server

Will ich mich nun auch noch auf dem WebServer web.example.com anmelden, wiederholt sich die Prozedur. Das OATH ist schon ganz abgegriffen 8-)

Ich will es einfacher haben, also passe ich meine .ssh/config mal wieder an. Ich lasse den „Host *“ Teil mal weg, um es übersichtlicher zu gestalten.

# Erstmal den Stepping Stone definieren
Host step
  User            admin
  HostName        hop.example.com
  ForwardX11      yes   
  LocalForward    2222 localhost:22
# Jetzt den Port 2222 auf meinem Client
Host tunnel
  HostName        localhost
  Port            2222
  User            admin
# Nun den Rest der Firma
Host *.example.com
  HostName        %h
  User            admin
  ProxyCommand    /usr/bin/ssh -q -W %h:%p tunnel

Der Befehl

ssh server2.example.com

bringt mich jetzt sofort auf den angegeben Server, ohne das ich nochmals das OATH bemühen muss. Ein Blick in den Debug Output (ssh -v) zeigt uns wie es funktioniert.

[user@client][/home/user] ssh -v server2.example.com
OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 114: Applying options for *
debug1: /home/user/.ssh/config line 179: Applying options for *.example.com
debug1: Executing proxy command: exec /usr/bin/ssh -q -W server2.example.com:22 tunnel

Alles klar? Natürlich nicht, also hier die Auflösung des Rätsels. Einmalig melde ich mich auf „step“ an, um den lokalen Port 2222 mit dem Port 22 des Stepping Stones zu verheiraten. Hier muss ich mich natürlich mit meinem OATH ausweisen. Diese SSH Session minimiere ich und vergessen sie.
Da jetzt aller Traffic auf meinen lokalen Port 2222 an den Port 22 des Stepping Stones geleitet wird, könnte ich mich jetzt sofort mit „ssh tunnel“ auf dem Stepping Stone anmelden, ohne das OATH herausholen zu müssen. Damit habe ich diese Schritt zwar vereinfacht muss aber immer noch zwei ssh Commands eingeben, um dahin zu kommen wo ich eigentlich hin muss.
Der dritte Eintrag ist es, der mit den „direkten“ Login erlaubt. Der Parameter „ProxyCommand“ sorgt dafür, das auf „tunnel“ ein Befehl (ssh in diesem Fall) gestartet wird. Der zu diesem ssh Aufruf „-W %h:%p“ ist ein wenig kryptisch. In der .ssh/config kann ich Variablen verwenden, „%h“ steht für den eingegeben Hostnamen, „%p“ für eine eingegebene Portnummer (wenn man keine angegeben hat, wird 22 als Default genommen).
Eine Liste der nutzbaren Variablen ist:

  1. %% - Das Zeichen ‘%’
  2. %C - Abkürzung für %l%h%p%r
  3. %d - Pfadname des lokalne Home Directories
  4. %h - Der lokale Hostname
  5. %i - Die lokale Benutzer ID (numerisch)
  6. %L - Der lokale hostname
  7. %l - Der voll qualifizierte lokale hostname (client.heim.netz)
  8. %n - Der im ssh Command angegebene Hostname
  9. %p - Der Port auf der Server Seite
  10. %r - Der username auf dem Server
  11. %u - Der lokale Benutzename

Während der Arbeit habe ich nun aber immer das Fenster mit der „Step“ Session offen, um den lokalen Port 2222 nutzen zu können. Wenn man das Fenster als störend empfindet, kann man mit

ssh -N -f step

den ssh Prozess in den Hintergrund schicken und das Fenster schliessen. Es stellt sich jetzt aber die Frage, wie ich den so in den Hintergrund verschwundenen Prozess kontrollieren (.z.B. beenden) kann. Dafür gibt es den sogenannte Control Mechanismus, der mit allen so aufgesetzten ssh Verbindungen über einen ControlPath kommunizieren kann. Auf weitere Einsatzzwecke komme ich in weiteren HowTo's zu sprechen, hier nur mal der Command um dies zu realisieren:

ssh -N -f -o "ControlMaster=auto" -o "ControlPath=~/.ssh/cm_sockets/%r@%h:%p" step

wird der Prozess gestartet und sofort in den Hintergrund geschickt. Das Verzeichnis ~/.ssh/cm_sockets/ muss existieren. In der .ssh/config sind die Einträge wie folgt zu setzen:

# Erstmal den Stepping Stone definieren
Host step
  User            admin
  HostName        hop.example.com
  ForwardX11      yes   
  LocalForward    2222 localhost:22
  ControlMaster   auto
  ControlMaster   ~/.ssh/cm_sockets/%r@%h:%p
  ControlPersist  0
   

Durch die Angabe eines ControlPath wird es uns möglich, den Hintergrundprocess mit der Option „-O“ zu kontrollieren

ssh -O check step # Prüft, ob die Connection aktiv ist
ssh -O exit step # beenden die Connection

Die weiteren möglichen Befehle zu „-O“ findet ihr, wie schon gesagt, in anderen SSH HowTo's.

howtos/sshstepstone.txt · Zuletzt geändert: 2022/02/18 08:09 von 127.0.0.1