[kecy]
Disclaimer (téměř kopie disclaimeru z minulého dílu, který na prudiče zdá se zabral :)): Tento článek čtete na vlastní nebezpečí. Pokud se vám první (druhý, n-tý..) díl nelíbil, mohu vás ujistit, ze se vám nebude líbit ani tento, ale vaše poznámky v diskusi budou ignorovány, protože jste byli varováni a měli jste se poučit. Naopak pokud se vám to minule líbilo…etc., to už znáte, jinak byste tady přeci nebyli :).
K minulému dílu: Děkuji za přínosné poznámky v diskusi. Za uhodnutí identity artaxe si lízátko vysloužili Jan Kulveit a Petr Andrs, já si to s nimi nějak vyřídím :). Co se týče domácího úkolu č. 2 (šlo o problém, co s různými klíči, když přistupujeme na tunely vedené několika porty daného stroje), Lace radí parametr HostKeyAlias, což opravdu funguje, následuje demonstrace použití :) (jablonecká je sousední router v síti CZFree, zireael můj router a chroustalka moje workstation za maškarádou a firewallem, na kterou vede tunel přes zireaelčin port 2222, první připojení spojené s ukládáním klíčů již proběhlo, je škoda místa to sem pastovat, protože byly použity úplně stejné příkazy).
[johanka@jablonecka johanka]$ ssh -o 'HostKeyAlias vlastovka' 10.33.0.38 Enter passphrase for key '/home/johanka/.ssh/id_dsa': [johanka@zireael johanka]$ exit Connection to 10.33.0.38 closed. [johanka@jablonecka johanka]$ ssh -o 'HostKeyAlias chroustalka' -p 2222 10.33.0.38 Enter passphrase for key '/home/johanka/.ssh/id_dsa': johanka@chroustalka:~$
Petr Vagera radí nacpat do authorized_keys násilím všechny klíče, které potřebujete, pak bude vždy matchovat alespoň jeden a OpenSSH už nebude mít kecy. To můžete snadno udělat tak, že se jednou připojíte na každý port s použitím aliasu a poté ručně zeditujete known_hosts tak, že všechny aliasy na začátcích řádků s příslušnými klíči přejmenujete na skutečný název/IP stroje. Každopádně tedy obě metody fungují a já chlapcům děkuji :).
Další důležité poznámky v diskusi se týkaly práv – jak jsem si později i sama ověřila, je třeba ohlídat práva nejen směrem k čitelnosti potřebných souborů, ale i z druhé strany, tedy aby příslušné strategické soubory a adresáře (authorized_keys, .ssh*, ale i home…) nebyly zapisovatelné pro skupinu nebo nedejbože pro všechny, ssh pak klíče z vlastního paranoidního přesvědčení nepoužije, ale odmítne říci, proč.
2.5 :) akční paranoidní postup – klíče mezi OpenSSH a SSH
Na začátek trocha ideologie: OpenSSH a SSH používají různé formáty klíčů (OpenSSH a SECSH), které na sebe navzájem naštěstí umí převádět ssh-keygen z OpenSSH. Nezvládlo mi sice převést privátní SSH klíč (defaultního šifrování DSA) na OpenSSH verzi (kdyby byl bez passphráze, šlo by to), ale to nás zase tolik nedrásá, protože za normálních okolností potřebujeme převádět pouze public klíče, a ty jdou bez problémů (DSA i RSA, oběma směry).
Velmi zkrácený postup, užitečný pro hrubý přehled o tom, co vlastně děláme, a pro ty, kdo důvěrně znají klíčové postupy pro oba druhy ssh (podrobný návod bude následovat):
[/kecy][data]
Klient OpenSSH a server SSH: vygenerujeme na klientovi klíč, provedeme patřičné kroky, jako bychom byli OpenSSH only, public část klíče převedeme pomocí ssh-keygen -e do formátu SECSH, zkopírujeme na server, a tam už se chováme, jako bychom byli SSH only.
Klient SSH a server OpenSSH: vygenerujeme klíč na klientovi, provedeme patřičné kroky, jako bychom byli SSH only, zkopírujeme public část klíče na server, tam ho převedeme pomocí ssh-keygen -i do OpenSSH formátu, a dále pokračujeme, jako bychom byli OpenSSH only.
[/data][kecy]
Jak vidíte, je to snadné až triviální, ale než jsem na to přišla…:) Tady je názorný návod, užitečný zejména pro ty, kteří jedno z použitých ssh vidí poprvé v životě; vetšinu věcí (práva, jména souborů apod.) už nebudu zbytečně rozpitvávat, najdete si to v minulém dílu v sekci příslušného ssh.
Tentokrát použiju reálná jména počítačů :), aby v tom nebyl zmatek. Atrey má OpenSSH, arc SSH. Pokud si je budete plést, napomůže logická úvaha – předminule jsem říkala, že SSH používá pouze johanka, a je asi zřejmé, který počítač z těchto dvou je johančin ;).
[/kecy][data]
Klient OpenSSH a server SSH
V roli klienta je zde tedy atrey, v roli serveru arc.
johanka@atrey:~$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/johanka/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/johanka/.ssh/id_dsa. Your public key has been saved in /home/johanka/.ssh/id_dsa.pub. The key fingerprint is: c3:17:7c:30:b3:ea:3d:24:36:e7:97:ee:d1:c7:db:b9 johanka@atrey
vygenerovali jsme si klíč
johanka@atrey:~$ cd .ssh johanka@atrey:~/.ssh$ ls id_dsa id_dsa.pub johanka@atrey:~/.ssh$ ssh-keygen -e -f id_dsa.pub > johanka@atrey.closed.pub
převedli jsme public klíč do formátu SECSH
johanka@atrey:~/.ssh$ scp johanka\@atrey.closed.pub johanka@arc:.ssh2/. johanka@arc's password: scp: warning: Executing scp1. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). lost connection johanka@atrey:~/.ssh$
A v tuto chvíli máme problém, o kterém si povíme někdy příště :). Zatím to vyřešíme tak, že se nalogujeme na server a použijeme jeho scp (ve směru SSH->OpenSSH již problém není)
johanka@atrey:~/.ssh$ ssh arc johanka@arc's password: Last login: Mon Mar 31 2003 17:53:44 +0200 from atrey.karlin.mff.cuni.cz No mail. johanka@arc:~$ cd .ssh2 johanka@arc:~/.ssh2$ scp johanka@atrey:.ssh/johanka\@atrey.closed.pub . johanka@atrey's password: johanka@atrey.closed.pub | 716B | 0.7 kB/s | TOC: 00:00:01 | 100%
konečně jsme zkopírovali veřejný klíč z klienta
johanka@arc:~/.ssh2$ vim authorization
Do souboru authorization napíšeme/přidáme řádek
Key johanka@atrey.closed.pub "authorization" [New] 1L, 29C written johanka@arc:~/.ssh2$ exit logout Connection to arc closed. johanka@atrey:~/.ssh$ ssh arc Enter passphrase for key '/home/johanka/.ssh/id_dsa': Last login: Mon Mar 31 2003 18:07:04 +0200 from atrey.karlin.mff.cuni.cz No mail. johanka@arc:~$A vidíte, funguje to :)
Klient SSH a server OpenSSH
V roli klienta arc, v roli serveru atrey
johanka@arc:~$ ssh-keygen2 Generating 2048-bit dsa key pair 7 o.oOo..oOo.o Key generated. 2048-bit dsa, johanka@arc.ms.mff.cuni.cz, Mon Mar 31 2003 18:21:14 +0200 Passphrase : Again : Private key saved to /home/dolezalova/.ssh2/id_dsa_2048_a Public key saved to /home/dolezalova/.ssh2/id_dsa_2048_a.pub
právě jsme si vygenerovali klíč
johanka@arc:~$ cd .ssh2 johanka@arc:~/.ssh2$ ls id_dsa_2048_a id_dsa_2048_a.pub random_seed johanka@arc:~/.ssh2$ mv id_dsa_2048_a johanka@arc johanka@arc:~/.ssh2$ mv id_dsa_2048_a.pub johanka@arc.pub johanka@arc:~/.ssh2$ vim identification
Do souboru identification napíšeme řádku
IdKey johanka@arc "identification" [New] 1L, 18C written johanka@arc:~/.ssh2$ scp johanka\@arc.pub johanka@atrey:.ssh/. johanka@atrey's password: johanka@arc.pub | 1.2kB | 1.2 kB/s | TOC: 00:00:01 | 100% johanka@arc:~/.ssh2$
zkopírovali jsme public část klíče na server
johanka@arc:~/.ssh2$ ssh atrey johanka's password: Authentication successful. You have mail. Last login: Mon Mar 31 18:28:52 2003 from arc.ms.mff.cuni.cz johanka@atrey:~$ cd .ssh johanka@atrey:~/.ssh$ ls johanka@arc.pub johanka@atrey:~/.ssh$ ssh-keygen -i -f johanka@arc.pub > johanka@arc.open.pub johanka@atrey:~/.ssh$ cat johanka@arc.open.pub >> authorized_keys johanka@atrey:~/.ssh$ exit logout johanka@arc:~$ cd .ssh2 johanka@arc:~/.ssh2$ ssh atrey Passphrase for key "/home/dolezalova/.ssh2/johanka@arc" with comment "2048-bit dsa, johanka@arc.ms.mff.cuni.cz, Mon Mar 31 2003 18:21:14 +0200": Authentication successful. Last login: Mon Mar 31 18:33:25 2003 from arc.ms.mff.cuni.cz johanka@atrey:~$
A vidíte, taky to funguje :)
[/data][kecy]
Troubleshooting
Tady vás odkážu na minulý díl (a poznámky k němu na začátku dílu dnešního), protože nic nového zde neprovádíme. Akorát si dejde pozor na možnou záměnu adresářů .ssh a .ssh2! Na každém počítači budete používat jiný, na OpenSSH .ssh, na SSH .ssh2.
Ntý akční (ale nepříliš paranoidní) postup – jak se přihlásit z ciziny
Nebudeme se zde zatím nijak zvlášť zabývat bezpečností, jako spíš tím, jak se vůbec přihlásit (via ssh) na svůj oblíbený unixový účet z pochybného počítače v palmové chýši, který má jen wokýnka (nejlépe čínskou verzi), o ssh klientovi si může nechat zdát, ven ma povolené pouze http, floppy mechanika nejde použít a obsluha samozřejmě nemá páru, o co jde, případně se s ní vůbec nedomluvíte.
V následujícím textu budu BÚNO předpokládat, že se jedná o Windowsy a nemáte na nich administrátorská práva. Částečně vycházím ze svých vlastních zkušeností z loňského léta, kdy jsem se domnívala, že na univerzitě v Itálii bude rozumné připojení, podcenila preventivní přípravu…a nebylo :).
Problém č. 1 – ssh klient: Pokud i nějaký ssh klient najdete, nemůžete předpokládat, že je spolehlivý, tudíž je třeba mít vlastní.
PuTTY má tu ohromnou výhodu, že ho nemusíte instalovat, stačí ho pouze spustit, klidně i přímo z webu. Ideální je vytvořit si před cestou vlastní webovskou stránku s užitečnými utilitkami ke stažení/spuštění, např. PuTTY, PSCP apod., budete tak mít jistotu, že použitý klient je zaručeně neškodný. Zapomenete-li na to, můžete buď použít stránku Petra Pajase :) jako já, nebo si prostě nechat v Googlu vyhledat „putty.exe“ a spustit. Pokud webu nedůveřujete, vozte si s sebou potřebné věci na disketě.
Můžete také použít některý z javovských klientu, kterých se dá na webu najít spousta (namátkou isnetworks.com/ssh, java-ssh nebo sshtools.com, pozor, některé podporují pouze protokol 1), jejich výhodou je přenositelnost, takže je můžete použít i na nějaké pochybné architektuře s pochybným operačním systémem (OK, do toho x86 s Wokny asi taky zapadá :)), ale browser musí umět a mít povolenou Javu.
Bezpečnostní minimum: Ideální je asi použít OTP ( podrobnosti na Kryptě, díky za link v diskusi k prvnímu dílu), nicméně když to neuděláte, asi se nic nestane (= mně se ještě nic nestalo :)), je však vhodné alespoň mít někde poznamenaný fingerprint serveru (třeba na té webovské stránce, kam jste si vystavili klienty) a raději se přímo logovat pouze na nějaký méně důležitý účet a na skutečné místo určení až z něj (případný útočník většinou (i když ne vždy) odchytává pouze první heslo).
Problém č. 2 (horší) – ořezávání trafficu: Klient ne a ne navázat spojení, ale web běží, takže připojení k síti je v pořádku? V lepším případě jste za firewallem, který pouze zahazuje konexe na nevhodné porty, v horším za http proxy.
Firewall: Zde je řešení jednoduché, ale potřebujete spolupráci na druhé straně (v lepším případě preventivní přípravu před cestou). Je třeba, abyste na počítači, na který se chcete připojovat, pustili (nebo někoho nechali pustit) ssh daemona na příslušně pofidérním portu, tedy pokud je ven povolena např. telnetí konexe (to se nam opravdu stalo, telnet povolili a ssh ne, čehož logika mi poněkud unikla :)), pustit sshd na portu 23, pokud jsou povoleny pouze hhttpí konexe, pustit sshd na portu 80. V PuTTY potom akorát zadáte číslo cílového portu, a pokud se např. při zadání 23 automaticky překliklo na telnet, překliknete zpátky na ssh a je to. Javovské klienty by také měly umět připojit se na libovolný port, ostatně to umí snad každý rozumný ssh klient.
O obcházení proxy a o dalších věcech, co jsem vám průběžně naslibovala, si povíme někdy příště, ale neslibuju, že to bude za týden, nějak nestíhám :(. Mějte se pěkně, děti.
Extra special thanx to: (jako vždy) Lace, Qiq
