Dotaz: Pristup na SSH pres "cloud"?

[petrfm]

Ahoj, potreboval bych vyresit jednu pikantnost. Mam linuxovou desku, treba RPi, pripojenou k routeru, ktery je za NATem. Nema protunelovane porty, takze se k nemu z venku nemuzu dostat, cili operuje jen v lokalni siti. Chtel bych ho presto ovladat, navazat s nim komunikaci pres internet, idealne, abych se dostal do shellu, treba pres SSH, ale neni to nutne. Da se to nejak zaridit? Umi se treba pripojit SSH k jinemu serveru, vytvorit tam screen sezeni a cekat az se k nemu na tom serveru nekde v netu pripojim a zacnu pracovat vzdalene s tim RPi, skrze ten server nekde v netu?

Snad to pochopite, jak to myslim. Druha moznost je asi nejaka webova aplikace, na kterou by si to rpi sahalo a zjistovalo, zda nema vykonat nejaky prikaz. Ja bych se k te aplikaci pripojil z PC a zadal treba uptime. On by to zjistil, provedl by ten prikaz a vratil mi na ten web vysledek.

Neumim to spravne formulovat, co vlastne hledam, takze se mi spatne hleda na google.

---

---

Odpovědi

[ttt]

Zdá se mi, že vhodné klíčové slovo je "reverse SSH tunnel". Z RPi vytvoříš tunel na server (ssh -R ...), na serveru se pak budeš moc připojit k RPi, i když je za NATem, přes ten vytvořený tunel. Možná se bude hodit i autossh.

[pavlix]

Případně IPsec nebo v podstatě jakýkoli VPN nástroj.

[petrfm]

A nebyva problem s pruchodem VPNek u vsech routeru? Beha to na nestandartnich portech, ne? Neni treba klasicke HTTP nebo telnet spolehlivejsi, ze projde? Potrebuju, aby to bezelo pokud mozno vsude, kde se da dostat na web, aniz bych mel pristup do routeru a moznost konfigurace.

[pavlix]

Co jsou to ty nestandardní porty? Nějaká SSL/TLS VPN na portu 443 by zadání nesplňovala? Klasické HTTP asi spolehlivější nebude, může podléhat nějaké transparentní proxy nebo něčemu takovému. Telnet v podstatě není protokol.

[petrfm]

To jsou porty, které nemusí být vždy otevřené. Ale máš pravdu, asi jsem zvolil špatný termín, jak významově, tak pravopisně Vím jenom, že se u routerů řeší extra propustnost pro VPNky, tak zda nemůže nastat nějaký problém právě kvůli tomu, že to běží na portu VPNky a ne běžné 80tce, FTP, SSH, nebo třeba telnetu. Jestli plácám kraviny, tak sorry, právě proto jsem se přišel zeptat na nejvhodnější řešení

[pavlix]

To jsou porty, které nemusí být vždy otevřené.

Takže všechny. Ale osobně bych sázel na tcp/443, akorát mi docela vadí to, že TCP VPN jsou zoufale neefektivní a zvlášť trpí na sebemenší problémy na síti. Nicméně jakákoli TCP VPN se dá provozovat na jakémkoli TCP portu a stejnětak jakákoli UDP VPN se dá provozovat na jakémkoli UDP portu. IPsec se dá provozovat přímo nad IP nebo přes UDP. I proto má Microsoft SSTP jako výchozí transport tcp/443.

Nenarazil jsem na situaci, kdy by bylo potřeba namísto tcp/443 použít tcp/80, ale stát se to může. O ostatních silně pochybuju. Jinak největší záběr a ještě podstatně horší výkon mají DNS tunely, které fungují i za spoustou captive portálů. :D

[nobody]

tohle prave funguje presne tak ze stanice je ta co vyvolava bezne ssh spojeni smerem ven a ty se na to otevrene spojeni pripojis z venkovniho serveru... sam to tak spokojene pouzivam :)

[nobody]

to se ti nezda :) podle me idealni je to tak:
- na stanici skript kontrolujici jestli bezi ssh spojeni na server, pokud ne tak ho nahodi - pravidelne je pousten cronem
- na serveru je v authorized_keys public klic te stanice a pred nim (na stejnem radku) je nastaveno aby pri spojeni se pustil sleep na hodne dlouho, povoleno jen presmerovani pozadovaneho portu a ruzne dalsi omezeni
pak to funguje tak ze na serveru se pripoji pomoci: ssh localhost -p ten_pridelenej_port_stanice

[petrfm]

Hodil bys sem prosim presne tu konfiguraci toho serveru? Konkretne toto :

 je nastaveno aby pri spojeni se pustil sleep na hodne dlouho, povoleno jen presmerovani pozadovaneho portu a ruzne dalsi omezeni

[nobody]

a co kdyz jde z tve strany o automatickej nevypinatelnej sber dat, pokus o nastoleni totality a cenzury internetu? no dobra...

na serveru:

cd /home/uzivatel_na_serveru/.ssh/
# pokud neni, tak vytvorit authorized_keys
touch authorized_keys
# nastavil bezpecne prava
chmod 600 authorized_keys
# do souboru vlozis publik klic od klienta a pred nej (na zacatek radku s klicem) vlozis:
command="/bin/sleep 4294967201",no-agent-forwarding,no-pty,no-user-rc,no-X11-forwarding,permitopen="localhost:22201" 

na klientu: # skript co kontroluje spojeni a kdyz neni, tak ho nahodi, auto spousteni muzes pridat do cronu

#!/bin/sh
sshcmd="ssh -f uzivatel_na_serveru@server -R 22201:localhost:22 sleep 3"

if [ "$(ps aux|grep "${sshcmd}"|grep -v grep)" = "" ]; then
    # pokud ma spojeni aktivovat bezny uzivatel:
    su -c "${sshcmd}" jmeno_uzivatele_na_klientu
    # nebo pokud by mel spojeni aktivovat primo root:
    "${sshcmd}"
fi

ze serveru se pak pripojis pomoci (port je definovan na klientu i serveru, zmen oboje pokud chces jinej):

ssh -p 22201 localhost

pokud by se spojeni kouslo, muzes na serveru vyvolat preruseni pomoci zabiti procesu sleep, jehoz cislo zjistis pres:

ps aux | grep 4294967201

nebo naprasaka, pokud vis ze jinej sleep bezet nemuze, tak:

killall sleep

a nasledne pockas nez klientuv cron nenahodi skriptem spojeni znovu...

[Beda0]

Pokud nevadí, že to de přes servery třetí strany, tak hamachi. Zadarmo de propojit 5 počítačů. Jak to je s podporou na ARM distribucích si nejsem jistej, ale na RPi jsem ji úspěšně zkompiloval a používám (ArchLinux - z AURu).

[Petr]

Taky můžeš použít IPv6 tunel.

[Andrej]

Da se to nejak zaridit?

Ano, dá. Připoj se k tomu stroji přes IPv6. Pak nebude za NATem.

Jiná možnost: ssh -f -N -R 22222:[::1]:22 server.s.veřejně.dostupnou.ip

Pak stačí připojit se na SSH -p 22222 server.s.veřejně.dostupnou.ip

Všechny podrobnosti jsou v manuálových stránkách. Ale je lepší si tenhle voser ušetřit a použít prostě IPv6.

[Andrej]

Pokud jde o automatický SSH tunel, unit file pro přesně takovou službu může na tom RPi vypadat takto:

[Unit]
Description=SSH in SSH tunnel to Whoknowswhere
After=network-online.target
Requires=network.target

[Service]
Restart=always
StartLimitInterval=0
Type=forking
ExecStart=/usr/bin/ssh \
        -i /root/.ssh/id_rsa.lojza -f -C -N \
        -o ConnectTimeout=10 \
        -o ServerAliveInterval=15 \
        -o ServerAliveCountMax=2 \
        -R [::1]:22222:[::1]:22 \
        -R [2a01:xxxx:yyyy:zzzz::1]:22222:[::1]:22 \
        -R [2a01:xxxx:yyyy:zzzz:1::1]:22222:[::1]:22 \
        -R [2a01:xxxx:yyyy:zzzz:2::1]:22222:[::1]:22 \
        lojza@server.blabla.ble

[Install]
WantedBy=multi-user.target

Nevýhoda je, že v souboru ~root/.ssh/id_rsa.lojza musí být nešifrovaný soukromý klíč uživatele lojza přijímaný serverem server.blabla.ble. Ale jinak to má jenom samé výhody. A lojza může mít hooodně omezená práva; do toho účtu se beztak nikdy nikdo neloguje.

[pavlix]

Jen k těm závislostem, After=network-online.target je samo o sobě špatně, patří k němu ještě Wants=network-online.target, oproti tomu Requires=network.target tam vůbec nepatří, to je target ve smyslu klasického runlevelu. Ale nepopírám, že to může na některém systému v některé konfiguraci fungovat, jen se pak lidi diví, když to fungovat přestane.

[petrfm]

IPv6 jsem ještě neřešil, no díky tvé odpovědi jsem zkoumal, jestli ho můj ISP vůbec podporuje a ne. Takže předpokládám, že bych musel na router nasadit nějaký tunel do IPv6 sítě, že? To ale degraduje tohle řešení pro případ, že bych to chtěl použít v síti, kde nemám možnost získat IPv6 adresy. Pokud se to teda nedá zařídit přímo v tom RPi, instalací nějakého IPv6 tunelu a tím získáním adresy IPv6 jen pro to jediné zařízení.

[mimi.vx]

Pokud máš k dispozici stroj s veřejnou IP, tak to můžeš vyřešit jednoduše nastavením openvpn. Jestli jsi zaregistroval jak o vánocích jezdil na mazací tramvaji vánoční stromek, tak u něj jsem to vyřešil přesně tak. To rpi totiž bylo napájené z drátu, který se na každé točně natvrdo vypínal, takže po zapnutí si to muselo samo nahodit wifi a VPN. Navíc, protože signál nebyl zcela stabilní a kvůli zaruseni to konektivitu občas ztratilo, se to muselo umět samo vzpamatovat a obnovit tunel.

[Karel]

Ja to resim pres sit TOR (www.torproject.org).

Staci nainstalovat tor, ktery je normalne k dispozici v repositarich distribuci, editovat soubor s nastavenim bezne v /etc/tor/torrc a odkomentovat radky s

#HiddenServiceDir /var/lib/tor/hidden_service/

#HiddenServicePort 22 127.0.0.1:22

ve slozce /var/lib/tor/hidden_service/ se pak nachazi soubor s adresou prave vytvoreneho serveru ke kteremu se jde pripojit.

Pripojeni k servru s dalsiho pocitace je pak mozne provest za pouziti torify, napr.:

$ torify ssh user@address.onion

[petrfm]

Tyjo, to se mi líbí to vyzkouším, díky za tip. Postupem času stejně bude potřeba vytvořit internet v internetu, protože ten oficiální začíná stát dost za houby

[nobody]

a tohle si zkusil? funguje?

[petrfm]

Tím popravdě začnu, ale ještě jsem se k tomu nedostal, nenašel jsem čas na zkoušení. Chci si nastudovat tu syntaxi toho ssh, abych věděl, co ten skript vlastně dělá a jak to funguje. Chci to pochopit, aby mi to dělalo radost, né jenom slepě opsat a používat

[petrfm]

Jinak tahle debata mi dala 3 podněty.

1) Zkusit si tvůj skript a využít SSH jako tunel.
2) Že je možné použít TOR jako jednoduchý tunel
3) Začít se zajímat o IPv6, které můj provider neposkytuje, takže nějaké tunelování...

Všechno je to na pár hodin samostudia

[Váš komentář]

http://www.abclinuxu.cz/zpravicky/dve-bezpecnostni-chyby-v-openssh#26

[petrfm]

no... a?

[petrfm]

Jinak ještě jedna věc... použít SSH znamená, vystrčit SSH port do internetu. A vzhledem k tomu, že v SSH každý týden najdou nějakou kritickou díru, se to bojím udělat. Je mi jasné, že VPNka taky bude samá díra, ale už je to něco jiného. Pokud někdo bude dělat robota, který automaticky skenuje IP a porty a testuje chyby na SSH, podaří se mu průnik mnohem rychleji, než bude muset prolomit VPNku, pak oskenovat adresy vnitřní sítě a teprve napadnout zranitelné SSH.

Alespoň tak to vnímám. Nemám prostě k OpenSSH důvěru.

[nobody]

osobne mam v OpenSSH na serveru mnohem vetsi duveru nez v www prohlizece na desktopu, viz napr: ffmpeg chyba ;)

[petrfm]

I to je pravda, koukal jsem do logu chyb OpenSSH a neni to zase takova tragedie, jsou pouzivanejsi a mnohem zranitelnejsi aplikace.

[Josef Kufner]

Asi tak. Udělejme si malé srovnání CVE od roku 2014 včetně, tedy za poslední cca 2 roky:

1. dovecot: 1 CVE entry
2. postfix: 2 CVE entries
3. ejabberd: 2 CVE entries
4. exim: 3 CVE entries
5. openvpn: 4 CVE entries (z toho 3 obsahují slovo "remote")
6. lighttpd: 4 CVE entries
7. nginx: 4 CVE entries
8. isc bind: 12 CVE entries
9. cups: 15 CVE entries
10. openssh: 17 CVE entries (z toho 13 obsahuje slovo "remote")
11. postgresql: 20 CVE entries
12. apache: 149 CVE entries
13. mysql: 151 CVE entries
14. chromium: 286 CVE entries
15. forefox: 301 CVE entries
16. chrome: 303 CVE entries

Toto srovnání neřeší, zda to či ono je zneužitelné vzdáleně a zda to je víc než jen DoS. To by asi bylo mnohem zajímavější, ale asi by bylo mnohem pracnější ta data posbírat.

Vychází mi z toho, že OpenSSH je pro většinu aplikací naprosto vyhovující. A pokud chce mít někdo jistotu, nechť to zpřístupní jen přes OpenVPN.

[pavlix]

Vychází mi z toho, že OpenSSH je pro většinu aplikací naprosto vyhovující. A pokud chce mít někdo jistotu, nechť to zpřístupní jen přes OpenVPN.

IPsec. Ten kernelový. Tam by se v případě bugu v ESP, security policies a security associations alespoň nemuseli dohadovat, jestli se chyba počítá jako chyba v linuxu. :)

...OpenSSH je pro většinu aplikací naprosto vyhovující. A pokud chce mít někdo jistotu, nechť to zpřístupní jen přes OpenVPN.

Kdysi jsem tady někomu psal, že to tak někde používám. A obdržel jsem víceméně dehonestující komentáře, že je to "security by obscurity" a že jsem tudíž lama, která si na něco hraje.

[Josef Kufner]

Z určitého úhlu pohledu to je pravda. Jak SSH, tak OpenVPN by mělo být dostatečně bezpečné samo o sobě. Na druhou stranu tam OpenVPN opravdu přidává jednu bezpečností vrstvu navíc, takže to není jen "by obscurity".

[petrfm]

Používá to stejnou šifrovaci knihovnu, která je taky samá díra, že? Takže nakonec je to zase jen o tom, co nejvíce to zamotat, aby se to útočníkovi zkomplikovalo. Alias security by obscurity absolutně vede, dokud bude ten linux samá díra

[Josef Kufner]

Jo, to to trochu kazí.

[pavlix]

Možná pak budeš lama, která nebude narozdíl od ostatních trpět důsledky bezpečnostní chyby. Nehledě na to, že více úrovní bezpečnosti a security by obscurity jsou dvě naprosto odlišné věci. Pokud teda nepoužíváš na obě služby stejné přístupové klíče.

[petrfm]

...nebo šifrování se stejnýma dírama No, časem se dopracujeme k tomu, že nbusr123 je rozumný poměr mezi bezpečím a pohodlím. Je pravda, že docela často používám heslo 123456

[nobody]

https://xkcd.com/936/

[Lol Phirae]

Je pravda, že docela často používám heslo 123456

... což u dementa tvého kalibru nikoho nepřekvapí ...

[pavele]

Hm, zapoměl dodat, že to heslo zadává do klávesnice na svém hardwerovém tokenu.

Přístup s heslem a přístup s klíčem není úplně to samé.

[pavlix]

Jinak klíčem jsem měl namysli obecný klíč včetně zapamatovatelného ASCII řetězce.

[Václav "Darm" Novák]

Díky za tip, tohle mě nenapadlo :) Používat to na něco datově náročnějšího asi nebude nic moc (třeba scp), ale na ssh super!

[mseed]

Jedna z možností je pomocí IPV6 Miredo