Vytvoření a užívání dočasného SSH tunelu ve scriptu

29.4.2014 12:29 | Přečteno: 1915× | Linux | | poslední úprava: 14.5.2014 10:36

Při potřebě vytváření ssh tunelu ve scriptu jsem doposud vždy vytvořil spojení na pozadí, ale není to nic moc, osobně z toho mám „špinavý“ pocit. Při opětovné potřebě této funkcionality, jsem narazil, vyzkoušel a aplikoval jiný způsob. Někdo asi řekne, že jsem objevil nový světadíl (tuším Ameriku) a bude mít pravdu, pro mě to objev byl…

Běžný a mnou i jinde používaný způsob s procesem na pozadí může být různě variován, ale v zásadě se jedná:

o spuštění a odchycení PID:

ssh -L "50000:localhost:2049" -fnNT "user@server.example.org" &
SSHPID=$!

o čekání či a/nebo jiná kontrolu ustavení tunelu:

sleep 3

…užívání…

uzavření spojení/tunelu (případně předřazená nějaká kontrola existence či co je to za proces):

kill $SSHPID

No a objevený nový světadíl je využití Multiplexing-u k tomuto účelu.

Vytvoříme si cestu pro ukládání kontrolního socket-u (nebo socket-ů):

mkdir -p ~/.ssh/controlmasters/ && chmod 700 ~/.ssh/controlmasters/

Pokud by cesta neexistovala následující příkazy zklamou.

Vytvoření hlavního, pro účely tunelu jediného nutného, spojení:

ssh -M -o "ControlMaster=yes" \
       -o "ControlPath=~/.ssh/controlmasters/myscript_%r@%h:%p" \
       -o "ExitOnForwardFailure=yes" \
       -L "50000:localhost:2049" \
       -fnNT "user@server.example.org"

EDIT 2014-04-29 19:32: Opravil jsem ControlMaster=yes na ControlMaster=auto byla to chyba přepisu.
EDIT 2014-04-29 19:48: Nebyla to chyba přepisu, jen jiné užití (a navíc se mně zamotaly myšlenkové pochody), vrátil jsem to zpět na yes, při tomto užití je to logičtější.

Po úspěšném provedení příkazu je tunel ustaven (na rozdíl od spouštění procesu/tunelu na pozadí).
Nejzajímavější ExitOnForwardFailure=yes (spolu s -L) zajistí, že pokud už spojení existuje tak se nové nevytvoří a je vrácen chybový kód. Pokud by jsme ExitOnForwardFailure=yes neuvedli, tak se spojení naváže, tunel se sice nevytvoří, ale spojení bude „neovladatelné“ ve světle dalších příkazů. Takto jak to je, lze vytvořit právě jedno spojení pro daný script 'myscript_' uživatele '%r' hosta '%h' a port '%p'.
-M + ControlMaster=yes + ControlPath=path zařizuje scriptem nastavený Multiplexing. (Scriptem nastavený proto, že paramtry definované -o lze definovat i v ssh_config)

Pokud si uděláme:

ls ~/.ssh/controlmasters/

tak vidíme i vytvořený socket - což se může hodit na nějaké další interakce.

Kontrola existujícího „master“ spojení se provede lehce:

ssh -O check \
  -o "ControlPath=~/.ssh/controlmasters/myscript_%r@%h:%p" \
  "user@server.example.org"

Návratový kód 0 je jen pokud existuje.
2014-05-08: Při spouštění cron-em může být ještě záhodno dolnit -t -t (-tt) pro potlačení hlášení „Pseudo-terminal will not be allocated because stdin is not a terminal.“.

Také lze kombinovat i hledání jednotlivých spojení v běžících procesech např:

ps -ef | grep "ControlPath=~/.ssh/[c]ontrolmasters/myscript_" | grep 'user@server.example.org'

Jak, je věcí už každého (jen nezapomenout na potlačení nalezení sama sebe - nejjednodušším způsobem přes [])

…užívání…

Zrušení/ukončení „master“ spojení a tedy zrušení tunelu (úklid):

ssh -O exit \
  -o "ControlPath=~/.ssh/controlmasters/myscript_%r@%h:%p" \
  "user@server.example.org"

Vzhledem k definici unikátnosti daného spojeni přes ControlPath lze volat jak se nám zlíbí i opakovaně (samozřejmě v případě neexistence spojení je vrácen chybový kód).
2014-05-08: Při spouštění cron-em může být ještě záhodno dolnit -t -t (-tt) pro potlačení hlášení „Pseudo-terminal will not be allocated because stdin is not a terminal.“.
V příkladech jsem to vždy rozepsal, ale v scriptu si nadefinujeme proměnné a třeba na závěr pomocí

rmdir ~/.ssh/controlmasters/

můžeme cestu i zrušit, má-li být specifická jen pro daný script.
Pokud to spouštíme s „méně definovaného“ prostředí například cron-em, tak si (asi) doplníme plné cesty k příkazům.
Místo ControlPath lze použít parametr -S viz man ssh.
V ukázkách jsem použil '~', je na každém jak s tím práci zvládá… :)
Můžeme ještě využít -o ControlPersist=1h od verze OpenSSH 5.5, která omezí navíc existenci spojení časem.

Podle mě to vypadá mnohem kulturněji než používání procesu na pozadí…

       

Komentáře

[ewew]

Môžeš skúsiť background režime ssh s parametrami spustenia -Nf

[ewew]

Asi to už používaš. Tak potom nič.

[Josef Kufner]

ssh -f -L 1234:127.0.0.1:1234 "$server" sleep 5

Tento tunel se automaticky uzavře s posledním spojením, přičemž 5 sekund čeká na první spojení. Díky -f se ssh pošle do pozadí, jakmile je spojení navázáno a tunel je připraven.

[Šangala]

Trošku mi to rozveď, takto vidím jen tunel ustavený na 5 sec.

[Josef Kufner]

ssh skončí až když je uzavřen poslední proud dat, ať už socket nebo stdio. Ten sleep způsobí, že stdio je otevřené na 5 sekund a pokud do té doby je navázáno TCP spojení skrz tunel, ssh počká na konec tohoto spojení, i když stdio je už ukončeno. A díky -f běží ssh na pozadí, taže pokud je dalším příkazem připojující se program, má tento program těch 5 sekund na otevření spojení.

[Šangala]

To mě pak po odeslání napadlo. Ale pokud si zpřístupňuji/tuneluji služby, nemusí to nutně znamenat, že kontroluji i zbylou komunikaci a rozhoduji kdy se spojení naváže (dělám něco na vyšší úrovni). Nikdy jsem to tak nezkoušel a nemíním začínat, protože je snazší se zeptat Pokud se to takto tuneluje třeba samba nebo nfs, tak to vydrží až do umountu a pak to chcípne?

Jinak to má mouchu, že se takto málokam připojím, u těch věcí co jsou automatické, bo ty „servisních“ účty nemají povoleno provedení příkazu a nemají ani shell (/sbin/nologin a PermitOpen jen na konkrétní port či mašina:port).

U popisovaného/objeveného způsobu se mi líbí, že je to pod přímou kontrolou.

[Josef Kufner]

Otázkou je, k čemu tunel chceš. Já tohle používám k připojení klienta, který neumí šifrovat sám o sobě ke službě, která je děravá. Takže mám skript, který obsahuje uvedený řádek a pak spustí klienta, který se okamžitě připojí a předá příkaz nebo otevře monitorovací okýnko. Tunel pak zmizí sám, jakmile není potřeba.

Pokud bych chtěl mountovat filesystémy a dělat něco složitějšího, nastavím si VPN. Ta je na to dělaná a snadněji se používá.

Co se mountů týče, nezkoumal jsem jak se Samba a NFS chová. Pokud si po celou dobu připojení filesystému drží aktivní TCP spojení, tak se bude držet i tunel. Ale pokud např. NFS bude nastavené, aby běželo po UDP, tak máš smůlu. Ale na to takový tunel beztak není vhodné řešení.

[Šangala]

Odpověď je ke „všemu a k čemukoliv“ je to pokaždé něco jiného.

Ale případ, kdy jsem toto objevil bylo (plně v mé režii) právě prostor pro „hrubé“ šifrované zálohy celých VM mašin (bez dat) pro rychlou obnovu a zálohy jsou lifrovány na zálohovací stroj s NFS (ale jen localhost - přes tunel).

VPN je často zbytečná, starost navíc a pokud to není tvoje, tak jim tam stejně nenastavíš. Právě filesystémy (samba/nfs4) odkudkoliv kamkoliv řeším přes ssh tunel, je to nejflexibilnější, mám na to takový dlouhý, dnes ho označím za zmatený script, který si osahá kde je (ip/MAC brány) a ustaví potřebný tunel (případně i přes více hop-ů, nebo v místě namontuje bez tunelu).

NFS4 přes TCP.

[Josef Kufner]

Zrovna zálohování bych řešil raději rsyncem, či nadstavbou nad ním. Přenáší jen rozdíly a ssh používat umí.

[Šangala]

Už jsem to nechtěl rozepisovat, ale nevyhovuje mi (je to i často/někdy pomalé) - následně šifrovaný přírustkový per-měsíc tar mi sedí víc (rsync na některá data normálně používám). Tedy nejvíc mi sedí obraz, kde je nepoužité místo nulováno, je to pak rozumně malé a obnova je pak velmi snadná, ale zas blbě se to řeší přírustkově, pokud se chce nechat více stavů a taky to trochu nabourává šifrování, ale to jen tak na okraj - a taky je to pomalejší, ale to z vnějšku zas tak nevadí.

Možností jak to dělat je roj.

[pavlix]

Pokud jde o přírůstkovou zálohu, tak na běžné věci se mi nejvíce osvědčil rdiff-backup. Není to nic sofistikovaného, je to v podstatě obdoba rsync s historií.

[Šangala]

Díky - znám, jak jsem napsal, je roj možností a myslím, že jsem fčul zvolil správnou a splňující to co potřebuji (a stejně to v budoucnu bude jinak + se bude držet jeden jednodenní obraz pro okamžitou obnovu) - neměl jsem v úmyslu rozebírat metody a přístup k zálohování, chtěl jsem popsat obejevený způsob ovládání tunelu.

[Šangala]

Vrtá mi to hlavou, bo někdy mám drobné „sociálně-komunikační“ Cooper-ovské problémy .

Jak Josef Kufner tak ty jste chtěli nabídnout řešení, což je bezva a já jsem je odmítl. Není to tím, že bych si nevážil rady, ale tím, že se nemám problém a že mi stav daného zálohování vyhovuje, což sice neznamená, že to mám dobře a nepotřeboval bych radu, jen se mi nechce vysvětlovat všechny souvislosti a procházet znovu všechny varianty (navíc jsem přesvědčen, že stav je to dočasný)…

Obě nabídnuté a i další možnosti zálohová používám (rsync docela aktivně, rdiff-backup v jednom případě, už spíš neaktivně…)

Takže: „Oběma díky, třeba to jindy a jinde rozebereme…“

[pavlix]

Díky, ale myslím, že nad tím až zbytečně moc hloubáš. Většina zdejších diskutujících se v 99% času stráveném diskutováním na věc plně nesoustředí, protože návštěva diskuze představuje buď výplň nebo odpočinek. Nelze očekávat plynulost podobnou rozhovoru z očí do očí ;).

[odin]

Tento clanek je velmi zajimavy, dekuji za nej. Ale neda mi to, musim se zeptat, jakou ma tento zpusob vyhodu oproti napsani skriptu v jazyce, ktery obsahuje libssh a kde lze resit ssh spojeni "nativne"?

[Šangala]

Shell script je to nejlepší pro spojení spousty různých systémových „příkazů“. Nedokážu si představovat provádět základní správu jinak než skripty přímo upravitelnými, krátkými a jen přímo spojující jednotlivé příkazy.

Třeba na NTB si lze velmi flexibilně řídit jednotný přístup odkudkoliv kamkoliv a čehokoliv na cokoliv (třeba připojení samba sdílení či třeba účetnictví z místa, z kterého projde ven jen 22 na místo kde je vstup povolen jen na 22 a v síti za bránou je nějaký fileserver nebo db server třeba VNC a to vše může být i na několik hoop-ů).

Navíc dnešní doba (i díky BYOD apod.) nahrává tomu mít i interní věci vše zabezpečené jakoby byly veřejné a tomu lze napomoci přístupem ke službám jen přes tunel (případně VPN) a tedy mít rozumnou autorizaci a bezpečného spojení pro cokoliv (jak na co a jak kde).

[Odin]

Jiste, to chapu. Ale stale to nevysvetluje, proc nepouzit jiny skriptovaci jazyk, ve kterem lze s ssh pracovat primo. Zpusob, ktery je ukazan v blogu, mi prijde velmi zajimavy a uzitecny, ale stale se mi to zda trochu kostrbate.

[Šangala]

Přiznám se, že nevím co chceš slyšet ani jaký skriptovací jazyk máš na mysli, natož jaký způsob práce/správy a ani nevím co je kostrbaté. Mně to naopak přijde uhlazené, jsou to tři příkazy ustavení/konrola/uzavření.

Budeš muset dát víc - nemám na co reagovat.

[Krystl]

Jeste bych upozornil na sshgate, idealni pokud potrebujete vytvaret tunely do nejake site za ssh serverem. Pri pokusu o pripojeni je automaticky vytvoren tunel, ktery je po ukonceni spojeni automaticky zavren.

K.

[Šangala]

Neznám, tak jsem si jen pročetl README, bo man jsem nenašel, možná se pletu, protože to není moc dokumentované, ale dělá to jen…

…něco jako:

ssh -L 50000:internal_host:2049 -N user@gateway

Nebo

Ne plně bezpečné:

ssh -L 50000:localhost:50000 user@gateway ssh -L 50000:localhost:2049 user@internal_server

a bezpečnější varianta:

ssh -L 50001:internal_server:22 user@gateway
ssh -L 50000:localhost:2049 -p 50001 localhost

?

(parametry jako -NT a -fn jsem vynechal)