Hlavní navigace

Názor ke článku Reverzní SSH tunelování od tukan - Jako sorry, ale post o objevení -R uvedený...

  • 30. 7. 2008 14:13

    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
    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