iptables jsou v clanku zmineny spise do poctu. Pokud vim,
pred nejakou dobou na rootu vychazel serial na toto tema.
Pokud znate problematiku iptables, je presmerovani vpodstate
jednoduche rozsireni.
QoS je jina problematika, mozna o ni take nekdy neco napisu (a take o ni, myslim, vysly serialy).
Je-li zadán parametr -L, poslouchá na počítači, ze kterého se spojujete (lokálním), je-li zadán -R, poslouchá na počítači, na nějž se spojujete (vzdáleném).
Pokud na dotyčný port přijde spojení, SSH ho protuneluje svým šifrovaným kanálem ("vedle" normálního přenosu příkazů) a z počítače
!!! na druhém konci tunelu !!!
(v případě -L vzdáleného, u -R lokálního) se spojí ...
Už se těším na pokračování. Ještě by to chtělo probrat aspoň 2 témata :
a) jak dostat do "kanálu" celou podsíť - tedy něco jako ekvivalent "roude add -net ...", ale aby se ty data cestou šifrovaly
b) dtto jako a) + možnost "přihodit" do šifrovaného manálu i IPX pakety (pokud to půjde samozřejmě).
Ja by som potreboval taku vec ze doma na pc (nonstop pripojene na net) mam neverejnu ip a chcem cez ssh tunelovanie na nejaky server aby som sa mohol prihlasovat na moj pc z inetu (pripojim sa na server a z neho na moj pc ked je vytvoreny tunel moj_pc<->server). Je to mozne a bude sa to rozoberat v dalsich dieloch?
Jestli to nekdo dela zadarmo, to fakt netusim. Za penize si muzes koupit ucet na hysteria.sk, tam by to mohlo jit.
Jinak studentici by to mohli v nekterych pripadech pouzivat pres skolni server.
Pracujici (predpokladam IT pracovniky v pohodove firme, ktera upravi firewall a DNAT na prani) by to mohly ject pres firemni kompy.
Jinak se leda zkusit s nekym dohodnout, prakticky by mohl stacit ucet na server v nejakym jailu jenom se ssh.
Ted me napada jedno reseni i bez verejneho serveru, za predpokladu, ze pocitac, ze ktereho se pripojuji (na pocitac bez verejne IP adresy) ma verejnou adresu: kdyz se budu chtit pripojit, zjistim si IP adresu pocitace u ktereho sedim a poslu ji emailem (treba zasifrovanou v GPG) na emailovou adresu, ze ktere automaticky vybira muj domaci pocitac postu. Ten email zpracuje a pomoci SSH se protuneluje k pocitaci u ktereho sedim. Ma to slaba mista, ale teoreticky by to melo fungovat, ne ?
"Na závěr bych jen dodal, že bohužel podle mých zkušeností není přesměrovávání pomocí SSH zcela spolehlivé. Pokud bylo spuštěno, vždy mi po několika dnech spadlo - SSH na portu stále poslouchalo, ale spojení nebylo přenášeno. Možná je tato chyba již opravena, nevím, v poslední době jsem přes SSH nic dlouhodobě netuneloval."
Ja osobne tuneluju denne POP3 a IMAP pres SSH. Jedu z PC v privatni siti za firewallem a NATem na PC s public IP. Bohuzel NAT (zrejme) po urcite dobe shazuje neaktivni spojeni (kde neni traffic), takze jsem to musel vyresit, ze po pripojeni sshckem na stroj se asi kazdych 5 sekund vypisuje datum, takze se spojeni drzi. Bezi mi to perfektne, samozrejme kdyz lehne sit nebo restartuju, tak se spojeni prerusi, ale jinak jede nepretrzite. Akorat nedavno jsem pozoroval, ze mi to nejak prestalo fungovat, kdyz jsem mel v POP3 nejakej divnej email, tak tunel sice zustal, ale neslo pres nej komunikovat (pine nemohl nacist email). mimo tunel ten email cist sel (nebyl problem na POP3 serveru) a po smazani to slapalo zase dobre.
Pro autora:
- Mam za to, ze remote port forwarding (-R) podporuje pouze SSH verze 2.
- Dale jak autor pise, ze muzeme prohlizet nektere firewallem blokovane stranky, napriklad roota, tak
ma pravdu, ale jsou stranky, ktere prohlizet nejdou ... ted mne napada napriklad pokec.atlas.cz ... nevim proc tomu tak je (asi virtualni HTTP server???), pokud autor vi, jak vyresit tento problem, bylo by pekne se s nami o to podelit :) ..
Jinak diky za clanek, seth.
Pokud je to jen kvůli virtuálnímu HTTP serveru, je řešení jednoduché: přidejte si do hosts záznam
127.0.0.1 pokec.atlas.cz
spusťte SSH a do prohlížeče zadejte klasické pokec.atlas.cz. Browser se bude díky záznamu v host tabulce připojovat na lokální adresu, ale v hlavičce HTTP požadavku bude odesílat správně jméno serveru.
A pro sshd snad klíče nepotřebujete? Je to naprosto stejné: démon certifikát resp. klíč mít musí, klient může. Podstatný rozdíl je jen v tom, že stunnel je speciální aplikace pro SSL tunel, zatímco SSH primárně slouží k něčemu úplně jinému a tunelování je jen třešnička na dortu. Tím je dán i výrazný rozdíl ve velikosti programu.
Toho, že by bylo SSH rychlejší (myslíte konfiguraci, zátěž procesoru nebo overhead protokolu?), jsem si nevšiml. Složitost konfigurace je v případě stunnelu verze 3 přibližně stejná, u verze 4 je pro více tunelů konfigurace podstatně jednodušší.
Jeste jeden komentar k SSH portforwardingu.
Umi to protlacit pouze TCP pakety, takze pokud chcete tunelovat UDP, mate proste smulu. Zkousel
jsem kdysi pouzit NetCat, tak aby na obou stranach tunelu konvertoval UDP na TCP and vice versa, ale
mel jsem jen polovicni uspech, diky tomu, ze jak jsem jiz zminoval SSH v1 nepodporuje remote port forwarding. Takze smerem od klienta mi to fungovalo, ale UDP pakety s odpovedi od serveru bohuzel koncily pred vstupem do tunelu :).
Ma nekdo jine pozitivni zkusenosti?? Protlacil nekdo UDP skrz SSH2 obousmerne ? Ja uz nemel nervy instalovat na starickem serveru SSH2, protoze to vyzadovalo vyssi verzi gcc a to zas potrebovalo preinstalovat kernel ... a to cely delat remotely se mi nechtelo.
Zdar, seth.
No dobre, nejsem odbornik na "sitarskou" terminologii, to uznavam, mam spise povrchni znalosti a uznavam, ze o tunelovani jako takove se nejedna. Ale problem zustava, SSH portforwarding
nepodporuje "presmerovani" UDP paketu (rozumnej protlaceni jejich obsahu skrz SSL tunel). Takze me zajima, jestli nekdo neco takoveho resil a byl uspesny ...
Ja som potreboval poslielat zalohu dolezitych dat (cca ~5MB) na iny server v pravidelnych intervaloch. Vyriesil som to vygenerovanim kluca - public key si das na server, kam sa chces pripojit, private key tam, odkial sa chces pripojit. Nenastavis heslo pre pouzitie kluca a bude ti to fungovat aj v skriptoch.
Taktiez sa mozes inspirovat tym, ako prenasat nejake data bezpecne cez SSH:
http://platon.sk/cvs/cvs.php/scripts/shell/ssh-utils/
Jsem ve velke siti LAN se sdilenym pristupem k Inetu. Mam pristup k SSH serveru a chtel bych prez nej vytvorit tunel pro sifrovanou komunikaci ICQ. Bohuzel jsem zatim v zadnem ICQ klientovi neobjevil moznost nadefinovat si vlastni IP a port pro odchozi zpravy, nevite jak to vyresit?
Tohle me napadlo, jenze problem je v tomto. ICQ totiz pouziva nejmene 2 porty. Jeden pouziji hned pri pripojeni pro overeni hesla. login.icq.com TCP/5190 no a ten druhy se pouziva pro odchozi zpravy, jenze ten je pridelen vzdy dynamicky z rozsahu >1023 - 65535 bez moznosti jeho zmeny.
Takze pravidlo mam nastaveno takto: Miranda se pripojuje na localhost port 5190 toto prevezme SSH2 tunel a preposle na port 5190 login.icq.com
Kdyz se ale podivam snifferem tato doprava neni vubec sifrovana. Pritom v pravidle bych problem mit nemel protoze podobna pouzivam i pro postu a tam se sifruje (sniffer).
Prikladam vypis z konzole vubec se mi nelibi treti polozka tunelu:
Proto Místní adresa Cizí adresa Stav PID
TCP 0.0.0.0:4579 0.0.0.0:0 NASLOUCHÁNÍ 1512 - Miranda
TCP 192.168.1.1:4579 205.188.10.4:5190 NAVÁZÁNO 1512 - Miranda
TCP 0.0.0.0:5190 0.0.0.0:0 NASLOUCHÁNÍ 2012 - Tunel
Vypadato jako by Miranda tunel naprosto obchazela
mam rovnaky problem (uz vyrieseny). na vzdialeny server som nainstaloval dante socks proxy, pocuvajuce na vnutornom interface (port 1080). z windows masiny za firewallom tam mam forwardovany port 1080 via ssh (openssh for win32) a v icq mam nastaveny SOCKS5 server na localhost:1080.
Ahoj,
ad1)clanek je supr
ad2)zrovna tedka resim nasledujici problem:
nase firma me nekolik pobocek,kde pouzivame
jako firewall linux (iptables + proxy arp),za fw
je cisco jenz privadi internet. Jelikoz pobocky se intenzivne pripojuji na centralu ,kde jsou servery(hlavne imap,pop3,ms sql) ,tak se snazim usetrit linky komprimaci.Zkousel jsem
http://www.vtun.sourceforge.net ,ale vzdycky nejak narazim na proxy arp a nedari se mi to rozchodit. Myslite ,ze tunel pres ssh s komprimaci na patricnych portech je to prave orechove? Neznate nekdo lepsi reseni? U toho vtun se mi libilo to ,ze to ma umet komprimovat celkovy provoz. Kdo mi poradi ,ma u me min pivo :-). Dik hanz
Aha, tak mozna to tak jisty neni :).
Kazdoapdne je potreba zarucit, aby
PuTTy navazoval jen SSH2 spojeni ... takze si overte jestli vas nahodou neprepne do SSH1 tim, ze povolite pouze SSH2 spojeni ... a pokud to i tak nepujde, tak sup buq report na PuTTy a nebo SSH ... :) Mam takovy dojem, ze v jiste verzi OpenSSH nejaka chybka tykajici se remote port forwardingu byla ...
Jak overujete, ze na tom portu poslocha nebo ne ? Jen z logu? A nebo zkousite neco poslat? Napriklad pomoci netcatu ... ?
Z dokumentace PuTTy k remote portforwardingu:
The ‘Remote ports do the same’ option does the same thing for remote-to-local port forwardings (so that machines other than the SSH server machine can connect to the forwarded port.) Note that this feature is only available in the SSH 2 protocol, and not all SSH 2 servers support it (OpenSSH 3.0 does not, for example)
TAKZE TO DOST ZAVISI NA IMPLEMENTACI SSH SERVERU!
Ted mne napadlo, jak tento nedostatek obejit:
pouzijte remote port forwarding na portu1 a na remote stroji pustte netcat at vam posila data z portu2 na localhost:port1.
Ve vasem pripade - port2 - 8000, port1 - libovolny volny port.
Nevim jak pomale to bude, ale pak uz by to melo jit.
Je to trochu stranou tématu tunelování, ale s SSH to souvisí.
Potřeboval bych, aby skript na SSH klientu (na Win - PuTTY?) provedl na vyvolání automatické přilogování a výkon určitých příkazů na počítači s běžícím sshd.
Zcela polopatě - potřebuji, aby uživatel pécéčka byl schopen provést shutdown serveru, aniž by k němu fyzicky chodil psát na klávesnici a aniž by se musel unavovat s pamatováním nějakého vstupního hesla atp.
Věděl byste někdo něco jak to naskriptovat?
Musíte si přes ssh-keygen vygenerovat veřejný a privátní klíč. Veřejný nacpěte na serveru do domovského adresáře daného uživatele do souboru ~/.ssh/authorized_keys, soukromý uložte na klienta, a pak zavolejte
ssh -i soubor_s_private_klicem user@server "prikazy"
Pokud používáte PuTTY, stáhněte si ze stejného webu plink.exe a puttygen.exe, přes puttygen si zkonvertujte soukromý klíč do formátu, který bude PuTTY schopno zpracovat (stačí natáhnout ze souboru a znovu uložit) a spouštějte
plink.exe -i soubor_s_private_klicem user@server "prikazy"
POZOR! Obvykle (minimálně u základního nastavení Debianu ;-) musí být vlastníkem authorized_keys daný uživatel a musí byt jediný, kdo má k souboru přístup (tedy ani group, ani other), jinak bude tento způsob autorizace odmítnut (kdyžtak se podívejte do logu, SSH tam obvykle vypíše, proč se mu to nelíbilo - to se týká i portu na Windows). Tahle vlastnost se nechá vypnout v sshd_config nastavenim "StrictModes" na "no", ovšem samozřejmě je to na úkor bezpečnosti.
Jojo,nechavat heslo na ucet ktery muze shodit server (vetsinou root),to je neco ;-) Stejne jako klic...ale pro klic je dobre,ze mu lze nastavit jaky prikaz se ma spustit (viz man authorized_keys), zadne vnuceni jinych prikazu se nekona. Jde i omezit z jake IP se dany klic muze hlasit (ale pozor, v OpenSSH v tomhle byl byg). Je toho hodne co lze s klici vykouzlit,ale nesmi se to prehnat ;)
Jsem si vědom, rád bych to dopiloval. Za prvé nějaký účet (ne root), co by mohl pouze shutdown a jinak nic (ani přes konsoli)? Jde to vůbec?
Za druhé, aby se osoba takového účtu mohla přihlásit pouze přes určitý síťový interface (zevnitř LAN), méně ideální je určit pool povolených IP adres. Zároveň bych ale chtěl nechat plné SSH pro jiné účty i z jiných iface, takže filtrací sshd to udělat nejde.
Je to tak napůl. Doma mám fyzický přístup přes štafle na polici pod stropem v předsíni (všude jinde ten hučák vadí) a než jimi pořád verglovat tak je jednodušší to schazovat přes ssh a pak vypínačem, co mi visí dolů. Pro jiné doma by to chtělo něco co nejjednoduššího a aby se mi v tom náhodou nerýpali. S těmi klíči s povolenými příkazy to myslím je docela přiměřené.
Uvažuji ale i pro použití do práce a tam by přístup byl, takže i tahle rada C-A-Del je dost použitelná a díky za ní.
Mimochodem, párkrát server doma pochopitelně někdo vypnul i za běhu a stejně se nic nestalo. Mám pocit, že ext3 je už docela odolný. Přijde mi to podobně odolné jako JFS na AIXu. Jsou nějaké zkušenosti s divokým vypínáním?
zdravim..
zajimalo by me, jestli existuje nejake reseni, jak spojit takto pocitace: [1]NAT <--> [3]inet <--> NAT[2] tak, aby se pocitac [1] tvaril, jakoby byl v siti, ve ktere je pocitac [2]? Za dodrzeni omezeni, ze neni mozne zasahovat do nastaveni site.
sam jsem spachal takove asi ne moc ciste reseni, kde je mezi [1] a [3] ssh tunel a mezi [3] a [2] takova divna javova aplikace vlastni tvorby, ktera spojuje oba konce na [3] a zaroven provozuje socks proxy na [2].
nezna nekdo nejakou lepsi cestu?
Predevsim pro wifi site (treba CZfree.Net) by se velice hodily komprimovane tunely, ktere by dokazali zvysit propustnost a snad i spolehlivost zaruseneho wifi spoje. Jak takovy tunel realizovat a jaky komprimacni program pouzit? Slysel jsem, ze nejrychlejsi a nejlepsi je Bzip2 (ale winrar 3.20 komprimuje na woknech lepe :-), dale by me zajimalo, zdali by slo udelat jakousi virtualni komprimovanou (pod)sit, kde by se nekomprimovaly cele packety, ale pouze datova cast, takze pokud by bylo za sebou vice linuxovych routeru, ktere by byly nakonfigurovane na komprimovane tunely (a byly soucasti one virtualni kompr. site), nemusely by prichazejici data rozbalit a znovu zabalit na odchodu, ale rozbalili by se az na poslednim stroji, ktery by byl posledni v one virtualni "komprimacni siti".Proste vytvorit mnozinu primo spojenych (nebo i neprimo) routeru,ve ktere by datova cast packetu putovala zabalena a rozbalila by se az na hranici teto mnoziny, nebo u adresata nachazejiciho se uvnitr.Neni jiz takova vec hotova?
Pro informaci - na nezarušeném wifi mi IPSec (FreeS/WAN pod Linuxem) jel v pohodě, zvládal dokonce i přístup z WinXP, i když v nich nešlo pověsit na pakety došlé přes IPSec firewall, což považuji za velkou chybu (windows, samozřejmě). Mezi dvěma linuxovými mašinami mi spojení během cca půldruhého měsíce, co jsem to měl nastaveno, nespadlo ani jednou, ovšem signál byl většinou velmi dobrý. Měl jsem takhle řešený tunel skrz wifi do malé síťky v protějším domě a dál do Internetu. Navíc jsem měl v netfilteru povolený provoz pouze přes IPSec, takže případný dobrák, který by se tam chtěl přes wifi nabourat, neměl moc šanci (pokud by tam nebyl nějaký bug, samozřejmě), i kdyby prolomil WEP (ten jsem nakonec úplně vypnul).
Komprimace jde zapnout, ale jak moc je účinná, to, přiznám se, nevím. Maximální rychlosti, kterou jsem s tím dosáhl, byly cca 2.5Mbit/s, dál to nebrzdilo ani tak wifi, jako spíše pomalý procesor v počítači naproti, který nestíhal rychleji šifrovat (nějaká K6 na frekvenci kolem 200MHz, nevím to přesně, pak mi jí ukradli).
Předpokládám, že FTP server je v intranetu a PC v tomtéž. Budete mít asi potíž dostat se do toho intranetu, odděluje-li ho nějaká firewall.
Jinak nejjednodušší by asi bylo na to PC instalovat FTP proxy a chodit přes ní. Chtělo by to více info jak to vypadá, co kde běží (na tom PC a co doma) a co je po cestě. Zda máte nějaký vliv na ten FTP server a případně tam něco dát atp. Třeba to lze udělat celé i nějak jinak.
FTP server je na Internetu, ma nejakou IP (napr. 145.31.xx.xx), ale je omezen v pripojeni pouze na PC s IP zacinajici 145.31. Jina odmita. Mam ucet na PC, ktere ma IP 145.31.yy.yy (ale zadna velka prava -> proxy instalovat nemuzu) a doma klasicky dial-up. Chod FTP ovlivnit taky nemuzu. Doma i na PC je Linux. O serveru nic nevim, stejne tak jako o vecech (ceste) mezi.
To je těžké, pokud na PC nic nemůžete?!
Pokud se na něj lze dostat aspoň terminálem (ať již telnet nebo SSH), tak si nainstalujte na svůj stroj doma ftp server (bývá součástí asi všech distribucí) s povoleným uploadem. Pak se z domu přihlaste nějakým terminálem na PC, downloadujte ftp z veřejného serveru na své diskové místo na PC, přelogujte ftp k sobě domů a pak si to uploadněte domů. Ještě si nějak musíte zjistit, jakou IP adresu po dial-up připojení váš domácí stroj právě má. Je to ruční práce, ale vyžaduje to minimum věcí na tom prostředkujícím PC.
Dobrý den,
prosím všechny odborníky zde - neukamenujte mne, ale mohl by mi prosím někdo vysvětlit polopatě jak provést následující:
doma: Linux-FW s verejnou IP, za ni jsou 2 stanice s neverejnou WinXP
v praci: Linux-FW, lezi na ni (provizorni) postak
Potreboval bych z tech XPcech stahovat postu z prace. Jak to provest a na jakou IP nastavit Outlook - pop3?
Diky za kazdou radu.