SebaGeek ...so cool, dass es schon supra ist! (Science Joke)

Mehr SSH Proxying

26.10.2011 16:40, Tags: #Server, #Linux
Inzwischen ist für mich das Tunneln über zwei (oder mehr) SSH-Hosts wesentlich alltäglicher geworden. Meine alte Lösung dafür (hier beschrieben) hat aber zwei Nachteile. Einerseits braucht man auf dem Server, über den man springen will, sowohl eine Shell als auch Netcat, andererseits hat man bei vielen geschlossenen Verbindungen viele hängende Netcat-Prozesse.

Inzwischen geht das ganze ein Stück einfacher: Irgendwo zwischen OpenSSH v5.1 und v5.5 wurde der "-W" Parameter eingeführt, mit dem SSH über die bestehende Verbindung eine TCP-Verbindung zu einem anzugebenden Host/Port Paar aufbaut. ssh meinhost -W seba-geek.de:80 ist also äquivalent zu ssh meinhost nc seba-geek.de 80 - bis auf, dass der ganze Netcat-Overhead wegfällt. Hier also nochmal die überarbeitete Config aus dem vorhergegangenem Blogpost:

1 Host gateway
2 Hostname gateway.foo.bla
3 IdentityFile ~/.ssh/gatewaysshkey
4
5 Host internal
6 Hostname internal
7 ProxyCommand ssh gateway -W "%h:%p"
8 IdentityFile ~/.ssh/internalsshkey

Für Gelegenheiten, in denen man nicht extra Configs anlegen möchte, kann man auch folgendes (recht triviales) Script nehmen:
 1 #!/bin/bash
2
3 if [[ "$2" == "" ]]; then
4 echo "Usage: <proxyhost> <ssh params>"
5 exit 1
6 fi
7
8 proxy=$1
9 shift
10 ssh -o ProxyCommand="ssh $proxy -W %h:%p" $@

Hat man nun zum Beisiel ein Netz, in dem man nur einen SSH-Server erreichen kann, baut man über diesen und danach sicherheitshalber über einen eigenen Server einen Socks-Proxy auf: sshproxy host.intern someserver.de -D 7777

SSH Proxying

31.05.2010 02:23, Tags: #Server, #Linux
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.
π