SSH Proxying
Folgendes Problem ergab sich mir durch meinen Studentenjob: Ich habe einen haufen Linuxkisten, die alle nicht aus dem Netz per ssh erreichbar sind. Nur eine spielt quasi ssh-Gateway. Will ich nun auf eine der Kisten (z.B. Internal) muss ich also über den Gateway. Hierzu gab es mehrere Ansätze:
1. ssh zum Gateway, dannach ssh von dort aus zu Internal. Problem ist nur, dass man vielleicht dem Gateway nicht vertrauen möchte. Ausserdem ist man dann zu Passwordauthentication verdonnert, da man nicht wirklich ssh-Privatekeys auf der Kiste liegen haben möchte. Also kriegt der Gateway im Zweifelsfall auch das Passwort mit. Unschön.
2. Portforwarding: ssh gateway -L localhost:1234:internal:22 und dann ein ssh localhost -p1234. Potentiell eine Möglichkeit, gerade wenn man sich das irgendwie hinscriptet. Nur will man eigentlich nicht für jeden Server einen lokalen Port assignen damit die knownhosts nicht kaputt gehen. Gefällt mir auch nicht.
3. ssh ProxyCommand ! Direkt in ssh drin. Die Theorie: ssh zu Gateway. Dort dann direkt netcat internal 22 ausführen und somit an den SSH-Stream von Internal dran kommen und dagegen dann ssh machen. Für den Gateway ist der Traffic zu Internal verschlüsselt, man kommt direkt dran und kann auch mit scp/sshfs/younameit direkt arbeiten (und natürlich auch lokale keyfiles zum authen benutzen!). Einziger Unterschied ist, dass man ggf. zwei Passwörter für den Account (oder den ssh-Key, je nachdem) eingeben muss.
Hier die Konfiguration dafür:
Host gateway
Hostname gateway.foo.bla
IdentityFile ~/.ssh/gatewaysshkey
Host internal
Hostname internal
ProxyCommand ssh gateway nc %h %p
IdentityFile ~/.ssh/internalsshkey
Bedingungen dafür sind, dass auf Gateway netcat vorhanden ist und er internal zu der internen ip auflösen kann (kann man ggf. natürlich auch einfach selber dort einsetzen..). Meiner Meinung nach eine super Sache und ein riesen Spaß. Vielleicht hilft es ja auch dem ein oder anderen.
1. ssh zum Gateway, dannach ssh von dort aus zu Internal. Problem ist nur, dass man vielleicht dem Gateway nicht vertrauen möchte. Ausserdem ist man dann zu Passwordauthentication verdonnert, da man nicht wirklich ssh-Privatekeys auf der Kiste liegen haben möchte. Also kriegt der Gateway im Zweifelsfall auch das Passwort mit. Unschön.
2. Portforwarding: ssh gateway -L localhost:1234:internal:22 und dann ein ssh localhost -p1234. Potentiell eine Möglichkeit, gerade wenn man sich das irgendwie hinscriptet. Nur will man eigentlich nicht für jeden Server einen lokalen Port assignen damit die knownhosts nicht kaputt gehen. Gefällt mir auch nicht.
3. ssh ProxyCommand ! Direkt in ssh drin. Die Theorie: ssh zu Gateway. Dort dann direkt netcat internal 22 ausführen und somit an den SSH-Stream von Internal dran kommen und dagegen dann ssh machen. Für den Gateway ist der Traffic zu Internal verschlüsselt, man kommt direkt dran und kann auch mit scp/sshfs/younameit direkt arbeiten (und natürlich auch lokale keyfiles zum authen benutzen!). Einziger Unterschied ist, dass man ggf. zwei Passwörter für den Account (oder den ssh-Key, je nachdem) eingeben muss.
Hier die Konfiguration dafür:
Host gateway
Hostname gateway.foo.bla
IdentityFile ~/.ssh/gatewaysshkey
Host internal
Hostname internal
ProxyCommand ssh gateway nc %h %p
IdentityFile ~/.ssh/internalsshkey
Bedingungen dafür sind, dass auf Gateway netcat vorhanden ist und er internal zu der internen ip auflösen kann (kann man ggf. natürlich auch einfach selber dort einsetzen..). Meiner Meinung nach eine super Sache und ein riesen Spaß. Vielleicht hilft es ja auch dem ein oder anderen.
Alternativ kann man auch ssh -A in Verbindung mit einem lokalen ssh-agent auf dem Client benutzen.
Damit benutze ich einen ssh-key um mich auf beiden nacheinander zu authen und keiner von beiden bekommt den Key direkt, da nur die ssh-auth Verbindung weitergeletet wird.
And the problem is lots of hanging netcat processes that require cleanup:
cheetah >>ps aux | grep nc
user 889 0.0 0.0 6104 688 ? Ss May17 0:00 nc infrabox 22
<SNIP 100 lines or so>
user 32464 0.0 0.0 6104 692 ? Ss May28 0:00 nc infrabox 22
in principle though, one could probably automate the cleanup and then this solution becomes a bit more elegant :-)