LinuxON.sk - Linux a OpenSource portál

** Diskusia k článku: SSH a Linux **

SSH je dôležitou súčasťou dnešného internetu. Tento článok Vám ozrejmí jeho fungovanie a základy práce s balíkom OpenSSH.


Čo to je


SSH (Secure Shell) je sieťový protokol určený na vzdialenú správu počítača, pričom všetky dáta sú posielané a prijímané šifrovane. Vznikol ako náhrada za telnet, rlogin a podobné protokoly, kde sa všetko (vrátane hesla) prenášalo v textovej podobe a po odchytení boli údaje ľahko zneužiteľné.






OpenSSH


OpenSSH je balík obsahujúci SSH klient a server. Je súčasťou projektu openBSD, takže netreba hovoriť, že bezpečnosť je priorita (aj keď v minulosti bolo pár nepríjemných chýb).
Domovská stránka OpenSSH je www.openssh.org. V dobe písania tohto článku je najnovšia stabilná verzia 5.3, nič ale nepokazíte inštaláciou verzie rady 4. Po stiahnutí a rozbalení balíka OpenSSH skompilujete tradične, configure skript, make, prípadne make install. Odporúčam nepúšťať configure len tak ledabolo, prečítajte si help (configure --help). Zdajte aspoň miesto, kam sa má nainštalovať a umiestnenie konfiguračných súborov. Tradične je to /usr/ a /etc/ssh/. Proces kompilácie a inštalácie teda spustíte nasledovnou sekvenciou príkazov.


$ ./configure --prefix=/usr/ --sysconfdir=/etc/ssh/
$ make
# make install


Je ale veľmi pravdepodobné, že to potrebovať nebudete, nevidel som distribúciu, čo by OpenSSH nemala v repozitároch. Niektoré dokonca aj v štandardnej inštalácií.


Ako to funguje


Nie je na škodu mať akú takú vedomosť o tom, ako SSH približne funguje. Ak vás to nezaujíma, môžete túto časť preskočiť. Nasledujúce informácie sa týkajú verzie SSH2. Nie som žiadny kryptológ, tak to berte s rezervou .


Šifrovanie


Komunikácia pomocou SSH, ako už bolo spomenuté, prebieha šifrovane. To, ako celý šifrovací proces prebieha, sa pokúša ozrejmiť nasledovný odstavec. Samozrejme nezachádza do technických detailov šifrovacích algoritmov, to je vysoko mimo rozsah článku.

SSH2 využíva kombináciu asymetrického a symetrického šifrovania. Asymetrická šifra je použitá len a len na prenos kľúča použitého pre symetrické šifrovanie. SSH server má svoj verejný a privátny kľúč (kľúč je len súbor s dátami, nepredstavujte si nič abstraktné ). Zatiaľ čo verejný kľúč poskytuje server hocikomu, privátny kľúč je bezpečne uložený na servery, kde k nemu má prístup len administrátor.

Celý princíp asymetrickej šifry spočíva v tom, že dáta zašifrované verejným kľúčom sa dajú odšifrovať len privátnym. Keď sa klient prvý raz pripojí na server, server mu pošle svoj verejný kľúč, klient si ho uloží pre neskoršie použitie a zašifruje ním kľúč, ktorý bude neskôr použitý na symetrické šifrovanie. Takto zašifrovaný kľúč pošle serveru, ten si ho odšifruje svojim privátnym kľúčom. Teraz pozná aj server aj klient kľúč a začína komunikáciu symetrickou šifrou. Symetrická šifra sa, ako ste už mohli postrehnúť, líši od asymetrickej tým, že narozdiel od dvojice kľúčov (verejný a privátny) sa používa len jeden kľúč. Symetrické šifry sú všeobecne bezpečnejšie.

Do celej teoretickej skladačky nám ešte niečo chýba, a to konkrétne šifry použité na zabezpečenie spojenia. Na asymetricky šifrovanú časť spojenia sa používajú algoritmy RSA a DSA. Na symetrickú časť máte na výber z viacerých a to (citujem s manuálu) "3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc, aes128-ctr, aes192-ctr, aes256-ctr, arcfour128, arcfour256, arcfour, blow‐fish-cbc, and cast128-cbc". To, aká šifra bude použitá, môžete ovplyvňovať ako na strane klienta, tak aj na strane servera. Väčšinou to ale nebude potrebné, keďže openssh sa dokáže rozhodnúť sám pre tú "najlepšiu"

Nesmie chýbať názorný obrázok. zelena časť znázorňuje kroky, kde sú prenášané dáta šifrované ešte asymetrickou šifrou, červená analogicky symetrickou.



Autorizácia


Keď už je vytvorený šifrovaný komunikačný kanál, môže začať proces autorizácie. SSH2 poskytuje viac spôsobov autorizácie, my si popíšeme dva najčastejšie.


Autorizácia heslom


Klasický spôsob všetkým iste známy. Server si po pripojení klienta vypýta heslo a po kontrole spustí vybraný shell uvedený v /etc/passwd. OpenSSH môže, ale nemusí používať systém PAM.


Autorizácia kľúčom


Tak ako ste pre server jednoznačne identifikovaný svojím menom a heslom, je tomu aj v prípade kľúčov. Klient vygeneruje sadu kľúčov, privátny a verejný. Privátny je opäť bezpečne uložený na klientskom počítači, zatiaľ čo verejný je uschovaný na serveri. Server potom pri pripojení zašifruje nejaké dáta verejným kľúčom, ktorý ma k dispozícií a pošle ich klientovi. Ten, ak má k dispozícií privátny kľúč, môže dáta rozšifrovať a poslať späť serveru. Ten potom, ak obrží správne dáta usúdi, že klient ja autorizovaný a spustí shell.


Poďme sa pripojiť


Určite sa už po tej teoretickej omáčke chcete konečne pripojiť a spravovať svoj počítač vzdialene. Tak poďme na to. Prvý krok bude, ak to za Vás nespravil balíčkovací systém, naštartovať sshd. Konkrétny postup sa líši od distribúcie po distribúciu, tak si uvedieme aspoň pár príkladov. Všetky príkazy treba spustiť ako root

• Debian/Ubuntu

/etc/init.d/ssh start

• ArchLinux

/etc/rc.d/sshd start

• Slackware

/etc/rc.d/rc.sshd start


Ak server beží, pribudne Vám v procesoch sshd počúvajúci na porte 22. Obidvoje si môžeme overiť príkazom

netstat -tlpn

Ak ssh beží, mal by sa medzi výstupom nachádzať riadok podobný tomuto



tcp        0      0 0.0.0.0:22              0.0.0.0:*   
LISTEN      3094/sshd




Skúsme sa teda prihlásiť. Na to aby ste sa mohli prihlásiť aj mimo lokálnej siete, potrebujete samozrejme verejnú IP, preto teraz len overíme funkčnosť OpenSSH a pripojíme sa z lokálneho počítača. OpenSSH klienta spustíte príkazom ssh, ktorého základná syntax je ssh uzivatel@host, pričom uzivatel je užívateľské meno a host doména/ip adresa počítača, na ktorý sa chceme prihlásiť. Prihlásme sa teda na lokálny počítač.

ssh janko@localhost

Pri prvom pripojení nás server prekvapí hláškou podobnej tejto

The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 20:03:45:4c:f4:09:e3:5c:21:2a:ea:bf:79:82:3c:f5.
Are you sure you want to continue connecting (yes/no)?

Kedže ste sa k serveru ešte nikdy nepripojili, klient ešte nemá v databáze verejný kľúč servera. Napíšte teda yes a stlačte enter. Klient si uloží kľúč do ~/.ssh/known_hosts. Server pokračuje vypýtaním hesla, zadajte ho teda. Heslo sa tak, ako sme na unixových systémoch zvyknutí, nebude zobrazovať. Po overení správnosti hesla ste prihlásený a môžte robiť, čo chcete (samozrejme to vyžaduje znalosť práce so shellom). Popísané kroky ilustruje nasledovný obrázok








Konfigurácia


Kedže štandardná konfigurácia nemusí vždy vyhovovať, ukážeme si, ako OpenSSH prispôsobiť k obrazu svojmu.

OpenSSH sa štandardne konfiguruje pomocou súborov v /etc/ssh/. Pre server je to sshd_config a pre klient ssh_config. Súbory majú formát Direktíva hodnota pričom, jednotlivé položky sú oddelené riadkami. Cieľom článku nie je popísať všetky možné možnosti OpenSSH, preto sa zameriame len na základné nastavenia.


Zmena portu


Port 22 vystavený internetu sa do pár minút premení na strelnicu rôznych botov skúšajúcich slovníkové heslá na účty root, test a podobne. Preto nie je od veci premiestniť sshd na iný port. O to sa v konfiguračných súboroch stará direktíva Port. Štandardne je nastavená na číslo 22. Prepíšeme ju teda na nejaké vyššie, neobvyklé číslo, povedzme 4389. Súbor ssd_config teda bude obsahovať riadok

Port 4398

Teraz musíme prinútiť klienta, aby sa na ten port pripájal tiež. Opäť to môžeme dosiahnuť pridaním rovnakého riadku do ssh_config. Správnejšie bude ale povedať to klientovi parametrom pri spustení. Konkrétne ide o parameter -p. Na server počúvajúci na porte 4398 sa teda pripojíme príkazom

ssh -p 4398 uzivatel@host


Nastavenie protokolu

Povolenie prvej verzie SSH protokolu môže znamenať bezpečnostné riziko. Preto sa uistite, že ssh_config aj sshd_config obsahjú riadok

Protocol 2


Autorizácia kľúčom

Autorizácia kľúčom je pohodlnejšia ako vyťukávanie hesla, problém je v tom, že zatiaťčo heslo je len vo vašej pamäti (dúfajme ), kľúč sa nachádza na disku, kde je ľahšie ho ukradnúť. Kľúč si síce môžete takisto ochrániť heslom, problém je, že sa potom  stráca pohodlnosť takéhoto riešenia, existuje však možnosť vyhnúť sa častému zadávaniu hesla pri použití kľúča pomocou nástroja ssh-agent. Ten si možno popíšeme v pokračovaní, ak nejaké bude.

Aby ste sa mohli prihlasovať pomocou kľúča, musí sshd_ config obsahovať riadok

PubKeyAuthentication     yes


Ďalším krokom je vygenerovanie dvojice kľúčov (verejný a privátny). RSA kľúče vygenerujeme príkazom

ssh-keygen -t rsa


Program si vypýta miesto, kam má uložiť kľúče, keďže nám vyhovuje štandardné umiestnenie, tak len stlačíme enter. Ďalej si vypýta heslo, ktoré bude použité na prístup k privátnemu kľúču. Teraz je na Vás, či niečo zadáte alebo nie, bezpečnejšie samozrejme bude, ak áno. Dvojicu kľúčov teraz máme v ~/.ssh/id_rsa (privátny) a ~/.ssh/id_rsa.pub (verejný).

Posledný krok je umiestniť náš verejný kľúč na server. Kľúč musíme umiestniť do ~/.ssh/authorized_keys. Môžeme použiť ftp,sftp alebo len ručne skopírovať riadok s ~/.ssh/id_rsa.pub do ~/.ssh/authorized_keys. Súbor potom bude obsahovať niečo podobné tomtuto:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzriLTMYHhCc7fr8IXkZwNWRG81
j6PoT9wx4pU8mYRW/P1MGzY1LdU7NC5MOjwGwfVmIY70/NG5VKwsTOBzrAQ/75
+3nZd3PB4uaCYdex+dNI3+iBYCfjdWX3gqCZshJzx7cd+4m33gqzFQyEchNiI9
K5lXIPv/ICQq6cp3ZktVgxqbGSzydTuOKBIBnA05CWMXZYxhgEG1ivijoHVVpQ
B+mSMKACb7ylLYXD0wVimL8zsuxVnWEIDsf/plOlcWFvqqQF7oixCLtPQuDQwk
f6pqPrWcJ2xtffWf5DrLSvl1cYvd6obvXvsndEPuJ5/D7mLSpVNYm1IkpxsOAz
CFcKCw== xchg@smaher



V skutočnosti to bude na jednom riadku, v článku je text zalomený. Teraz už jednoducho príkazom

ssh uzivatel@host


sa pripojíme, server nebude vyžadovať heslo od účtu.

Zakázanie prihlásenia na účet root

Zásada nikdy sa neprihlasovať pod rootom platí aj tu (no na serveroch možno menej). Využívajte mechanizmy su a sudo. Účet root zakážete v sshd_config pridaním riadku

PermitRootLogin no


Záver

Po prečítaní tohoto článku by ste sa mali vedieť pripojiť na svoj počítač z iného počítača a pracovať na ňom. Samotný OpenSSH má však oveľa viac možností (x11 forwarding, port forwarding, socks proxy, sftp, ...) ktoré sa sem však nezmestili. V prípade, že by bol záujem o článok o ďalších možnostiach OpenSSH, tak sa ho skôr či neskôr dočkáte .

Hlásim sa medzi záujemcov o pokračovanie.

konecne normalny clanok po dlhom case

ale jedna pripomienka: ten obrazok by si zasluzil ine farby. Musel som ostrit zrak aby som farbu pisma odlizil. Majte zlutovanie aj s nami co sme farboslepi

Nepoznam sice autorov a kedy o com pisu ale ked sa niekomu nepaci hadam by mohol napisat nieco aj sam, nie? Ja som rad ze si precitam kazdy tyzden nieco, je to lepsie ako nic.

A tiez sa pridavam, dobry clanok.

Ano fajn clanok.
A teraz ma napada, ze mam takyto problem.
Robil som nejaku zalohu na server s rsync cez ssh.
Nejak sa to zaseklo a tak som to zhodil.
Od vtedy sa mi nejak zaseklo prihlasovanie s vygenerovanym klucom. Musim stale vytukavat heslo ked sa chcem prihlasit. Nejake napady?

Je tvoj kluc stale na servery tam kde ma byt? Je aj na lokalnom pc tam kde ma byt? Skús parameter -v klientovi. Alebo vygeneruj novy kluc.

xchg napísal:


Vymazal som svoj kluc aj na servery vygeneroval novy a naimportoval som ho nanovo. Stale to iste.
po -v vypisal toto.

OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xx.xxx.xx.xxx [xx.xxx.xx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/bum/.ssh/identity type -1
debug1: identity file /home/bum/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/bum/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xx.xxx.xx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/bum/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/bum/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/bum/.ssh/identity
debug1: Trying private key: /home/bum/.ssh/id_dsa
debug1: Next authentication method: password
Táto e-mailová adresa je chránená pred spambotmi. Ak ju chcete vidieť, je potrebné aby ste mali zapnutý JavaScript. 's password:

Hladá hladá tie súbory ale nenájde. V /home/bum/.ssh/id_dsa home/bum/.ssh/identity alebo home/bum/.ssh/id_rsa má byť privátny kľúč, je tam?