Reverzní SSH tunelování
Předminule jsem psal o zavádění internetu do jedné firmy v Chrastavě. U:fon nepřiděluje veřejné adresy a tak chci sestavit tunel.
Sestavení tunelu jsem chtěl původně dát do /etc/rc.local, ale to se neosvědčilo – jednak spojení může „vyhnít“, a pak už není nikdo, kdo by jej znovu nahodil, a jednak nechci mít zbytečně navázaný tunel. Telefonické „aktivování“ jsem zavrhl, Jeho Veličenstvo Pan Ředitel má telefonátů moc i tak.
Rozhodl jsem se, že se skript bude jednou za půl hodiny snažit stáhnout soubůrek, a když se mu to podaří, postaví tunel.
Samotný tunel
ssh -R 0.0.0.0:1234:localhost:22 tunelar@yakumo.hrach.eu -n -N -o ConnectTimeout=20 ConnectionAttempts=1
SSHčko se připojí s uživatelem tunelar na yakumo.hrach.eu a port 1234. Na yakumu na všech (0.0.0.0) rozhraních se bude forwardovat na port 22 lokálního přístroje. -N dělá (tedy spíše nedělá) nespuštění vzdáleného shellu, další parametry viz man ssh. Tunelarovi můžeme nastavit shell na /bin/false. chsh tunelar -s /bin/false
Pokud toto spustíme, pravděpodobně zjistíme, že se port 1234 otevřel na yakumu jenom na localhostu a zvenku není přístupný. RTFM, man ssh:
By default, the listening socket on the server will be bound to the loopback interface only. This may be overriden by specifying a bind_address. An empty bind_address, or the address ‚*‘, indi- cates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).
Hmm…
The argument may be ``no'' to force remote port forward- ings to be available to the local host only, ``yes'' to force remote port forwardings to bind to the wildcard address, or ``clientspecified'' to allow the client to select the address to which the forwarding is bound.
Takže do /etc/ssh/sshd_config přidáme GatewayPorts clientspecified.
Aby šlo přihlašování automaticky (bez hesla), vytvoříme si nějakého uživatele (přece nebudeme stavět tunel pod rootem) a pomocí tohoto návodu mu vyrobíme klíč.
Omáčka okolo
#!/bin/bash
while true; do
if wget http://yakumo.hrach.eu/tunel -q -O /dev/null
then
echo ok
ssh -R 0.0.0.0:1234:localhost:22 tunelar@yakumo.hrach.eu -n -N -o ConnectTimeout=20 ConnectionAttempts=1sleep 1 #když spojení spadne, pokusíme se ho obnovit skoro hnedelseecho failsleep 1800 #jinak se půl hodiny vyspímefi done
Skript někam uložíme, nastavíme mu x-bit a necháme ho pod jiným uživatelem než rootem spouštět z /etc/rc.local.
-
Jarda (neregistrovaný)
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.
-
jenda (neregistrovaný)
[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. -
Pavel Troller (neregistrovaný)
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 -
tukan (neregistrovaný)
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 -
tukan (neregistrovaný)
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
PasswordAuthentication no
GatewayPorts no
AllowTcpForwarding yes
PermitOpen localhost:4321
X11Forwarding no
ForceCommand /usr/local/bin/fwloopV 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/fwloop. 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ž ServerAliveInterval/ServerAliveCountMax).
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 -oServerAliveInterval=10 -oServerAliveCountMax=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_forward; \
echo 1 > /proc/sys/net/ipv4/conf/eth0/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 MASQUERADEMí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
-
tukan (neregistrovaný)
[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". :)
-
petr (neregistrovaný)
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... -
Pavel Troller (neregistrovaný)
[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
-
Jirka (neregistrovaný)
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 :/
-
Suchý čert (neregistrovaný)
[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",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... johnPomocí parametru from lze také omezit použití daného klíče na konkrétní IP adresy.
-
paw (neregistrovaný)
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.
