U nizu članaka o SSH protokolu v. 1 objasnili smo postupak uspostave veze između klijenta i poslužitelja, čiji je cilj autentikacija poslužitelja i uspostava sigurnog komunikacijskog kanala između klijenta i poslužitelja. U trenu kada se kanal uspostavio, na red dolazi autentikacija korisnika što je tema ovog članka. 

SSH protokol v.1, preciznije revizija 1.5, podržava šest mehanizama za autentikaciju korisnika: 

1. sigurnosni sustav Kerberos

2. Rhosts mehanizam

3. RhostsRSA mehanizam

4. asimetrični ključevi korisnika

5. jednokratna lozinka

6. korisničko ime i lozinka

Prilikom autentikacije poslužitelj pokušava ostvariti autentikaciju koristeći pojedine mehanizme navedenim redoslijedom. Administrator može dodatno konfigurirati poslužitelj da neke od ovih mehanizama ne koristi ili ograničiti broj pokušaja autentikacije po pojedinom mehanizmu. Analogno tome i klijent može definirati koje mehanizme želi, odnosno ne želi koristiti.

Najčešći mehanizmi autentikacije su korisničko ime i lozinka te asimetrični ključevi. Ostali mehanizmi zahtijevaju dodatnu konfiguraciju ili instalaciju posebne programske potpore. U ovom ćemo članku stoga opisati spomenuta dva mehanizma, a u nekom od sljedećih i preostala četiri mehanizma.

1. Korisničko ime i lozinka

Korisničko ime i lozinka je najjednostavniji mehanizam autentikacije. Prilikom otvaranja korisničkog accounta na računalu na kojemu je SSH poslužitelj, korisnik definira svoju lozinku. U postupku autentikacije korisnik upisuje lozinku, a SSH poslužitelj provjerava da li je lozinka ispravna koristeći mehanizme operacijskog sustava za provjeru lozinke. Provjerom lozinke postupak autentikacije je završen.

PREDNOSTI:

Jednostavnost je osnovna prednost ovog mehanizma. Korisnici ne moraju posebno konfigurirati SSH klijenta, što je posebno važno za one korisnike koji pristupaju poslužitelju s različitih računala.

MANE:

Ovaj mehanizam nesigurniji je od ostalih, jer ovisi o kvaliteti lozinke. Ukoliko korisnik odabere jednostavnu lozinku (npr. koristeći samo mala slova ili riječ iz rječnika), napadač može ugroziti sustav. Osim toga korisnik mora prilikom svakog prijavljivanja ponovno upisivati lozinku što također omogućava napadaču da ju uoči prilikom upisivanja (tzv. shoulder surfing).

Na poslužiteljskoj i klijentskoj strani, autentikacija korisničkim imenom i lozinkom može se isključiti ili uključiti opcijom:

PasswordAuthentication no

odnosno:

PasswordAuthentication yes

2. Asimetrični ključevi

Postupak autentikacije asimetričnim ključevima analogan je autentikaciji poslužitelja u fazi uspostave veze. Prije korištenja ovog mehanizma potrebno je ispuniti dva uvjeta:

- korisnik mora posjedovati par ključeva: privatni i javni

- na poslužiteljskoj strani mora biti stvorena baza javnih ključeva koji imaju pravo pristupa

Postupak je sljedeći:

1. Klijent šalje poslužitelju svoj javni ključ. Preciznije, šalje dio javnog ključa radi učinkovitosti komunikacije.

2. Poslužitelj provjerava da li se primljeni javni ključ nalazi u bazi ključeva. Ukoliko se ne nalazi postupak se završava.

3. Klijent šalje cijeli javni ključ, a poslužitelj provjerava ovlasti dodijeljene ključu na tom računalu (autorizacija korisnika bit će obrađena u narednim člancima op. a.).

4. Poslužitelj stvara poruku koja se sastoji od pseudoslučajnog niza znakova od 256 bita. Poruku zatim kriptira s korisničkim javnim ključem i šalje natrag klijentu.

5. Klijent dekriptira poruku. Stvara novu poruku iz dekriptirane poruke i identifikatora sjednice, koji je primio tijekom uspostave veze i potom izračunava sažetak nove poruke i šalje ga poslužitelju.

6. Poslužitelj na isti način kombinira inicijalnu poruku s identifikatorom sjednice i izračunava sažetak. Izračunati sažetak uspoređuje sa sažetkom primljenim od klijenta. Ukoliko je on isti autentikacija je uspješno završena.

Važno je napomenuti da se razmjenom kriptirane poruke (korak 4) poslužitelj uvjerava da korisnik posjeduje privatni ključ koji odgovara javnom ključu poslanom na početku postupka. 

U koraku 5 opisan je način na koji korisnik kombinira identifikator sjednice s porukom kako bi povezao postupak autentikacije s određenom SSH sjednicom. Takav postupak onemogućava napad ponavljanjem poruke (engl. replay attack). Kod ovakvog oblika napada, napadač osluškuje i snima mrežni promet, a naknadno ponovno šalje određene poruke. U slučaju SSH-a, napadač bi mogao iskoristiti nedostatke generatora pseudoslučajnih brojeva, rekonstruirati niz bez dekriptiranja i lažno se predstaviti poslužitelju.

Sažetak poruke se koristi da se onemogući kompromitiranje privatnog ključa. Primjer kompromitiranja je napad odabranim jasnim (nekriptiranim) tekstom (engl. chosen-plaintext attack). Ovaj napad omogućava napadaču da za odabrani jasni tekst (engl. plain text) dobije tekst kriptiran korisničkim ključem. Te informacije napadač dalje koristi za dobivanje korisničkog tajnog ključa. Ukoliko bi SSH klijent u koraku 5. samo dekriptirao poruku, napadač bi mogao poslati klijentu neku ranije "uhvaćenu" kriptiranu poruku i na taj način je dobiti u jasnom obliku.

PREDNOSTI:

Autentikacija asimetričnim ključevima smatra se najsigurnijim mehanizmom u SSH protokolu. Potencijalni napadač mora "ukrasti" dvije stvari: privatni ključ i lozinku za privatni ključ. U praksi ne postoji mehanizam koji bi omogućio napadaču da otkrije privatni ključ iz javnog. Jedini način da dođe do njega je da provali na klijentsko računalo, što izlazi iz domene zaštite SSH protokola. Međutim, i kada dođe do privatnog ključa, napadač mora probiti lozinku. Ukoliko je korisnik odabrao kvalitetnu lozinku, za napadača je praktično nemoguće probiti ju.

MANE:

Osnovna mana ovog pristupa je zahtjevna konfiguracija. Korisnik mora imati privatni ključ na klijentskom računalu, što je problem za korisnike koji često mijenjaju računala s kojih pristupaju poslužitelju. Dodatno, korisnik mora stvoriti bazu javnih ključeva na poslužitelju.

Ključevi se stvaraju naredbom:

ssh-keygen

Stvoreni ključevi bit će spremljeni u direktorij ~/.ssh. Iznimno važno je da ovlasti na direktoriju budu postavljene tako da isključivo korisnik može pristupati njemu. U suprotnom autentikacija neće raditi. Za lozinku se preporuča koristiti duge izraze, ukupne duljine između 10 i 30 riječi. Stvorenom privatnom ključu moguće je primijeniti lozinku naredbom:

ssh-keygen -p

Baza javnih ključeva sprema se u datoteku ~/.ssh/authorized_keys. Za omogućavanje autentikacije korisniku je dovoljno da presnimi javni ključ u tu datoteku.

Detaljniji opis korištenja SSH ključeva i konfiguracije pri korištenju autentikacije asimetričnim ključevima tema je jednog od budućih članaka.

Na poslužiteljskoj i klijentskoj strani, autentikacija asimetričnim ključevima se može isključiti, odnosno uključiti opcijom:

PublicKeyAuthentication no

odnosno:

PublicKeyAuthentication yes