Reverzní SSH tunelování

Super inspirace, čeká mě vzdálená správá linuxu schovanýho za 2 nat a tohle je fakt dobře vymyšlený...

pekne. ja bych to misto rc.local dal do inittabu. tam je to vic na jistotu. eventuelne bych tam dal openvpn, kdyby bylo potreba neco vic nez ssh pristup.

Super návod, taky děkuji ...

[2] - skoro bych rekl ze openvpn k tomuto svadi mnohem vice - a to v rezimu 'road-warior' - kazdy ze spravovanych pocitacu by se pripojil do VPN kdyby bylo treba - takhle by to bylo pekne transparentni a mohl bych obsluhovat vsechny zaraz v jedne siti

Zajimave, jen trochu nechapu proc nepouzijete VPN? Resil jsem podobny problem doma, nechci verejne routovatelnou IP (muzu ji mit, ale nepotrebuji ji). Tak jsem postavil OpenVPN tunel proti serveru s verejnou IP. Konfigurace na 5 minut a odpada jakakoliv starost o navazani ci udrzovani spojeni, openVPN toto resi samo :-) Pres takovy tunel si spoustim z prace na domacim pocitaci X aplikace jako kontact apod. a jsem nadmiru spokojen.

[5] VPNka mi přišla jako kanón na vrabce. Kvůli tomu, že jednou za dva týdny poutřebuji udělat apt-get update; apt-get upgrade (nechci to dávat do cronu a nemít k tomu vzdálený přístup - co kdyby se apt v půlce instalace na něco ptalo nebo se něco rozbilo), nebudu stavět VPN. Ale kdybych potřeboval něco víc :-) tak to zkusím.
Ad. X-aplikace: co máš za linku? já to kdysi zkoušel se zapnutou kompresí na čtvrtmegabitu a použitelné nebylo skoro ani Xeyes :-) Jinak ve 100Mbit LAN pohoda.

Zdravim,
ja pouzivam ponekud jinou vec - "prave" ssh tunely, tj. nikoliv option -R, ale prikazem 'ssh -v -f -w0:1 my.tunnel.host true'. Ty uz jsou funkcne prakticky identicke s openvpn, ale konfigurace je stale o mnoho jednodussi. Pouzivam to hlavne tam, kde je treba "vystrcit" stroj zpoza zafirewallovaneho intranetu, ale jeho admin nechce udelat diru :-). Aby to nebyla uplna rana pod pas, tak si pak pomoci iptables omezim dostupnost takto vznikleho rozhrani jen na stroje, odkud potrebuji pristupovat a tim nedegraduji zabezpeceni. A protoze mam zkusenost, ze tyto ssh tunely se obcas "ucpou" (prestanou jednostranne prenaset, data se hromadi ve vstupni fronte tun interface a neprochazeji skrz), mam i maly scriptik, ktery kontroluje, zda je tunnel stale up a pokud uz neni, znovu jej nahodi. Samozrejme pro tento ucel potrebujete pridelit jednu verejnou IP, ale tech mam nastesti dost :-). Scripty pro nahozeni a udrzeni tunelu zaslu pripadnym zajemcum mailem. S pozdravem Pavel Troller

Doporucil bych nasazeni openvpn nez takoveto harakiri pres ssh. Kdysi vychazeli pekne clanky o tunelovani tady na rootu (tuneluji, tunelujes, tunelujeme...? ).

AD: vpn .. Na druhou stranu zase se naučíte, jak takovou situaci zvládat standardní cestou ;) ... jinak navázání jedné služby na jinou uplně nesouvisející (tunelu na http server) není uplně košér ;)

[7]: Velmi zajímavé. Prosím o zaslání příslušných skriptů, mail: linhq48 [zav] seznam.cz. Děkuji.

Program ako autossh vam asi nic nehovori? ten vytvara tunel sam a aj sam kontroluje ci ten tunel je funkcny.

WOW, OpenSSH že umí kromě toho "bezpečného" telnetu i port forwarding?? Tohle "vymyslet" muselo stát obrovskou invenci! Jeden by nevěřil, co všechno může bystrý člověk sám o sobě objevit, tedy pardon, "vymyslet". Jak vás vůbec napadlo, že by příkaz ssh mohl nějaké parametry mít? A koho by napadlo, že se funkce pro lokální/vzdálený forward dá použít na lokální a vzdálený forward... No nás, čtenáře a redakci root.cz, rozhodně ne. Tomu tedy říkám "vlastní řešení", bravo! Bravo!!

Už jste psal vývojářům OpenSSH? Za tohle vám budou určitě hrozně vděční; podle mě o této možnosti také ještě neví. Na to jsou holt potřeba "zlatý český ručičky". Zkuste vymyslet i nějaký dobrý způsob, jak všechny ty nově "vymyšlené" parametry zdokumentovat. Něco jako... já nevím, na to bude asi potřeba někdo chytřejší, jako vy, například... něco jako... manuál? Manuálové stránky? Nevím, jen si hraji se slovy, brainstorming, víte co. Zkuste nad tím popřemýšlet! Představte si, že ssh má i nějaké další dosud neobjevené vlastnosti a funkce. Kdyby se tak našlo víc lidí jako jste vy, společně byste jistě dokázali "vymyslet" celou řadu nových "řešení" pro OpenSSH a silou svého génia mu i vetknout nový, originální, parametr pro každou z nich. Časem by tak ssh mohlo mít třeba i desítky parametrů!

Podtrženo a sečteno, skvělá práce! Myslím, že mluvím za všechny, když říkám: "Děkuji." Vaše invence a originální přístup nám opravdu jdou příkladem. Kdyby všichni v open source byli jako vy, OpenSSH by již nyní mohlo mít dobré dva, tři parametry nad rámec obligátního "telnetu" zabezpečeného prostřednictvím substituční šifry.

Ještě jednou díky,
Tukan

Jeste se da pouzit hamachi a v nem si nadefinovat podsiti, kolik chci.

OpenVPN je super a sam ho taky pouzivam, ale tam musi byt aspon jeden server s pevnou IP s bezicim OpenVPN serverem. U hamachi se mohou navzajem primo spojit i dva klienti za NATem.

No jasne ze sa spoja aj 2 klienti za NATem kedze sa pripajaju na server s pevnou IP. Hamachi je vlastne OpenVPN na ktory sa pripaja x PC za NAT a on ich spoji do jednej "siete".

Presne tak - nepotrebujete mit svuj OpenVPN server. Hamachi si pouzije svuj.

Tukan: typicka reakcia zakomplexovaneho linuxoveho blba.
Bez urazky.

[16] Bez urážky, ale ten přídomek "linuxového" jste si mohl odpustit.

Jako sorry, ale post o objevení -R uvedený "vymyslel jsem vlastní řešení" si nic jiného než hrstku kritického humoru nezasluhuje.

Ale podívejte se sami na sebe. Než tomu chudákovi všichni nadiktujete ten svůj oblíbený VPN soft, co musí nacpat na obě strany, co takhle poradit něco s SSH? Já nevím, ale na to co potřebuje se OpenSSH hodí úplně perfektně - je "bez instalace", bez složitého nastavování, a na rozdíl od vašich skvělých plnohodnotných VPN není naprostou píčovinou. Uvědomujete si, že chce jen možnost jít do sítě ze které se může přihlásit??

Jendo: máš dva počítače, prace a doma. Z prace se můžeš přihlásit domu, ale ne opačně. Chceš i opačný přístup.

user@prace:~# ssh -R4321:localhost:22 user@domu [-i ~/.ssh/id_klic­_domu]
user@doma:~# ssh -p4321 user@localhost [-i ~/.ssh/id_klic­_prace]

To je něco na což jsi přišel sám. Důležité je mít forward v práci ve smyčce, tak jak to už máš. Jak vidíš, doporučuji ti vygenerovat si dva páry klíču, abys nemusel zadávat heslo. V takové konfiguraci je ale velmi moudré na straně doma pro přihlášení forwarderu dedikovat speciálního uživatele - nepřihlašuj se tedy z práce na sebe, vytvoř si pro to extra konto a v domácím sshd_config nastav přibližně následující:

Match User fwuser
Banner /etc/motd.fwuser
PasswordAuthen­tication no
GatewayPorts no
AllowTcpForwarding yes
PermitOpen localhost:4321
X11Forwarding no
ForceCommand /usr/local/bin/fwlo­op

V práci bude smyčka stejná, jen místo "user" se budeš přihlašovat jako "fwuser". Výhodou tohoto nastavení je, že když se ti k tunelu v práci někdo dostane, nemá k tobě domů otevřené dveře dokořán, žádné dveře tam nejsou. Proč? Tvé domácí sshd nedovolí uživateli fwuser nic jiného, než nahodit forward (otevřít jeden jediný port) - díky ForceCommand nedostane ani interaktivní shell. Max se přihlásí a uvidí výstup programu /usr/local/bin/fwlo­op. Já v něm mám např:

while true;do printf .;sleep 5;done

Kdyby zmáčkl Ctrl-C jen přeruší celé spojení. Vedlejší přínos té smyčky je, že ti tvůj forward drží aktivní a na žádné straně ho tak neusekne případný FW (funguje to lépe než ServerAliveIn­terval/ServerA­liveCountMax).

Je ale víc možností. Jedna věc je zpřístupnit si u sebe doma jeden port, lepší věc je zpřístupnit celou síť:

user@doma:~# ssh -D9080 -p4321 user@localhost

Tenhle příkaz se z domova přes forward přihlásí na SSH té pracovní mašiny (nebo kterékoli jiné, záleží jaký počítač:22 si v -R nastavil) a u tebe otevře port 9080, který se chová jako SOCKS4 proxy. SSH tomu říká dynamický forward - ano máš tak dva forwardy: z práce domů connect-back a přes něj pak z domova SSH, které tě pustí do celé pracovní sítě. Ani toto řešení nevyžaduje, abys na kterékoli straně byl přihlášený jako root. Většina programů SOCKS proxy podporuje přímo, takže to v nich jen stačí nastavit. Ty které to neumí, můžeš pomocí utility tsocks(1) ošálit tak, že si budou myslet, že běží v pracovní síti.

Poslední a nejlepší řešení je VPN, které je již v SSH pěkně dlouho. Výhoda - na obou stranách se ti otevře tunX interface provázané SSH spojením, kterým už jednoduše můžeš přiřadit IP a v routovací tabulce si nastavit routování práce/doma. Výhoda - máš přímé spojení do celé pracovní sítě, je to jako opravdové VPN s pingy atd., ale bez sraní se s instalací, řešení NATů, protlačování molochů jako OpenVPN nebo OpenS/WAN přes jeden forward, bez učení se zbytečností, bez hodin konfigurace. Výhoda - stačí ti jedno jediné spojení, ani není potřeba connect-back, i když je to s ním lepší (viz dále).

root@doma:~# ssh -w1:1 -p4321 root@localhost

Ano, tak snadné a tak neznámé, že nikdo z místních mudrců nebyl s to ti o tom říci. :) Když ti něco nepůjde, projdi logy, SSH ti všechno pěkně popíše. Všimni si, že to musíš dělat jako root a taky přihlásit se na roota. Sshd na obou stranách musí běžet s nastavením "PermitTunnel yes" a tvůj kernel musí umět nebo mít modul pro tun/tap interface (u distribučních to není problém, u vlastního si možná budeš muset tento modul přikompilovat). Výsledek je nový tun1 interface na obou stranách, kterému jen přidělíš IP a masky. V tom máš dvě možnosti:

1) přidělíš jim IP z priv. rozsahu a na pracovní straně zapneš maškarádu; to se nedá splést, je to rutina; výhoda - na tvůj domácí interface se z firmy nikdo nedostane, jedině by byl přímo na cílovém -w1:1 stroji

2) přidělíš si volnou IP z firemního rozsahu a jsi přímo v jejich síti se vším všudy; pak je dobré podchytit přístupová práva pomocí iptables; toto řešení má samozřejmě jeden zádrhel - jak nastavit routování? jak bude pracovní síť vědět, že na to jedno (nebo víc) IP u tebe doma se dostane přes interní -w1:1 "gateway"? odpověď je obligátní pro člověka, který to umí se sítěmi - nevím jestli mezi ně patříš, proto věz, že řešením je ARP PROXY.

Tady máš skript, který používám já:

echo "CONNECTING to prace VPN"
ssh -p4321 root@prace -fw1:1 -oServerAliveIn­terval=10 -oServerAliveCou­ntMax=3 ' \
echo "REMOTE SETUP"
ifconfig tun1 10.10.64.222 netmask 255.255.255.255 up; \
ip ro ad 10.10.64.223/32 dev tun1; \
echo 1 > /proc/sys/net­/ipv4/ip_forwar­d; \
echo 1 > /proc/sys/net­/ipv4/conf/et­h0/proxy_arp'

while ! ifconfig tun1>/dev/null 2>&1; do echo "Waiting for VPN connect..."; sleep 1; done

echo "LOCAL SETUP"
ifconfig tun1 10.10.64.223 netmask 255.255.255.255 up
ip ro ad 10.10.0.0/16 dev tun1
echo 1 > /proc/sys/net­/ipv4/ip_forward
iptables -t nat -D POSTROUTING -o tun1 -j MASQUERADE
iptables -t nat -I POSTROUTING -o tun1 -j MASQUERADE

Místní systém určitě rozhodí formátování, snad to bude zřetelně vidět i bez všech odsazení a s případným zalomením některých řádků. Je to jen pro inspiraci, prober si to.

Jak vidíš, připojím se na jeden interní stroj jako root, nahodím VPN. Když je hotovo, spustí se na vzdálené straně konfigurace tun1 interface. Jedna volná IP pro tamní tun1, nastavení routy pro domácí stranu a zapnutí ARP proxy. Když je vše nahoře i na domácí straně, spustí se lokální konfigurace. Druhá volná IP na můj tun1 interface a nastavení rout(y) pro všechny rozsahy, které jsou dostupné ve firmě. Zapnutí forwardu u mě + lokální maškaráda tě nemusí zajímat - je to jen pro ostatní počítače u mě doma, které tak mohou domácí VPN stranu používat jako router pro firemní rozsah. Ty už mají jiné, privátní, adresy, protože nepotřebuji a nechci, aby měli IP z firemního rozsahu.

Z toho všecho jistě vidíš, proč preferuji VPN nahazovat od sebe a ne z práce. Sice by na to celé stačilo jedno SSH spojení (z práce), ale zas by kdokoli ze vzdáleného stroje měl potenciálně přístup na mého roota. Preferuji opačnou situaci, s tím, že connect-back běží pod oním okleštěným uživatelem (jak jsem demonstroval), a i když tam jsou klíče, nikdo se mi ve skutečnosti do systému dostat nemůže. Je to tedy řešení i pro situaci, kdy pracovní počítač je "untrusted".

To by mohlo stačit. Chápu, že nebylo pěkné si z tebe dělat srandu, ale nedalo mi to. :) Tohle máš na oplátku. Tři kompletně popsaná řešení, jeden velmi cenný trik s restrikcí přihlašovaných uživatelů, funkční příklady a skripty kolem. Mrzí mě, že nemůžu říct, že ti všichni moudří tady kolem - co mě tak nepěkně pomluvili :)) - nedokázali předvést ani řádek použitelného know how. Na problém "potřebuji přístup do práce" zvládli leda tak vyjmenovat jeden VPN software, který je navíc pro tuto situaci zcela nevhodný. Ať žijí konformní a hloupá stádečka - vždyť jsou natolik slušná, že je ani nenapadne si z někoho udělat legraci. To se přece musí ocenit; sice nepomohou, ale _neublíží_... A to je to hlavní, milé děti. Tak a teď na kutě a spát!

Tukan

Tukane, díky za vyčerpávající komentář. Určitě využiju.
Jinak to "vymyslel jsem vlastní řešení" jsem tam nenapsal já a ani jsem to neměl v úmyslu, popis článků ve "Výběr z blog.root.cz" píše vždycky pan Krčmář.
Ještě jednou díky za inspiraci.

Trochu OT, ale nevite nekdo, jestli je mozne mit webovy server (pouze na pokusy) na pocitaci s neverejnou IP, kdyz nemam pristup na zadny pocitac s verejnou IP (napr. abych si tam udelal tunel)? Je nejaka sluzba, ktera neco podobneho nabizi?
Dik.

[20] No pokud ho chceš mít veřejně přístupný a správce natujícího routeru ti nechce nastavit port forwarding, tak ne.

[19] Aha, no na Krčmáře to rozhodně sedí; promiň, myslel jsem, že jsi to psal ty. Bylo to takový divný, vymyslet řešení tak, že se použije jeden přepínač k tomu k čemu slouží... :) Občas mi to nedá a musím si v takovém případě šťouchnout. Beru původní diatrábu zpět, bez toho perexu na HP to je totiž docela OK log. Zdravíme Krčmáře, který ví, jak nezklamat své "fanoušky". :)

Otázka trochu mimo - pokud jsem na pocitaci s neverejnou IP a chci xe připojit na pocitac s neverejnou IP a nemám "spřátelený" server a správce sítě mi nepřidělí port (přesměrování), co mi zbývá?
Našel jsem jen Hamachi a dále zmínku, že by to mohlo s OpenVPN (snad) jít protunelovat...

[23] http://www.root.cz/clanky/prelez-preskoc-a-podlez-nat/

[11]: Ne, o programu autossh jsem opravdu nevedel. Vrele diky za rozsireni obzoru! Jiz jej mam nainstalovany (kompilace je velmi humorna, napred asi minutu bezi configure a pak cca 100 ms se kompiluje jediny .c soubor :-) ). Jiz jej testuji a pokud vyhovi, samozrejme na nej prejdi misto sveho scriptoveho reseni. Zdravi Pavel Troller

V posledni dobe jsem v podobnych pripadech zacal delat to, ze jsem na pocitaci ke kteremu se takhle musim dostat zprovoznil IPv6 (pro jeden pocitac za NATem nejaky tunel (sixxs + aiccu), pro celou sit s jednou verejnou IP adresou statickej tunel od HE (podstatne mensi opruz nez SixXS), nebo aspon 6to4..

Pak se tam dostanu odkudkoli, kde IPv6 mam, coz se snazim vsude. Sshcknu se odkudkoli kamkoli, klidne i s -X, a proste to funguje. Kez by tak uz cesti provideri tu IPv6 davali nativne :/

Právě jsem zkusil ipv6 tunel-prostě jsem nainstaloval a spustil gwsix - a ono to jede!
Bez nastavování, zkusil jsem ping a ssh, prostě paráda.
Přímo mi to vyrazilo dech...

[18] OpenSSH umožňuje i omezování spouštění programů pro jednotlivé klíče, například je možné do authorized_keys napsat (příklad z manuálové stránky :):

tunnel="1",com­mand="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",com­mand="sh /etc/netstart tun2" ssh-rsa ... john

Pomocí parametru from lze také omezit použití daného klíče na konkrétní IP adresy.

Zajímavé řešení. Nicméně možná se stačilo informovat u U:fona. Veřejnou statickou adresu sliboval od loňska, pár neodbytným jedincům ji dokonce umožnil a od 21.7. ji nabízí plně veřejně. Samozřejmě za prachy, ale těch 149 Kč /měsíčně by možná Ti kteří nejsou techničti zdatní jako autor také utáhli a je to rozhodně levnější oproti konkurenci.

diky za nakopnuti - nechtel jsem si nic installovat, jen pouzit SSH. Ale ono stale tvrdosijne povidalo "connect to address xxx.xxx.xxx.xxx: Connection refused"; holt jsem spatne studoval man ; )

To je prostě skvělé. Jen jsem pořád učit něco nového každý den! Děkuji!