"átssh"-zni a tűzfalon

Hálózatok egyéb

Sziasztok!

A munkahelyemen nagyon sok portot tiltanak, de a 80 és a 8080-as portok szabadok. Gondoltam, jó lesz az nekem ssh-zni, ha az otthoni routeren a 8080-as portot átforwardolom egyik gépemre a 22-es portra. Ezzel szerintem nincs is baj. Csupán annyi, hogy nem megy.
Ha jól értelmezem, akkor az
export http_proxy="http://usernevem:jelszo@proxy.cegemproxyszervere.eu:8080", majd a
ssh 123.45.67.89 -p 8080 parancs elég lenne.

De nem történik semmi: nem kapok vissza a promptot.

Ha viszont egy böngészőbe írom be a 123.45.67.89:8080 IP-t és portot, akkor a SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1 visszajelzést kapom a böngésző felületén, vagyis eljutok a kívánt gépig.

Szerintetek hol van a kutya elesve?
(Annyi adalékként, hogy az export http_proxy parancsot jól adtam meg, mert pl. links-el így tudok böngészni konzolból.)

  • 2121 megtekintés

( Zsugabubus | 2007. 09. 03., h – 20:03 )

Az ssh az nem http (hanem ssh...ki gondolta volna), ergo nem megy át http proxy szerveren.

( miloska | 2007. 09. 03., h – 21:35 )

rakj http szervert a http portra es vannak java-s ssh kliensek, azokkal probald.

nem vagyok benne biztos, h azok atmennek a tuzfalon, csak otlet...nem probaltam, felelosseget nem vallalok :)

( cheeky v | 2007. 09. 03., h – 21:55 )

A koncepció jó, de használj HTTPS portot, a tűzfalak zöme csak azon engedi a CONNECT hívást.
Tehát router:443 -> belsőgép:22

Ezután már proxytunnel a barátod.

A leírás szerint próbálkoztam:

$HOME/.ssh/config 


Host foobar
		ProtocolKeepAlives 30
		ProxyCommand /path/to/proxytunnel -p proxy.customer.com:8080 -u user -s password -d mybox.athome.nl:443

majd: 


ssh foobar

ProtocolKeepAlives-zal bánata van az ssh-nak, amit a manual alapján meg is értek, mert nincs ilyen opció.
(A routeremet távirányítással előtte azért módosítottam 443->22-re.)

Bocs, eltuntek az ekezeteim.

Ha ennyire erdekel:
Csinalnak ket root ca-t, egy trusted-et, meg egy not trusted-et.
A trusted-ben minden halozaton beluli ceg megbizik (ceges install pl).

Ezek utan ha elersz egy HTTPS oldalt, akkor az SSL-t a proxy kibontja, general certet az oldalnak a ket CA vmelyikevel attol fuggoen, hogy az eredeti cert valid volt-e, vagy sem, es visszaadja a megfelelo tartalmat, persze a szokasos elemzesek/ellenorzesek utan.

No rocket science. Viszont az SSL lenyeget rombolja le, nevezetesen a ceg ugyan megbizhat az adott oldalban, de az ugyfel, aki a kerest kezdemenyezi, innentol nem lehet biztos benne, hogy az altala kapott informacio autentikus, es nem lett modositva. Ezert is nem terjedt el ez a megoldas.

Az ssh nem panaszkodik, legalabbis nem a kulcs miatt, hanem mert eleve a protokoll nem felel meg a HTTP-nek, tehat mar ott bukik a kapcsolatfelepites.

( gorgo75 v | 2007. 09. 04., k – 11:47 )

Telepits otthon openvpn-t az elérhető proxyn-keresztül ...........