SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

 

 

 

 

 

 

 

DIPLOMSKI RAD br. 1697

ANALIZA I SIMULACIJA SSH PROTOKOLA

Tihomir Meščić

 

 

 

 

 

 

Izvršni program : SSH_Simulator.zip

Izvorni kod : Izvorni_kod.zip

PDF verzija diplomskog : pdf

 

 

 

 

 

Zagreb, 2007.

 

 

Sažetak :

 

U ovom radu opisan je Secure Shell (SSH) protokol za sigurno udaljeno spajanje i prenošenje podataka između dva računala preko nesigurne mreže. Opisan je nastanak ovog protokola kao i protokoli slične namjene koji su mu prethodili. Protokol je detaljno opisan kroz pregled njegovih sastavnih dijelova: prijenosnog, autentifikacijskog i spojnog protokola. Razvijen je program koji simulira i vizualizira rad ovog protokola.

 


Sadržaj :

 

1      Uvod.. 1

2      Povijest, razvoj i slični protokoli 3

2.1      Povijest i razvoj SSH protokola. 3

2.2      R-naredbe. 4

2.3      TELNET. 4

3      Arhitektura SSH protokola. 6

3.1      Pregled arhitekture. 6

3.1.1       Podatkovne strukture SSH protokola. 7

3.1.2       Brojevi poruka. 8

3.2      Prijenosni protokol 9

3.2.1       Uspostavljanje veze. 9

3.2.2       Kompatibilnost sa starim verzijama. 10

3.2.3       SSH binarni paketni protokol 11

3.2.4       Algoritmi kompresije. 12

3.2.5       Algoritmi enkripcije. 12

3.2.6       Integritet podataka. 14

3.2.7       Metode razmjene ključeva. 15

3.2.8       Algoritmi javnog ključa. 16

3.2.9       Pregovaranje algoritama. 17

3.2.10     Razmjena ključeva. 19

3.3      Autentifikacijski protokol 23

3.3.1       Zahtjevi za autentifikacijom... 23

3.3.2       Autentifikacija pomoću javnog ključa ("publickey") 24

3.3.3       Autentifikacija pomoću lozinke ("password") 27

3.3.4       "hostbased" autentifikacija. 28

3.4      Spojni protokol 29

3.4.1       Otvaranje kanala. 30

3.4.2       Prijenos podataka. 31

3.4.3       Zatvaranje kanala. 31

3.4.4       Interaktivne sjednice. 32

3.4.5       Prosljeđivanje TCP/IP prometa. 34

4      Praktični rad.. 36

4.1      Programska implementacija. 36

4.2      Korištenje programa. 37

5      Zaključak. 42

6      Literatura. 43

7      Dodaci 45

 

 

 

 

1         Uvod

Secure Shell protokol (SSH) je mrežni protokol za sigurno spajanje na udaljeno računalo preko nesigurnog medija kao što je Internet. Bez obzira na njegovo ime, protokol pruža puno veću funkcionalnost nego obični alati za udaljeno spajanje poput telnet-a ili rlogin-a. Ova dva prethodna protokola su sa sigurnosnog aspekta jako nesigurna, jer je sav promet  između klijenta i poslužitelja nekriptiran, i tako su osjetljive informacije kao što su korisničke lozinke čitljive svima koji mogu prisluškivati mrežni promet. Dizajn tih protokola je odraz vremena u kojem su oni nastajali. Tada su računala bila relativno rijetka, obično su se nalazila u akademskim institucijama i umrežavana su u male lokalne mreže, tako da velika sigurnost i tajnost podataka i nije bila osobito potrebna. Međutim, porastom broja računala i razvojem Interneta, rizici su postali puno veći. Sve se više osjetljivih podataka počelo prenositi Internetom, i sve je više raznih alata koji omogućavanju prisluškivanje podataka zlonamjernim korisnicima, pa je bilo samo pitanje vremena kada će se protokol kao SSH pojaviti. SSH, za razliku od starijih protokola za udaljeno spajanje (remote login) nudi jako veliku sigurnost. To je protokol koji pripada aplikacijskom sloju TCP/IP modela, ali može funkcionirati i preko drugih prijenosnih protokola. On osigurava tajnost svih prenošenih podataka tako što kriptira sav promet između klijenta i poslužitelja. Također osigurava integritet prenošenih podataka računanjem MAC (message authentication code) kodova za svaki paket. U postupku spajanja klijenta, SSH omogućava klijentu da autentificira poslužitelj, tj. da utvrdi da je poslužitelja baš onaj za kog se izdaje, i tako se osigura od mogućeg čovjek-u-sredini (man-in-the-middle) napada gdje bi se potencijalni napadač predstavljao kao poslužitelj. Nadalje, SSH omogućava nekoliko mehanizama za autentifikaciju klijenta, od kojih su najčešće autentifikacija javnim ključem i autentifikacija lozinkom. Za razliku od telnet protokola ovdje se lozinke prenose sigurnim kriptiranim kanalom, i tako onemogućuju prisluškivanje (eavesdropping). Nakon uspostavljanja veze i međusobnog autentificiranja, spojni sloj SSH protokola omogućava razne usluge. Moguće je tradicionalno udaljeno korištenje ljuske operacijskog sustava (shell), ali je također moguće koristiti uspostavljenu vezu za prosljeđivanje prometa nekih drugih protokola (port forwarding), ili je moguće pokrenuti neki podsustav (scp, sftp) koji će koristiti SSH kanal kao sigurni medij za prenošenje podataka. Protokol dopušta i korištenje kompresije podataka za uštedu mrežnog prometa, ako to obje strane u komunikaciji zahtijevaju. Omogućeno je i istovremeno korištenje više kanala za prijenos, koji su zapravo samo logički kanali, a sav promet se multipleksira u jedan kanal. Protokol ima modularan dizajn, tj. dopušta implementacijama dodavanje novi usluga ili podsustava već postojećim, jer se o svim uslugama vrši pregovaranje. Također je moguće dodavanje novih kriptografskih algoritama ili metoda autentifikacije, ako se stare s vremenom pokažu kao nesigurne. Ovaj rad će na početku opisati povijest i razvoj ovog protokola, i protokole slične namjena koji su mu prethodili. Zatim, u drugom poglavlju će biti opisana kompletna arhitektura ovog protokola kroz pregled prijenosnog, autentifikacijskog i spojnog sloja i njihovih funkcija. U četvrtom poglavlju bit će opisan praktični dio ovog rada, a to je izrada računalnog programa koji simulira rad SSH protokola, prikazuje sve podatke koji su relevantni za simulaciju, i omogućava mijenjanje istih. Bit će opisani detalji programske implementacije, kao i upute za korištenje programa.

Treba reći da postoje dvije nekompatibilne verzije protokola, SSH-1 i SSH-2. Prva verzija protokola pati od dosta sigurnosnih propusta pa je brzo nakon nastanka zamijenjena puno boljom verzijom SSH-2. S obzirom da je SSH-1 protokol zastario i sve se manje koristi, u ovom radu bit će opisan samo SSH-2 protokol i gdje god se spominje SSH protokol to zapravo znači SSH-2 protokol, osim ako nije drukčije navedeno.


2         Povijest, razvoj i slični protokoli

 

U ovom poglavlju bit će opisani nastanak i razvoj SSH protokola, različite verzije tog protokola, zatim će biti dan pregled protokola slične namjere koji su prethodili SSH protokolu.

 

2.1      Povijest i razvoj SSH protokola

 

SSH protokol je u svojoj inačici SSH-1 nastao 1995. godina a razvio ga je Finac Tatu Ylönen, koji tada bio istraživač na tehnološkom sveučilištu u Helsinkiju (University of Technology, Helsinki). Motivacija za izradu tog protokola bio je slučaj napada na računalnu mrežu njegovog sveučilišta u kojem su napadači, doznavali lozinke korisnika prisluškivanjem prometa na mreži. Originalno je protokol bio namijenjen samo za njegovu osobnu upotrebu, ali je zbog velikog interesa, u srpnju 1995. objavljena prva verzija programa (SSH1) zajedno sa izvornim kodom i dopušteno je besplatno kopiranje i distribuiranje programa. Procjenjuje se da je do kraja te godine program prihvatilo oko 20,000 korisnika iz 50 zemalja, a tvorac je bio obasipan sa 150 email poruka dnevno, u kojima su ljudi tražili razne informacije o korištenju programa. Ylönen pred kraj 1995. godine osniva tvrtku SSH Communications Security, Ltd. (http://www.ssh.com/), s ciljem da komercijalizira i nastavi razvoj svog proizvoda, a još i danas je predsjednik i glavni inženjer zadužen za razvoj protokola. Prva verzija (SSH1) dokumentirana je 1995. godine i predložena kao IETF Internet Draft. Međutim, ta verzija je imala puno sigurnosnih problema, a sve ih se više otkrivalo kako je program bivao sve popularniji. Zbog toga SSH Communications Security 1996. godine predstavlja novu verziju protokola koje je nekompatibilna sa starom jer uvodi nove algoritme. Ta nova verzija nosi oznaku SSH 2.0 ili SSH-2. Ubrzo IETF formira radnu grupu nazvanu SECSH (Secure Shell) čija je zadaća standardizacija i razvoj protokola. Radna grupa podnosi prvi Internet Draft za SSH-2 protokol u veljači 1997. godine.

Godine 1998. tvrtka SSH Communications izdaje program naziva "SSH Secure Shell" koji je baziran na SSH-2 verziji protokola. Međutim, zbog toga što je program bio komercijalan, tj. nije bio besplatan kao prva verzija, on ne biva dobro prihvaćen i SSH-1 verzija protokola još par godina ostaje popularnija i korištenija nego SSH-2 verzija. To se promijenilo tek pojavom OpenSSH implementacije (http://www.openssh.com/) koja se razvija pod OpenBSD (http://www.openbsd.org/) licencom što znači da je potpuno besplatna i otvorenog izvornog koda. Open SSH implementacija je u početku bila bazirana na posljednjoj besplatnoj inačici originalnog SSH programa (1.2.12). Popularnost joj je jako brzo rasla zbog svoje otvorenosti, dostupnosti za razne operacijske sustave i podršci za obje verzije SSH protokola. Godine 2006. SSH-2 kao već zreo protokol postaje predloženi Internet Standard definiran u nizu RFC dokumenata [1-5].

 

2.2      R-naredbe

 

UNIX naredbe rsh (remote shell), rlogin (remote login) i rcp (remote copy) koje su poznate pod imenom r-naredbe (r-commands), su direktni prethodnici SSH-1 naredbi ssh, slogin i scp. Sučelja prema korisniku su skoro potpuno identična. Međutim, r-naredbe za razliku od svojih ssh dvojnika ne kriptiraju promet i imaju autentifikacijske mehanizme koje je lako prevariti.

rsh naredba koristi se za izvršavanje naredbe na udaljenom računalu, rlogin naredba spaja se na udaljeni terminal dok rcp naredba služi za kopiranje datoteka sa udaljenog poslužitelja ili kopiranje datoteka na udaljeni poslužitelj. Zajednička stvar im je način autentifikacije korisnika. Nakon spajanja klijenta na udaljeni poslužitelj, poslužitelj iz poslane mrežne adrese klijenta nalazi ime računala pomoću servisa kao što su NIS (network information service) ili DNS (domain name system). Nakon toga server provjerava lokalne konfiguracijske datoteke, najčešće su to /etc/hosts.equiv i $HOME/.rhosts. U tim datotekama se nalaze imena računala i imena korisnika kojima je dopušteno spajanje na to računalo. Ako je ime računala i korisnika pronađeno u jednoj od tih datoteka, korisniku je dopušteno spajanje sa svim ovlastima koje inače ima na tom računalu.

Ovaj sustav autentifikacije je jako nesiguran, s obzirom servisi kao DNS imaju sigurnosne rupe koje bi omogućile da računalo potencijalnog napadača  nakon kompromitiranja DNS servera, poslužitelju izgleda kao računalo kojem može vjerovati. Napadač bi tada dobio potpuni pristup tom računalu bez da zna korisničku lozinku. Ako su r-naredbe konfigurirane da traže lozinku, ona se prenosi kao čisti tekst.

r-naredbe se mogu koristiti u malim mrežama gdje se može vjerovati svim računalima. Međutim, korištenje u nesigurnim mrežama kao što je Internet bi predstavljalo prevelik rizik tako da ove naredbe polako odlaze u prošlost. Dodatni nedostatak im je i taj što se mogu koristiti samo na UNIX računalima.

 

2.3      TELNET

 

TELNET (TELecommunication NETwork) je do pojave SSH protokola, bio daleko najkorišteniji protokol za spajanje na udaljeni terminal. Razvijen je 1969. godine i postao je jedan od prvih Internet standarda (IETF STD 8). Velika prednost pred r-naredbama mu je to što je nezavisan o platformi na kojoj se koristi. Obično se koristi iznad TCP/IP konekcije, iako je sam TELNET protokol stariji od samog TCP/IP protokolnog stoga. Tipičan mrežni pristup (port) na kojem TELNET poslužitelj osluškuje zahtjeve je 23.

U zadnjih desetak godina zbog pojave SSH protokola dosta gubi na popularnosti, ali se i dalje koristi, pogotovo zato što klijentski TELNET program dolazi unaprijed instaliran na gotovo svim operacijskim sustavima.

Sa sigurnosnog aspekta se korištenje TELNET protokola nikako ne preporučuje. To je stoga što se svi podaci (uključujući i lozinke) prenose u čistom, nekriptiranom obliku. Tako je moguće da svatko tko ima pristup mrežnom usmjerniku na mreži između dva računala koja komuniciraju TELNET-om i ima pokrenut nekakav alat kao što je tcpdump, može pročitati korisničke lozinke.

Drugi razlog zašto se TELNET treba izbjegavati je stoga što on nema mehanizme za autentificiranje poslužitelja, tako da su mogući man-in-the-middle napadi, u kojima bi se potencijalni napadač predstavljao kao TELNET server i došao do tajnih podataka klijenta.

 

 


3         Arhitektura SSH protokola

 

U ovom poglavlju detaljno je opisana arhitektura SSH protokola, podatkovne strukture koje se koriste, podjela protokola na tri glavna dijela (prijenosni, autentifikacijski i spojni), njihove značajke i njihova povezanost te najvažniji algoritmi koji su potrebni za funkcioniranje protokola.

 

3.1      Pregled arhitekture

 

Kao što je već rečeno SSH protokol je protokol za sigurno udaljeno logiranje i druge mrežne usluge preko nesigurne mreže kao što je Internet koji koristi klijent-poslužitelj model . Protokol je definiran u nizu RFC dokumenta ([1] do [4]) i trenutno ima status predloženog Internet standarda. Sastoji se od tri glavne komponente/sloja:

 

·        Prijenosni protokol (The Transport Layer Protocol) koji pruža autentifikaciju poslužitelja, tajnost prijenosa, i integritet prenošenih podataka. Također, opcionalno pruža i uslugu kompresije podataka. Obično radi kao aplikacijski protokol iznad TCP/IP protokolnog stoga, ali nije ovisan o njemu, već može raditi na iznad svakog protokola koji pruža pouzdan prijenos podataka

·        Autentifikacijski protokol (The User Authentication Protocol) koji je zadužen za autentifikaciju korisnika poslužitelju na koji se on pokušava spojiti. Za njegov rad je potrebno da prijenosni sloj protokola već bude u funkciji.

·        Spojni protokol (The Connection Protocol) je zadužen za multipleksiranje više logičkih kanala u jedan kriptirani tunel. Također upravlja zahtjevima korisnika za uslugama kao što su to zahtjev za pokretanjem pseudoterminala (pty) i ljuske operacijskog sustava (shell) ili izvršavanje naredbe na poslužitelju ili pokretanje podsustava (scp, sftp) ili pak prosljeđivanje mrežnih pristupa (port forwarding). Radi iznad prijenosnog i autentifikacijskog sloja.

 

Nakon uspostave sigurnog prijenosnog kanala klijent obično pošalje zahtjev za pokretanjem autentifikacijskog servisa (ssh-userauth). Također, nakon uspješne autentifikacije klijent će poslati zahtjev za pokretanjem spojnog protokola (ssh-connection). To omogućava da novi protokoli budu definirani i da koegzistiraju sa postojećim protokolima.

 

Slika 1 : Arhitektura SSH protokola

 

3.1.1      Podatkovne strukture SSH protokola

 

Slijedi pregled podatkovnih tipova koji se koristi u SSH protokolu i njihova objašnjenja:

 

·        byte - ovaj podatak predstavlja proizvoljni niz dužine osam bitova (oktet). Neke podatkovne strukture predstavljaju se kao polje bajtova, što se piše byte[n], gdje je n broj članova u tom polju.

·        boolean – ovaj podatkovni tip predstavlja logičku varijablu koja se pohranjuje kao jedan bajt. Vrijednost 0 predstavlja logičko NE, dok vrijednost 1 predstavlja logičko DA. Sve vrijednosti koje nisu nula se također tumače kao logičko DA, ali implementacijama protokola nije preporučeno pohranjivati boolean vrijednosti različite od 0 ili 1.

·        uint32 – Ovaj podatkovni tip predstavlja 32-bitni cijeli broj bez predznaka (unsigned). Zapisuje se kao niz od četiri bajta i to tako da je prvi bajt najznačajniji, a zadnji bajt najmanje značajan (big endian). Tako se na primjer vrijednost 123456 (0x1E240), predstavlja kao niz bajtova 01 E2 40

·        uint64 – predstavlja 64-bitni cijeli broj bez predznaka (unsigned). Zapisuje se kao niz od osam bajtova u big endian poretku.

·        string – Predstavlja proizvoljni niz bajtova proizvoljne duljine. U string tipu podataka dopušteno je pojavljivanje svih mogućih znakova pa tako i null znaka, i znakova čiji je najznačajniji bit jednak 1. Zapisuje se tako da se prvo zapiše duljina niza (broj bajtova koji slijede) kao uint32 podatak, pa zatim 0 ili više znakova koji predstavljaju taj string. Završni null znak se ovdje ne koristi (kao na primjer u C stringovima), jer je kraj niza određen njegovom duljinom. Stringovi se također koriste za zapisivanje tekstualnih podataka. U tom slučaju, koristi se ASCII kodiranje ako se radi o internim imenima (npr. imena algoritama, imena podsustava i sl.), a za tekst koji će se eventualno prikazati korisniku koristi se UTF-8 kodiranje definirano u standardu ISO-10646. Pozitivna stvar kod UTF-8 kodiranja je to što zapis US-ASCII znakova ostaje nepromijenjen. Za tekst vrijedi isto kao i za proizvoljne nizove, završni null znak se ne koristi. Tako bi, na primjer, tekst "primjer" bio zapisan kao 00 00 00 07 p r i m j e r.

·        mpint – Ovaj podatkovni tip predstavlja veliki cijeli broj višestruke preciznosti (multiple precision integer) u dvojnom komplementu, zapisan kao string (znači prvo ide uint32 podatak u kojem je zapisan broj bajtova koji slijede), tako da najvažniji bajt ide na početku zapisa broja. Negativne vrijednosti imaju postavljen bit 1 kao najznačajniji bit prvog bajta koji predstavlja broj. Ako se, međutim, radi o pozitivnom broju koji bi imao bit 1 kao najznačajniji bit, tada se na početak zapisa dodaje jedan bajt čiji su svi bitovi nula. Vrijednost nula se kodira kao string čija je duljina jednaka 0 bajtova. Npr. broj 0 kodiramo kao 00 00 00 00, broj 0x10ab kodiramo kao 00 00 00 02 10 ab, broj 0x90 kodiramo kao 00 00 00 02 00 90.

·        name-list – Ovaj tip podataka predstavlja listu imena. Kodira se kao string čiji je sadržaj lista imena odvojenih zarezom. To znači da prvo ide uint32 podatak u kojem je zapisana ukupna duljina liste (broj bajtova koji slijedi), a zatim ide lista od 0 ili više imena koja su odvojena zarezom. Ime u listi mora biti dugačko minimalno jedan bajt i ne smije u sebi sadržati znak zareza (","). Sva imena moraju biti kodirana kao US-ASCII. Ovisno o kontekstu u kojem se ovaj tip podataka koristi, mogu postojati i druge restrikcije. Na primjer, u postupku pregovaranja algoritama, lista algoritama je predstavljena kao name-list podatak, i postoji ograničenje da navedena imena moraju biti ispravna imena algoritama (npr. za simetrične algoritme "aes-128-cbc", "blowfish-cbc" itd.). Završni null znak se ne koristi, niti za pojedinačna imena niti za listu u cjelini. Primjeri: prazna lista () se kodira kao 00 00 00 00, lista ("zlib,none") se kodira kao 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65.

 

3.1.2      Brojevi poruka

 

Poruke su glavna komponenti SSH protokola. Da bi ih sudionici u SSH komunikaciji razlikovali, sve poruke na svom početku imaju identifikacijski broj koji predstavlja vrstu poruke. Na temelju tog broja primatelj poruke zna koji su podaci sadržani unutra, u kojem su redoslijedu, i kako su kodirani.

SSH poruke imaju identifikatore u rasponu od 0 do 255, kodirane kao jedan bajt. Svi definirani identifikacijski brojevi poruka mogu se naći u dodatku A.

 

 

3.2      Prijenosni protokol

 

Prijenosni sloj SSH protokola je najniži sloj od kojeg zavise ostala dva sloja. Najčešće se protokol vrti iznad TCP/IP protokola, ali moguće je rad i iznad drugih protokola. On pruža jaku enkripciju, autentifikaciju poslužitelja, i čuva integritet prenesenih podataka. Autentifikacija korisnika se ne vrši u ovoj fazi, nego samo autentifikacija poslužitelja.

Ovaj protokol je dizajniran da bude jednostavan i fleksibilan, i da omogući pregovaranje o algoritmima i parametrima konekcije, i minimizira broj poruka kod pregovaranja. Algoritmi o kojima se pregovara su metode razmjene ključeva, algoritmi simetrične enkripcije, algoritam javnog ključa za autentifikaciju poslužitelja, algoritmi za računanje sažetka poruke (hash) i MAC algoritmi (message authentication code). Protokol predviđa da potpunu razmjena ključeva i autentifikacija servera završi nakon dvije razmjene poruka. U najgorem slučaj sve će biti gotovo u 3 razmjene.

 

3.2.1      Uspostavljanje veze

 

Poslužitelj osluškuje konekcije na TCP/IP pristupu broj 22 (što je službeni broj pristupa registriran od strane IANA-e), ali to može biti i bilo koji drugi pristup. Vezu inicira klijent. Nakon što je veza uspostavljena obje strane šalju identifikacijske nizove. Nizovi imaju sljedeći format:

 

SSH-verzijaprotokola-verzijaprograma razmak komentari CR LF

 

Na početku niza obavezno mora biti "SSH-", a nakon toga ide verzija protokola koju program koristi. Za SSH-2 verziju protokola to mora biti "2.0". Nakon toga slijedi verzija programa koji se koristi. Nakon toga mogu ići komentari, ali oni su opcionalni. Ako su komentari prisutni, tada nakon niza koji označava verziju programa mora doći razmak (ASCII 32). Identifikacijski niz mora biti prekinut jednim CR znakom (carriage return, ASCII 13), a nakon toga jednim LF znakom (line feed, ASCII 10). Null znak ne smije biti na kraju niza. Maksimalna dužina ovog niza je 255 znakova (uključujući i CR i LF znakove). Ako bilo koja strana primi identifikacijski niz koji ne počinje sa "SSH-" mora ga ignorirati. Ovi identifikacijski znakovi bitni su kod izbora verzije protokola koji će se koristiti, a oba niza će se poslije koristiti u Diffie-Hellman postupku razmjene ključeva.

Odmah nakon što su poslani identifikacijski nizovi sa obje strane počinje proces razmjene ključeva. Svi podaci koji se šalju nakon identifikacijskih nizova moraju biti u formatu binarnog SSH paketa.

 

Ovdje se dan jedan primjer preuzet iz log datoteke programa Putty, u kojem se može vidjeti kako izgleda inicijalno uspostavljanje veze u praksi. Na klijentskoj strani je program Putty, dok je na poslužiteljskoj strani OpenSSH implementacija:

 

Event Log: Looking up host "192.168.145.2"

Event Log: Connecting to 192.168.145.2 port 22

Event Log: Server version: SSH-1.99-OpenSSH_3.9p1

Event Log: We claim version: SSH-2.0-PuTTY-Release-0.56

Event Log: Using SSH protocol version 2

 

Kao što se može vidjeti, ni klijent ni poslužitelj nemaju opcionalni komentar nego iza verzije programa odmah slijede CR i LF znakovi. Klijent je prijavio da koristi verziju protokola "2.0", dok je poslužitelj prijavio verziju "1.99".

 

3.2.2      Kompatibilnost sa starim verzijama

 

Kao što je napomenuto u prošlom dijelu, u postupku uspostavljanja veze bi sve implementacije trebale poslati da koriste verziju protokola "2.0" (tj. identifikacijski niz mora početi sa "SSH-2.0-"). Za stare verzije protokola ovaj niz je počinjao sa "SSH-1.x" (npr. "SSH-1.2", "SSH-1.4"...). S obzirom da još postoje programi koji koriste staru, prvu verziju protokola, potrebno je omogućiti kompatibilnost i sa tim programima.

 

Ako imamo slučaj da klijent koristi stari protokol (SSH-1), a poslužitelj koristi novi (SSH-2), tada bi poslužitelj trebao prijaviti svoju verziju protokola kao 1.99 (tj. identifikacijski niz počinje sa "SSH-1.99", kao u primjeru gore). U tom slučaju novi klijenti trebaju prepoznati ovo kao ekvivalent protokola 2.0 i početi razmjenu ključeva prema SSH-2 verziji protokola. Stare verzije klijenta niz "1.99" protumače kao verziju SSH-1 protokol i počinju razmjenu koristeći stariji protokol. Naravno, poslužitelj treba prijaviti verziju kao 1.99 samo ako podržava i staru verziju protokola i ako je konfiguriran tako da prihvaća i SSH-1 konekcije.

 

Ako imamo slučaj da klijent koristi novi protokol, a poslužitelj koristi stari protokol, tada je moguće da će klijent odmah nakon slanja svog identifikacijskog niza (a prije primanja poslužiteljevog) poslati i podatke za razmjenu ključeva. S obzirom da je poslužitelj koristi stariju verziju protokola on neće razumjeti podatke i prekinut će konekciju. Rješenje je to, da ako je klijent primio poslužiteljev identifikacijski niz, u kojem on javlja da koristi verziju 1 protokola, a već je kasno jer je klijent poslao dodatne podatke, tada klijent nakon prekidanja veze ponovno uspostavlja vezu i prijavljuje se kao klijent koji koristi staru verziju, i postupa po starom protokolu.

 

 

 

3.2.3      SSH binarni paketni protokol

 

Nakon slanja identifikacijskih nizova, počinje se koristiti SSH binarni paketni protokol (Binary Packet Protocol), koji će se koristiti za sav promet do prekida veze. Taj protokol definira format u kojem se šalju svi podaci i prikazan je na slici 2, a polja su detaljno opisana u tablici 1.

Slika 2 : SSH binarni paket

 

Tablica 1 : Značenje pojedinih polja u SSH binarnom paketu

Naziv polja
Tip podataka
Opis
duljina paketa
uint32
Označava duljinu paketa u bajtovima,
bez MAC polja, i bez sebe samog
duljina dopune
byte
Označava duljinu nasumične dopune u 
bajtovima
korisne informacije
byte[n1]
Ovdje su pohranjene korisne 
informacije. Ako je kompresija 
dogovorena ovo polje je komprimirano. 
Duljina ovog polja je n1 = 
duljina_paketa – duljina_dopune - 1 
dopuna
byte[n2]
Nasumična dopuna, takva da je 
ukupna duljina spojenih polja 
(duljina_paketa || duljina_dopune || 
koristan_teret || dopuna) višekratnik
broja 8 ili duljine bloka enkripcije, što 
god je veće. Obavezno mora biti 
barem 4 bajta dopune. Dopuna bi
trebala biti nasumična ali to nije 
obavezno. Maksimalna veličina 
dopune je 255 bajtova.
MAC
byte[m]
Message Authentication Code. Polje 
koje osigurava integritet podataka i štiti 
od napada ponavljanjem paketa, ili 
mijenjanja redoslijeda paketa. Nije 
obavezno i koristi se samo ako je to u 
postupku pregovaranja algoritama 
dogovoreno.
 
 

Kao što se vidi iz slike 2, svaki binarni paket počinje sa četiri bajta koja predstavljaju ukupnu duljinu paketa nakon tog polja, bez MAC polja koje je opcionalno. Slijedi jedan bajt u kojem je zapisana veličina dopune sa kraja paketa. Minimalna veličina dopune je 4 bajta, a maksimalna je 255 bajtova. Dopuna bi trebala biti nasumična, što otežava napade na algoritam kriptiranja koji se koristi. Veličina dopune se odabire tako da bi duljina ukupnog paketa bez MAC polja bila višekratnik broja 8 ili duljine bloka algoritma enkripcije, što god je veće.

Treba primijetiti da je minimalna duljina paketa 16 bajtova + duljina MAC polja ako se ono koristi. Kompletan paket se kriptira, pa tako i polje sa duljinom paketa, što znači da će kod pogrešne dekripcije i ovo polje biti pogrešno, te se neće moći znati kolika je duljina paketa. MAC polje se ne kriptira.

 

3.2.4      Algoritmi kompresije

 

Ako je u postupku pregovaranja algoritama dogovoren i algoritam kompresije, tada će polje sa korisnim podacima (samo to polje) biti kompresirano. Duljina paketa, i MAC polje će biti izračunati koristeći kompresirane podatke. Enkripcija će također biti izvršena nakon kompresije. Kompresija je nezavisna za svaki smjer, tj. možemo koristiti jedan algoritam za smjeru klijent-poslužitelj, a drugi algoritam za kompresiju u smjeru poslužitelj-klijent. Međutim, preporučeno ja da metoda kompresije bude ista oba smjera.

Tablica 2 : Definirani algoritmi kompresije

Ime algoritma
Zahtjev
Opis algoritma
none
obavezno
bez kompresije
zlib
opcionalno
ZLIB (LZ77) kompresija
 

U gornjoj tablici navedeni su algoritmi kompresije koje SSH protokol definira. Prva je 'none' metoda. Ona označava da nema kompresije, i prema SSH protokolu ta je metoda obavezna u svim SSH implementacijama. Druga metoda, označena kao "zlib", je zlib metoda kompresije opisana u dokumentima RFC1950 (ZLIB Compressed Data Format Specification version 3.3) i RFC1951 (DEFLATE Compressed Data Format Specification version 1.3).

 

3.2.5      Algoritmi enkripcije

 

Algoritam za enkripciju će biti dogovoren u postupku pregovaranja algoritama, dok će se ključ enkripcije dobiti Diffie-Hellman razmjenom ključeva. Nakon što je završena razmjena ključeva, svaki paket se kriptira, tj. sva polja osim MAC polja. Enkripcija se vrši nezavisno u oba smjera, tj. postoji poseban ključ i inicijalizacijski vektor za smjer enkripcije klijent-poslužitelj, dok se za smjer poslužitelj-klijent koristi drugi ključ i inicijalizacijski vektor. Osim toga moguće je čak da se koristi jedan algoritam enkripcije za jedna smjer, a drugi algoritam za drugi smjer, međutim to nije preporučljivo. Duljina ključeva enkripcije bi trebala biti minimalno 128 bitova.

Algoritmi koji su predviđeni za korištenje u originalnom protokolu dani su u sljedećoj tablici:

Tablica 3 : Definirani algoritmi enkripcije

Ime algoritma
Zahtjev
Opis algoritma
3des-cbc
obavezno
enkripcija-dekripcija-enkripcija DES
algoritmom, sa tri ključa, u CBC načinu
blowfish-cbc
opcionalno
Blowfish algoritam u CBC načinu 
kriptiranja. Ima ključ duljine 128 bitova.
twofish256-cbc
opcionalno
Twofish algoritam u CBC načinu sa 256-
bitovnim ključem i 128-bitovnim blokovima
twofish-cbc
opcionalno
Alias za twofish256-cbc
twofish192-cbc
opcionalno
Twofish algoritam u CBC načinu sa 192-
bitovnim ključem i 128-bitovnim blokovima
twofish128-cbc
opcionalno
Twofish algoritam u CBC načinu sa 128-
bitovnim ključem i 128-bitovnim blokovima
aes256-cbc
opcionalno
AES (Advanced Encryption Standard
algoritam u CBC načinu sa 128-bitovnim
blokovima i 256-bitovnim ključem
aes192-cbc
opcionalno
AES (Advanced Encryption Standard
algoritam u CBC načinu sa 128-bitovnim 
blokovima i 192-bitovnim ključem
aes128-cbc
preporučeno
AES (Advanced Encryption Standard
algoritam u CBC načinu sa 128-bitovnim 
blokovima i 128-bitovnim ključem
serpent256-cbc
opcionalno
Serpent algoritam u CBC načinu sa 256-
bitovnim ključem
serpent192-cbc
opcionalno
Serpent algoritam u CBC načinu sa 192-
bitovnim ključem
serpent128-cbc
opcionalno
Serpent algoritam u CBC načinu sa 128-
bitovnim ključem
arcfour
opcionalno
Arcfour algoritam koji kriptira tok podataka
i ima ključ duljine 128 bitova. Treba ga 
izbjegavati jer ima problem sa slabim 
ključevima.
idea-cbc
opcionalno
IDEA algoritam kriptiranja u CBC načinu
cast128-cbc
opcionalno
CAST-128 algoritam u CBC načinu, sa
128-bitovnim ključem
none
opcionalno
bez enkripcije, ne preporuča se

 

Kao što se vidi iz tablice, jedini algoritam koji je obavezan za sve implementacije je "3des-cbc", što je razumljivo. Taj algoritam je odabran zato što je DES algoritam dosta dugo bio najkorišteniji, a i dalje je skoro svugdje podržan. Iako 3DES ima ključ duljine 192 bita, taj ključ zapravo ima efektivnu duljinu od 112 bitova, što je manje od preporučenog, pa je puno bolje korištenje nekog drugog algoritma, kao što je npr. "aes128-cbc".

Svi algoritmi rade u CBC (cipher block chaining) načinu (osim arcfour algoritma), što znači da se prije kriptiranja vrši XOR operacija između čistog teksta i prethodnog kriptiranog bloka (ili inicijalizacijskog vektora ako se radi o prvom paketu). Princip rada u tom načinu prikazan je na slici 3.

Slika 3 : CBC način enkripcije

3.2.6      Integritet podataka

 

Integritet podataka zaštićen je tako što se uz svaki paket šalje i MAC (message authentication code) koji se računa iz tajnog ključa, rednog broja paketa i sadržaja samog paketa. Tijekom procesa dogovaranja algoritama, dogovara se i koji će se MAC algoritam koristiti.

Ako je odabran neki MAC algoritam različit od "none" (što označava da se ne koristi nikakav MAC algoritam) tada će se iz tajnog ključa izračunati MAC ključevi, jedan za smjer klijent-poslužitelj i drugi za smjer poslužitelj-klijent. Nakon toga će uz svaki poslani paket biti poslano i MAC polje. Ono se računa na sljedeći način:

 

mac = MAC (mac_ključ, redni_broj_paketa || nekriptirani paket)

 

gdje MAC označava dogovoreni MAC algoritam, mac_ključ je ključ dobiven nakon razmjene ključeva, redni_broj_paketa je redni broj paketa koji šaljemo predstavljen kao uint32, i postavljen na nulu za prvi paket. Taj redni broj se spaja zajedno sa nekriptiranim paketom, koji čine duljina paketa, duljina dopune, korisni teret i dopuna. Na te dvije spojene vrijednosti primjenjuje se MAC algoritam uz korištenje navedenog ključa i rezultat je mac polje koje se šalje zajedno s paketom. Strana koja primi paket, prvo ga dekriptira, primijeni mac algoritam na isti način, i ako dobivena vrijednost nije jednaka primljenoj to znači da se taj paket odbacuje. Time se čuva integritet i štiti od napada ponovnim slanjem paketa (replay attack) ili napada mijenjanjem redoslijeda paketa. I ovdje je moguće da klijent i poslužitelj koriste različite MAC algoritme ali to se ne preporuča.

 

Tablica 4 : Definirani MAC algoritmi

Ime algoritma
Zahtjev
Opis algoritma
hmac-sha1
obavezno
HMAC-SHA1 algoritam, duljina sažetka je 160 bitova, kao i duljina ključa
hmac-sha1-96
preporučeno
Prvih 96 bitova HMAC-SHA1 algoritma se uzimaju kao sažetak, ključ je duljine 160 bitova
hmac-md5
opcionalno
HMAC-MD5 algoritam, duljina sažetka je 128 bitova, kao i duljina ključa
hmac-md5-96
opcionalno
Prvih 96 bitova HMAC-MD5 algoritma se uzimaju kao sažetak, ključ je duljine 128 bitova
none
opcionalno
ne koristi se MAC, ne preporuča se
 

 

Svi HMAC-* algoritmi opisani su u [10], a zapravo predstavljaju obične algoritme za računanje sažetka (hash) koji se primjenjuju na spoj tajnog ključa i teksta, a ne samo na tekst kao što to rade obični algoritmi za računanje sažetka.

 

3.2.7      Metode razmjene ključeva

 

Metode razmjene ključeva definiraju način na koji obje strane dolaze do dijeljene tajne koja se onda koristi za generiranje svih potrebnih ključeva. U SSH-2 verziji protokola to je Diffie-Hellman algoritam.

 

Tablica 5 : Definirani algoritmi razmjene ključa

Ime algoritma
Zahtjev
diffie-hellman-group1-sha1
obavezno
diffie-hellman-group14-sha1
obavezno
diffie-hellman-group-exchange-sha1
opcionalno
diffie-hellman-group-exchange-sha256
opcionalno
 

Sve ove definirane metode koriste Diffie-Hellman algoritam razmjene ključeva, i sve osim ("diffie-hellman-group-exchange-sha256") koriste sha1 algoritam za računanje sažetka.

 

Metoda "diffie-hellman-group1-sha1" označava Diffie-Hellman algoritam uz korištenje sha1 algoritma, i koristi 1024-bitni modulus. Parametri su:

 

Modulus (1024 bita), heksadekadski: 
 
         FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
         29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
         EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
         E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
         EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
         FFFFFFFF FFFFFFFF
Generator:
               2
 
Metoda "diffie-hellman-group14-sha1" je ista kao i gornja uz tu razliku da koristi drugi modulus. Parametri su:
 
Modulus (2048 bita), heksadekadski:
 
      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
      E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
      15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
 
Generator:
       2

 

Metode "diffie-hellman-group-exchange-*" se razlikuju po tome što nemaju fiksno definirane parametre (modulus i generator), već se oni dogovaraju prilikom spajanja. Klijent pošalje paket sa zahtjevom u kojem traži te parametre i definira minimalnu i željenu veličinu u bitovima. Nakon toga, server koji ima veliku bazu izgeneriranih parametra šalje modulus i generator klijentu.

 

3.2.8      Algoritmi javnog ključa

 

SSH protokol je dizajniran tako da može raditi s bilo kojim algoritmom javnog ključa. Ti algoritmi se također dogovaraju nakon inicijaliziranja konekcije. Ipak, daleko su najkorišteniji DSS (Digital Signature Standard) i RSA algoritmi. Format zapisa njihovih ključeva za primjenu u SSH protokolu definiran je u [2], i označen kao "ssh-dss" i "ssh-rsa". DSS algoritam obavezno moraju podržavati sve implementacije dok je RSA opcionalan. Oni se koriste za generiranje digitalnog potpisa, što omogućava autentificiranje poslužitelja. 

 

Tablica 6 : Definirani formati javnih ključeva

Ime formata
Zahtjev
Opis formata
ssh-dss
obavezno
Sirovi DSS ključ
ssh-rsa
preporučeno
Sirovi RSA ključ
pgp-sign-rsa
opcionalno
OpenPGP certifikat (RSA ključ)
pgp-sign-dss
opcionalno
OpenPGP certifikat (DSS ključ)

 

Format zapisa DSS javnog ključa je sljedeći:

string    "ssh-dss"
mpint     p
mpint     q
mpint     g
mpint     y
 
gdje su p, q, q i y parametri DSS algoritma kodirani kao mpint podaci.
 
Format zapisa DSS digitalnog potpisa je sljedeći:
string    "ssh-dss"
string    dss_potpis
 
gdje dss_potpis predstavlja string zapis 160-bitnih brojeva "r" i "s" koji su rezultat potpisivanja DSS algoritmom.
 
Format zapisa RSA javnog ključa je sljedeći:
string    "ssh-rsa"
mpint     e
mpint     n
 
gdje su "e" i "n" parameri RSA algoritma kodirani kao mpint podaci.
 
Format zapisa RSA potpisa je sljedeći:
string    "ssh-rsa"
string    rsa_potpis
 
gdje rsa_potpis predstavlja string zapis broja "s" koji se dobije kao rezultat potpisivanja neke poruke RSA algoritmom.

 

Formati "pgp-sign-rsa" i "pgp-sign-dss" označavaju da su ključevi, certifikati i potpisi u OpenPGP binarnom formatu.

 

3.2.9      Pregovaranje algoritama

 

Pregovaranje algoritama počinje tako što obje strane pošalju liste (name-list) algoritama koje podržavaju. Liste se formiraju po prioritetu i to tako da preferirani algoritmi budu na vrhu liste.

Paketi moraju imati sljedeći format :

 

byte         SSH_MSG_KEXINIT
byte[16]     cookie (nasumični bajtovi)
name-list    algoritmi razmjene ključa
name-list    algoritmi javnog ključa
name-list    algoritmi enkripcije od klijenta prema poslužitelju
name-list    algoritmi enkripcije od poslužitelja prema klijentu
name-list    mac algoritmi od klijenta prema poslužitelju
name-list    mac algoritmi od poslužitelja prema klijentu
name-list    algoritmi kompresije od klijenta prema poslužitelju
name-list    algoritmi kompresije od poslužitelja prema klijentu
name-list    jezici od klijenta prema poslužitelju
name-list    jezici od poslužitelja prema klijentu
boolean      slijedi prvi KEXINIT paket
uint32       0 (rezervirano za buduća proširenja)

 

 

Dakle, prvi bajt je SSH_MSG_KEXINIT i govori primatelju o kojoj vrsti paketa se radi, zatim slijedi "cookie", koji je niz od 16 nasumičnih bajtova, i služi za otežavanje napada. Nakon toga slijede liste željenih algoritama odvojenih zarezom (name-list).

Algoritam za utvrđivanje dogovorenih algoritama je vrlo jednostavan:

1.                      ako je prvi algoritam u listi klijenta i u listi poslužitelja isti, tada je to odabrani algoritam

2.                      ako prvi algoritam u listama nije isti, tada se ide po listi klijentovih algoritama od početka do kraja, i prvi algoritam koji se nalazi i na poslužiteljevoj listi je odabrani algoritam

3.                      ako nema niti jednog istog algoritma u listama klijenta i poslužitelja, tada je pregovaranje neuspješno, i klijent i poslužitelj prekidaju vezu

 

Na ovom primjeru koji je preuzet iz log datoteke programa Putty može se vidjeti kako taj paket izgleda u praksi:

 

Incoming packet type 20 / 0x14 (SSH2_MSG_KEXINIT)

  00000000  1c fb 09 b9 09 1a 5d 7b 8e d1 f0 fe 95 90 7f ad  ......]{........

  00000010  00 00 00 59 64 69 66 66 69 65 2d 68 65 6c 6c 6d  ...Ydiffie-hellm

  00000020  61 6e 2d 67 72 6f 75 70 2d 65 78 63 68 61 6e 67  an-group-exchang

  00000030  65 2d 73 68 61 31 2c 64 69 66 66 69 65 2d 68 65  e-sha1,diffie-he

  00000040  6c 6c 6d 61 6e 2d 67 72 6f 75 70 31 34 2d 73 68  llman-group14-sh

  00000050  61 31 2c 64 69 66 66 69 65 2d 68 65 6c 6c 6d 61  a1,diffie-hellma

  00000060  6e 2d 67 72 6f 75 70 31 2d 73 68 61 31 00 00 00  n-group1-sha1...

  00000070  0f 73 73 68 2d 72 73 61 2c 73 73 68 2d 64 73 73  .ssh-rsa,ssh-dss

  00000080  00 00 00 87 61 65 73 31 32 38 2d 63 62 63 2c 33  ....aes128-cbc,3

  00000090  64 65 73 2d 63 62 63 2c 62 6c 6f 77 66 69 73 68  des-cbc,blowfish

  000000a0  2d 63 62 63 2c 63 61 73 74 31 32 38 2d 63 62 63  -cbc,cast128-cbc

  000000b0  2c 61 72 63 66 6f 75 72 2c 61 65 73 31 39 32 2d  ,arcfour,aes192-

  000000c0  63 62 63 2c 61 65 73 32 35 36 2d 63 62 63 2c 72  cbc,aes256-cbc,r

  000000d0  69 6a 6e 64 61 65 6c 2d 63 62 63 40 6c 79 73 61  ijndael-cbc@lysa

  000000e0  74 6f 72 2e 6c 69 75 2e 73 65 2c 61 65 73 31 32  tor.liu.se,aes12

  000000f0  38 2d 63 74 72 2c 61 65 73 31 39 32 2d 63 74 72  8-ctr,aes192-ctr

  00000100  2c 61 65 73 32 35 36 2d 63 74 72 00 00 00 87 61  ,aes256-ctr....a

  00000110  65 73 31 32 38 2d 63 62 63 2c 33 64 65 73 2d 63  es128-cbc,3des-c

  00000120  62 63 2c 62 6c 6f 77 66 69 73 68 2d 63 62 63 2c  bc,blowfish-cbc,

  00000130  63 61 73 74 31 32 38 2d 63 62 63 2c 61 72 63 66  cast128-cbc,arcf

  00000140  6f 75 72 2c 61 65 73 31 39 32 2d 63 62 63 2c 61  our,aes192-cbc,a

  00000150  65 73 32 35 36 2d 63 62 63 2c 72 69 6a 6e 64 61  es256-cbc,rijnda

  00000160  65 6c 2d 63 62 63 40 6c 79 73 61 74 6f 72 2e 6c  el-cbc@lysator.l

  00000170  69 75 2e 73 65 2c 61 65 73 31 32 38 2d 63 74 72  iu.se,aes128-ctr

  00000180  2c 61 65 73 31 39 32 2d 63 74 72 2c 61 65 73 32  ,aes192-ctr,aes2

  00000190  35 36 2d 63 74 72 00 00 00 55 68 6d 61 63 2d 6d  56-ctr...Uhmac-m

  000001a0  64 35 2c 68 6d 61 63 2d 73 68 61 31 2c 68 6d 61  d5,hmac-sha1,hma

  000001b0  63 2d 72 69 70 65 6d 64 31 36 30 2c 68 6d 61 63  c-ripemd160,hmac

  000001c0  2d 72 69 70 65 6d 64 31 36 30 40 6f 70 65 6e 73  -ripemd160@opens

  000001d0  73 68 2e 63 6f 6d 2c 68 6d 61 63 2d 73 68 61 31  sh.com,hmac-sha1

  000001e0  2d 39 36 2c 68 6d 61 63 2d 6d 64 35 2d 39 36 00  -96,hmac-md5-96.

  000001f0  00 00 55 68 6d 61 63 2d 6d 64 35 2c 68 6d 61 63  ..Uhmac-md5,hmac

  00000200  2d 73 68 61 31 2c 68 6d 61 63 2d 72 69 70 65 6d  -sha1,hmac-ripem

  00000210  64 31 36 30 2c 68 6d 61 63 2d 72 69 70 65 6d 64  d160,hmac-ripemd

  00000220  31 36 30 40 6f 70 65 6e 73 73 68 2e 63 6f 6d 2c  160@openssh.com,

  00000230  68 6d 61 63 2d 73 68 61 31 2d 39 36 2c 68 6d 61  hmac-sha1-96,hma

  00000240  63 2d 6d 64 35 2d 39 36 00 00 00 09 6e 6f 6e 65  c-md5-96....none

  00000250  2c 7a 6c 69 62 00 00 00 09 6e 6f 6e 65 2c 7a 6c  ,zlib....none,zl

  00000260  69 62 00 00 00 00 00 00 00 00 00 00 00 00 00     ib.............

 

 

3.2.10  Razmjena ključeva

 

Nakon što su utvrđeni svi potrebni algoritmi koji će se koristiti, kreće postupak razmjene ključeva i autentificiranja poslužitelja. Iako je teoretski moguće koristiti bilo koju metodu oko koje se klijent i poslužitelj dogovore, algoritam razmjene ključa koji se trenutno koristi u svim implementacijama je Diffie-Hellman algoritam. Uz njega se u postupku još koriste DSS ili RSA algoritam, a njihova funkcija je ovdje autentificiranje poslužitelja. 

Slijedi opis kompletnog postupka korak po korak. U opisu V_C označava klijentov identifikacijski niz, V_S je poslužiteljev identifikacijski niz, p i g su unaprijed poznati parametri Diffie-Hellman razmjene, p je veliki prosti broj, a g je generator za grupu GF(p), K_S je poslužiteljev javni ključ, I_C je klijentova SSH_MSG_KEXINIT poruka, a I_S je poslužiteljeva SSH_MSG_KEXINIT poruka.

1.                   klijent generira veliki slučajni broj x i računa broj e, e = g^x mod p. Klijent šalje broj e poslužitelju.

2.                   Poslužitelj generira slučajni broj y i računa broj f, f = g^y mod p. Poslužitelj prima broj e. Tada računa tajni ključ K, K = e^y mod p. Također računa H, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K). Poslužitelj potpisuje H svojim privatnim ključem i dobiva potpis s. Poslužitelj šalje (K_S || f || s) klijentu.

3.                   Klijent provjerava da javni ključ K_S stvarno pripada poslužitelju (bilo pomoću certifikata ili pomoću lokalne baze ključeva). Klijent može prihvatiti poslužiteljev ključ i bez provjere, ali to čini protokol ranjivim na man-in-the-middle napade. Klijent također računa tajni ključ K, K = f^x mod p, računa H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) i provjerava da li je s ispravan potpis od H.

 

Vidimo da kao rezultat razmjene dobivamo K, što je tajni ključ poznat samo klijentu i poslužitelju, a ne potencijalnim napadačima koji su prisluškivali promet. To je osigurano zbog težine računanja diskretnog logaritma na vrijednostima e i f.

Ako nismo provjerili da javni kjuč stvarno pripada poslužitelju tada je moguć aktivni napad, u kojem bi se potencijalni napadač nalazio između klijenta i poslužitelja i tako iskoristio slabost Diffie-Helman algoritma na man-in-the-middle napade.

 

Slijedi opis poruka kojima se ostvaruje gore opisana razmjena.

 

Klijent na početku šalje ovaj paket:

byte      SSH_MSG_KEXDH_INIT
mpint     parametar e

 

Poslužitelj odgovara slanjem paketa:

 

byte      SSH_MSG_KEXDH_REPLY
string    javni ključ poslužitelja i eventualno certifikati(K_S)
mpint     parametar f
string    potpis poslužitelja s

 

Na sljedećem isječku iz log datoteke programa Putty vidi se kako ta razmjena poruka izgleda u praksi:

 

Outgoing packet type 30 / 0x1e (SSH2_MSG_KEXDH_INIT)

  00000000  00 00 01 00 7b 9b 14 1c 58 76 a8 a8 75 89 ee a5  ....{...Xv..u...

  00000010  cc 6f e1 7a c8 0a 1e 2c 98 de 7e fc 43 d2 b3 a0  .o.z...,..~.C...

  00000020  4e 7f 17 11 81 34 72 b8 60 bb 0f f2 49 53 d0 0c  N....4r.`...IS..

  00000030  e8 14 79 1c 7d 7a 64 43 da f3 3b cd 84 67 ab 33  ..y.}zdC..;..g.3

  00000040  e0 c5 3f 84 fb f6 f9 b7 df 94 f5 63 99 02 77 c4  ..?........c..w.

  00000050  48 2c 4e f0 39 aa ee 68 41 79 2a 1a 27 53 63 8d  H,N.9..hAy*.'Sc.

  00000060  69 be 06 2f 80 19 dc ac 4a 12 1c 5d 2e 99 cd 1c  i../....J..]....

  00000070  19 d8 4e e4 10 08 b3 66 87 6c d6 35 3e 76 00 cc  ..N....f.l.5>v..

  00000080  93 74 93 13 06 3e 30 94 23 48 26 5a 17 1d a8 97  .t...>0.#H&Z....

  00000090  7b d7 db e4 21 86 d7 7d f6 1e 9e e7 1c 39 e9 69  {...!..}.....9.i

  000000a0  54 43 0b 74 73 46 e1 5c 78 6b 7f d9 d2 eb 6c 1f  TC.tsF.\xk....l.

  000000b0  38 f8 fc 16 33 7f c2 13 ff 27 c9 bc 55 f2 08 ae  8...3....'..U...

  000000c0  c0 b3 c7 fc 89 56 f0 69 f6 42 da 60 b0 e2 90 2f  .....V.i.B.`.../

  000000d0  dc 37 98 b4 c1 02 d3 1e a0 1a c3 b1 b8 62 45 31  .7...........bE1

  000000e0  38 d5 05 92 67 c7 4c 6b 93 9b aa b4 29 bc b8 8a  8...g.Lk....)...

  000000f0  a8 c5 de f8 22 13 11 54 f0 b6 00 8b 0b b1 61 b7  ...."..T......a.

  00000100  9a 3f 2d b9                                      .?-.

Incoming packet type 31 / 0x1f (SSH2_MSG_KEXDH_REPLY)

  00000000  00 00 00 95 00 00 00 07 73 73 68 2d 72 73 61 00  ........ssh-rsa.

  00000010  00 00 01 23 00 00 00 81 00 da b9 53 d1 51 28 36  ...#.......S.Q(6

  00000020  a2 62 67 bb a4 56 f0 ae 37 86 56 88 56 4f 73 a3  .bg..V..7.V.VOs.

  00000030  5e f3 8a 9f 2f 11 86 ee 6f 1a 2b 76 11 83 61 d6  ^.../...o.+v..a.

  00000040  7f 44 ee 26 7d aa 2d ef 10 02 75 e0 f2 40 ba aa  .D.&}.-...u..@..

  00000050  4a a8 df 60 28 6a 49 f6 7b 36 95 1f f8 ab 34 5e  J..`(jI.{6....4^

  00000060  f2 16 63 4e 20 31 64 ae 94 1e e9 dd 61 61 f3 c3  ..cN 1d.....aa..

  00000070  90 9f b3 8e 22 30 f1 08 50 83 68 ca 94 ad 82 d4  ...."0..P.h.....

  00000080  d3 25 26 69 66 91 79 ea 7c 7b 03 50 b1 fb 4a be  .%&if.y.|{.P..J.

  00000090  e3 40 f6 b1 e2 51 40 32 f9 00 00 01 00 59 a2 72  .@...Q@2.....Y.r

  000000a0  68 b7 16 49 a3 c9 f1 59 0a 67 3a b6 04 24 50 29  h..I...Y.g:..$P)

  000000b0  dc ab 66 85 51 88 7b 1f 2d 34 96 bc ba ed 01 db  ..f.Q.{.-4......

  000000c0  92 f7 d0 71 14 e8 57 28 f0 40 61 0f 0c 73 40 72  ...q..W(.@a..s@r

  000000d0  39 a9 51 59 f8 d7 02 d8 6a ff 5a be 48 95 90 ca  9.QY....j.Z.H...

  000000e0  ac 1d f5 2c 79 2e 7a a3 dd 18 da 30 a4 87 30 6f  ...,y.z....0..0o

  000000f0  bd 05 d7 f6 87 69 22 87 03 e4 73 4f 13 a2 66 71  .....i"...sO..fq

  00000100  39 0e 0c 9e 5d a0 38 32 d8 fb 42 90 b8 44 7f 1a  9...].82..B..D..

  00000110  92 c6 fe 0b b7 ac 72 3b f7 57 75 aa 49 fa 06 9a  ......r;.Wu.I...

  00000120  3c ef 28 44 6f 80 97 fd a5 3a 31 4e 0e e0 86 4a  <.(Do....:1N...J

  00000130  88 cb 66 6b b6 dd 84 e1 df ef 87 a0 41 6e ac 6c  ..fk........An.l

  00000140  de 42 06 e9 48 13 40 62 b3 d0 f6 36 a6 49 94 0a  .B..H.@b...6.I..

  00000150  2d 9e 4d ce ef b9 3e 02 c1 90 f3 70 62 52 54 2f  -.M...>....pbRT/

  00000160  90 27 b3 b2 f4 e2 64 8f 53 81 26 0a ff b0 cd bb  .'....d.S.&.....

  00000170  ab 78 a3 1f 40 b4 3f aa 1f 98 b9 47 0a c5 34 2c  .x..@.?....G..4,

  00000180  c3 9a 9b 43 ac 22 f3 65 86 9e 81 56 d3 4b 81 53  ...C.".e...V.K.S

  00000190  a1 c6 24 a9 24 82 46 a9 b9 a1 37 49 ff 00 00 00  ..$.$.F...7I....

  000001a0  8f 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 80  .....ssh-rsa....

  000001b0  74 bb 21 5e 51 c0 88 e7 25 be cf 87 62 c4 70 a1  t.!^Q...%...b.p.

  000001c0  0e 11 17 e8 ba 6a fb df 75 d8 e3 72 64 7e 26 13  .....j..u..rd~&.

  000001d0  34 95 41 4b 71 0b 62 c2 b7 5e f4 02 f1 3a 8d 8e  4.AKq.b..^...:..

  000001e0  ed 88 61 a3 be ce 38 6c be 00 9b 10 9b 31 99 d9  ..a...8l.....1..

  000001f0  50 bf 51 a5 3e 1c 56 d9 72 7c 36 88 48 fb 62 2b  P.Q.>.V.r|6.H.b+

  00000200  12 bc d7 da ed 03 af 8f bc dd e2 ec 9e 45 02 91  .............E..

  00000210  3f f4 c6 fe 82 a8 5a 7b d8 4d f6 89 1b 0d 20 f1  ?.....Z{.M.... .

  00000220  35 ee ba 91 de 44 93 f7 34 87 c1 16 50 b1 07 d9  5....D..4...P...

 

 

Na kraju razmjene ključeva kao rezultat imamo vrijednosti K (tajni ključ) i H (sažetak razmjene). Svi ključevi za enkripciju i MAC dobivaju se iz te dvije vrijednosti. Sažetak H iz prve razmjene se također koristi kao identifikator sjednice (session identifier), koji se koristi u autentifikacijskim metodama kao dio podataka koji se digitalno potpisuje privatnim ključem korisnika. Taj identifikator ostaje isti tokom cijelog trajanja veze.

 

Ključevi se generiraju korištenjem hash funkcije koja je dio algoritma razmjene ključeva. Tako se u algoritmu "diffie-hellman-group1-sha1" koristi SHA1 funkcija. Generiraju se drugi ključevi za svaki smjer enkripcije. Ključevi se računaju na sljedeći način:

Inicijalni IV (klijent -> poslužitelj) 
                               = hash (K || H || "A" || identifikator_sjednice)
Inicijalni IV (poslužitelj -> klijent) 
                               = hash (K || H || "B" || identifikator_sjednice)
Ključ enkripcije (klijent -> poslužitelj) 
                               = hash (K || H || "C" || identifikator_sjednice)
Ključ enkripcije (poslužitelj -> klijent)
                               = hash (K || H || "D" || identifikator_sjednice)
MAC ključ (klijent -> poslužitelj)
                               = hash (K || H || "E" || identifikator_sjednice)
MAC ključ (klijent -> poslužitelj)
                               = hash (K || H || "F" || identifikator_sjednice)

Ovdje su znakovi od "A" do "F"  zapravo obični ASCII znakovi, a identifikator sjednice i vrijednost H, su jednaki kod prve razmjene ključeva.

 

Razmjena ključeva završava tako što sva strana pošalje paket:

 

byte      SSH_MSG_NEWKEYS

 

Ovaj paket se šalje primjenjujuće stare ključeve. Svaka poruka poslana nakon ove mora koristiti nove ključeve i algoritme. Nakon što jedna strana  primi ovu poruku ona od tog trenutka pa nadalje mora koristiti nove ključeve za primanje podataka.

Nakon završetka razmjene ključeva klijent će zatražiti pokretanje određene usluge sljedećim paketom:

 

byte      SSH_MSG_SERVICE_REQUEST
string    ime usluge

 

Svaka usluga ima svoje dodijeljeno ime. Najznačajnije su ove dvije usluge:

-              ssh-userauth

-              ssh-connection

koje redom označavaju autentifikacijski i spojni protokol. Gotovo uvijek nakon završetka razmjene ključeva klijent će zatražiti pokretanje usluge autentifikacije (ssh-userauth).

 

Ako poslužitelj podržava traženu uslugu i želi prihvatiti poslani zahtjev on to dojavljuje klijentu paketom:

 

byte      SSH_MSG_SERVICE_ACCEPT
string    ime usluge

 

Ako, ipak, poslužitelj ne želi prihvatit klijentov zahtjev on to čini slanjem sljedeće poruke i nakon toga se odspaja:

 

byte      SSH_MSG_DISCONNECT
uint32    identifikator razloga prekida
string    opis razloga prekida veze u UTF-8 formatu
string    oznaka jezika

 

 

3.3      Autentifikacijski protokol

 

Nakon uspostavljanja sigurnog kanala, korisnik zahtijeva pokretanje usluge autentifikacije (ssh-userauth). Nakon što poslužitelj odobri zahtjev počinje proces autentifikacije. Na početku ovaj protokol prima identifikator sjednice od prijenosnog protokola (to je sažetak razmjene H, iz prve razmjene ključeva). Taj identifikator će se koristiti za digitalno potpisivanje ako to odabrana metoda autentifikacije bude zahtijevala.

Autentifikacijski proces predvodi poslužitelj, tako da klijentu šalje poruke u kojima navodi metode autentifikacije koje on podržava. Klijent može po svojoj želji odabrati metodu iz liste koju želi probati, bez obzira na redoslijed kojim su one navedene. Svaka autentifikacijska metoda identificira se prema svom rezerviranom imenu (npr. "password", "publickey",...). Postoji također i "none" metoda koja označava da nema autentifikacije i da je svakom korisniku dopušten pristup. Tu metodu poslužitelj ne smije navesti kao jednu od dopuštenih metoda autentifikacije. Međutim, klijent smije poslati zahtjev za "none" autentifikacijom. U najvećem broju slučajeva to će rezultirati time da će mu poslužitelj poslati poruku da autentifikacija nije uspjela i u toj poruci navesti autentifikacijske metode koje on podržava. Ako je pak poslužitelj konfiguriran tako da prihvaća "none" autentifikaciju, klijentu će biti omogućen pristup.

Nakon svakog neuspješnog pokušaja autentifikacije klijentu je omogućen ponovni pokušaj. Ipak, standard preporuča da se broj neuspjelih pokušaja ograniči na 20. Nakon tog broja pokušaja poslužitelj bi trebao prekinuti vezu.

 

3.3.1      Zahtjevi za autentifikacijom

 

Zahtjeve za autentifikacijom klijent ostvaruje slanjem sljedeće poruke:

 

byte      SSH_MSG_USERAUTH_REQUEST
string    korisničko ime 
string    ime usluge
string    naziv metode autentifikacije
....      specifična polja za svaku metodu

 

Poslani paket je tipa SSH_MSG_USERAUTH_REQUEST, nakon toga ide korisničko ime tog korisnika na računalu na koje se spaja. Zatim ide polje s nazivom usluge koju treba pokrenuti ako autentifikacija uspije (to je gotovo uvijek "ssh-connection", što označava spojni protokol). Nakon toga ide naziv metode autentifikacije koju klijent želi. Najvažnije metode dane su u tablici 7.

 

Tablica 7 : Najčešće metode autentifikacije

Ime metode
Zahtjev
publickey
obavezno
password
preporučeno
keyboard-interactive
opcionalno
hostbased
opcionalno
none
ne preporuča se

 

Od navedenih metoda jedino "publickey" metodu moraju podržavati sve implementacije. Ovaj popis nije konačan, i moguće je definirati i nove metode.

 

Ako poslužitelj odbije autentifikacijski zahtjev klijenta on će to učiniti slanjem sljedeće poruke:

 

byte         SSH_MSG_USERAUTH_FAILURE
name-list    autentifikacijske metode koje prihvaćam
boolean      djelomičan uspjeh

 

Dakle, poslužitelj šalje listu metoda koje on u tom trenutku može prihvatiti. Logička vrijednost djelomičan uspjeh koristi se ako je za autentifikaciju potrebno više od jedne metode. Na primjer, poslužitelj može zahtijevati da se korisnik mora autentificirati i "password" metodom i "publickey" metodom. Nakon što korisnik pošalje "password" zahtjev sa ispravnom lozinkom, poslužitelj će mu odgovoriti sa SSH_MSG_USERAUTH_FAILURE paketom u kojem će vrijednost varijable djelomičan uspjeh biti istina, a u listi prihvatljivih metoda neće biti navedena "password" metoda. To govori klijentu da je autentifikacija lozinkom prošla uspješno, ali da poslužitelj zahtjeva još jednu metodu autentifikacije da bi proces uspješno završio.

 

Kada poslužitelj u potpunosti prihvati autentifikaciju on šalje paket:

 

byte      SSH_MSG_USERAUTH_SUCCESS

 

 

3.3.2      Autentifikacija pomoću javnog ključa ("publickey")

 

Ova metoda je jedina koju obavezno moraju podržavati sve implementacije. Međutim, to ne znači da ona mora biti i jedina dopuštena, s obzirom da dosta korisnika nema svoj privatni ključ za autentifikaciju.

 

Ova metoda funkcionira tako da klijent pošalje poslužitelju digitalni potpis koji on stvara svojim privatnim ključem. Također pošalje i svoj javni ključ. Poslužitelj provjerava da taj javni ključ pripada tom korisniku. Najčešće se to radi tako da svaki korisnik u svom direktoriju na poslužitelju ima stvorenu datoteku u kojoj se nalaze njegovi javni ključevi. Na UNIX operacijskim sustavima to je datoteka "authorized_keys2" za verziju 2 protokola i "authorized_keys" za verziju 1 protokola. Sadžaj te datoteke može izgledati otprilike ovako:

 

ssh-dss AAAAB3NzaC1kc3MAAACBALJfoU2SAyLcuXwUpFqX4DKhUcEFNUdDmugGB1RgF

d6HEfuDrPdytgL0pewE3uTeoYwJxfcw8t7TbwpCYJPvcwV0aohXEhJ3qKAaqG9oPsUZeF

myEm8WAU7Ozg+6aJ1G8KBJTHzvVSMm3KucR+fnuNFz0uthScHMueG0pkQPC/9HAAAAFQD

makscBtZRBqddtnSpjej3I8c7ewAAAIEArQOUgxipjLvTKS22y5zoNRMVQzmaIOoj+Fzw

zb1LLm5cCW3JUQSeZ+luoY/jyuYxG6PH/6wl8u2L19lcOS7t7OJVwpS1BHL585N+s7odS

KCGMKB2XY0xIFVcRFp7jUZ/C+sWFkLrlx0fhYqaRXsyCIQyA+U/hA3kX+wpZ4U2J8IAAA

CAKVpU3GCiVDLWlelR4MI7XbplvLTFrUGN7rPHu62mJl6zprZua8I52z3ObUtz3NvmIcH

tql8zXWUCMcv4wN4VJIXCppRmTCPPLwYvkAph7c2F7EdJ2YdjPONaBfLbmmGqENUS7yeV

7sAjI92wz3wuKPj+UlxmtMfKzX2EdH6KX6U=

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBWSRmalBYDgsjvcyzV48EHfCt7rkiJ3Jhrl

1TNo8PPMUv9eB4MS3pfQgaxBLvIOHpypzYwPAgQNXcMz7qN2ObNWJxaKbgMoZM022m+ym

OZg4p9Fy6uadOfGj6ehcnnRqY0AhCACohjzutP8GwNXEk0P+HtFG47vmCoMHpdpX6gaw==

 

Ovdje vidimo da korisnik ima dva ključa, jedan RSA i jedan DSS ključ, kodirano base64 algoritmom. Da bi taj korisnik uspješno izvršio autentifikaciju "publickey" metodom, u njegovom  zahtjevu mora biti jedan od ta dva ključa. Također, digitalni potpis koji on pošalje provjeravat će se tim javnim ključem.

 

Privatni ključevi klijenta obično su pohranjeni na njegovom osobnom računalu, i da bi se očuvala sigurnost ove metode potrebno je da oni budu dobro zaštićeni. Najbolja metoda za to je, da korisnik prilikom generiranja ključa, zaštiti istog unošenjem takozvanog passphrase niza, što će rezultirati time da će privatni ključ biti kriptiran. Passphrase niz je duži od lozinke i može sadržavati i znakove razmaka. Svaki put kad on bude potreban, korisnik će biti upitan za unošenje passphrase niza.

 

Slijedi opis razmjene poruka ovom metodom autentifikacije. Da bi klijent provjerio da li poslužitelj prihvaća njegov javni ključ on šalje sljedeću poruku:

 

byte      SSH_MSG_USERAUTH_REQUEST
string    korisničko ime
string    ime usluge
string    "publickey"
boolean   NE
string    ime algoritma javnog ključa
string    javni ključ

 

Kao što se vidi to je standardna SSH_MSG_USERAUTH_REQUEST poruka kako je opisana gore. Specifična polja su ovdje "publickey" što označava da koristimo autentifikaciju javnim ključem. Logička varijabla NE označava da ovaj paket ne sadrži digitalni potpis. Zatim ide ime algoritma javnog ključa, najčešće su to "ssh-rsa" ili "ssh-dss", i na kraju ide javni ključ u formatu opisanom u poglavlju 3.2.8.

 

Ako poslužitelj ne prihvaća ponuđeni javni ključ on odgovara slanjem SSH_MSG_USERAUTH poruke. Ako poslužitelj prihvaća ponuđeni ključ on će dojaviti klijentu slanjem poruke:

 

byte      SSH_MSG_USERAUTH_PK_OK
string    ime algorima iz zahtjeva
string    javni ključ iz zahtjeva

 

Nakon što dozna da poslužitelj prihvaća njegov javni ključ, klijent pomoću svog privatnog ključa stvara digitalni potpis i šalje sljedeću poruku:

 

byte      SSH_MSG_USERAUTH_REQUEST
string    korisničko ime
string    ime usluge
string    "publickey"
boolean   DA
string    ime algoritma javnog ključa
string    javni ključ
string    digitalni potpis

  

Poruka je ista kao i prethodna koju je klijent poslao, s tom razlikom da je sada na kraju poruke i digitalni potpis klijenta, a logička varijabla sada ima vrijednost DA, što označava da je potpis prisutan. Inače, klijent može odmah poslati ovu poruku bez da prvo provjerava da li poslužitelj prihvaća njegov javni ključ, ali tada postoji rizik da će klijent uzalud računati potpis (što je računski skupa operacija).

 

Potpis se računa primjenom odabranog algoritma, pomoću klijentovog privatnog ključa nad porukom koja izgleda ovako:

 

string    identifikator_sjednice
byte      SSH_MSG_USERAUTH_REQUEST
string    korisničko ime
string    ime usluge
string    "publickey"
boolean   DA
string    ime algoritma javnog ključa
string    javni ključ
 

Primitkom ovog paketa, poslužitelj provjerava da li je ponuđeni javni ključ prihvatljiv, i zatim provjerava poslani digitalni potpis poslanim javnim ključem. Ako je potpis ispravan poslužitelj šalje SSH_MSG_USERAUTH_SUCCESS poruku, ako nije šalje SSH_MSG_USERAUTH_FAILURE poruku.

 
U ovom isječku iz log datoteke programa Putty može se vidjeti kako ta razmjena izgleda u praksi:
 
Outgoing packet type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
  00000000  00 00 00 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d  ....tiho....ssh-
  00000010  63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 04 6e 6f  connection....no
  00000020  6e 65                                            ne
Incoming packet type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
  00000000  00 00 00 27 70 75 62 6c 69 63 6b 65 79 2c 70 61  ...'publickey,pa
  00000010  73 73 77 6f 72 64 2c 6b 65 79 62 6f 61 72 64 2d  ssword,keyboard-
  00000020  69 6e 74 65 72 61 63 74 69 76 65 00              interactive.
Outgoing packet type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
  00000000  00 00 00 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d  ....tiho....ssh-
  00000010  63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 09 70 75  connection....pu
  00000020  62 6c 69 63 6b 65 79 00 00 00 00 07 73 73 68 2d  blickey.....ssh-
  00000030  72 73 61 00 00 00 95 00 00 00 07 73 73 68 2d 72  rsa........ssh-r
  00000040  73 61 00 00 00 01 23 00 00 00 81 00 b8 fa 70 fb  sa....#.......p.
  00000050  8e ae 54 85 5c 47 3c 4d d5 61 75 02 23 8e c1 09  ..T.\G<M.au.#...
  00000060  74 f3 9e 44 05 18 9c ba 2a 5e 48 cd 3c 01 9f d4  t..D....*^H.<...
  00000070  4a 30 e9 68 b3 c4 46 ef af 0e fa 12 d5 8b 55 35  J0.h..F.......U5
  00000080  d6 92 bb ed 6c 64 b2 7d f2 b9 eb 0f d4 e1 bd cc  ....ld.}........
  00000090  ed 12 da 97 be 12 a6 fe ea a3 17 d0 05 fa 01 a3  ................
  000000a0  f5 79 29 c8 a1 e5 ea 97 22 e6 14 a5 75 dc 79 c0  .y)....."...u.y.
  000000b0  18 33 89 05 ed 04 06 5d dc 91 fd 63 26 42 2e 63  .3.....]...c&B.c
  000000c0  18 06 bd bf 21 98 0a 66 2d e9 0f e5              ....!..f-...
Incoming packet type 60 / 0x3c (SSH2_MSG_USERAUTH_PK_OK)
  00000000  00 00 00 07 73 73 68 2d 72 73 61 00 00 00 95 00  ....ssh-rsa.....
  00000010  00 00 07 73 73 68 2d 72 73 61 00 00 00 01 23 00  ...ssh-rsa....#.
  00000020  00 00 81 00 b8 fa 70 fb 8e ae 54 85 5c 47 3c 4d  ......p...T.\G<M
  00000030  d5 61 75 02 23 8e c1 09 74 f3 9e 44 05 18 9c ba  .au.#...t..D....
  00000040  2a 5e 48 cd 3c 01 9f d4 4a 30 e9 68 b3 c4 46 ef  *^H.<...J0.h..F.
  00000050  af 0e fa 12 d5 8b 55 35 d6 92 bb ed 6c 64 b2 7d  ......U5....ld.}
  00000060  f2 b9 eb 0f d4 e1 bd cc ed 12 da 97 be 12 a6 fe  ................
  00000070  ea a3 17 d0 05 fa 01 a3 f5 79 29 c8 a1 e5 ea 97  .........y).....
  00000080  22 e6 14 a5 75 dc 79 c0 18 33 89 05 ed 04 06 5d  "...u.y..3.....]
  00000090  dc 91 fd 63 26 42 2e 63 18 06 bd bf 21 98 0a 66  ...c&B.c....!..f
  000000a0  2d e9 0f e5                                      -...
Outgoing packet type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
  00000000  00 00 00 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d  ....tiho....ssh-
  00000010  63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 09 70 75  connection....pu
  00000020  62 6c 69 63 6b 65 79 01 00 00 00 07 73 73 68 2d  blickey.....ssh-
  00000030  72 73 61 00 00 00 95 00 00 00 07 73 73 68 2d 72  rsa........ssh-r
  00000040  73 61 00 00 00 01 23 00 00 00 81 00 b8 fa 70 fb  sa....#.......p.
  00000050  8e ae 54 85 5c 47 3c 4d d5 61 75 02 23 8e c1 09  ..T.\G<M.au.#...
  00000060  74 f3 9e 44 05 18 9c ba 2a 5e 48 cd 3c 01 9f d4  t..D....*^H.<...
  00000070  4a 30 e9 68 b3 c4 46 ef af 0e fa 12 d5 8b 55 35  J0.h..F.......U5
  00000080  d6 92 bb ed 6c 64 b2 7d f2 b9 eb 0f d4 e1 bd cc  ....ld.}........
  00000090  ed 12 da 97 be 12 a6 fe ea a3 17 d0 05 fa 01 a3  ................
  000000a0  f5 79 29 c8 a1 e5 ea 97 22 e6 14 a5 75 dc 79 c0  .y)....."...u.y.
  000000b0  18 33 89 05 ed 04 06 5d dc 91 fd 63 26 42 2e 63  .3.....]...c&B.c
  000000c0  18 06 bd bf 21 98 0a 66 2d e9 0f e5 00 00 00 8f  ....!..f-.......
  000000d0  00 00 00 07 73 73 68 2d 72 73 61 00 00 00 80 0c  ....ssh-rsa.....
  000000e0  84 94 17 aa 16 e0 32 7b 00 65 14 ed d2 44 4f c0  ......2{.e...DO.
  000000f0  85 6b d7 74 0d 77 5b fa 2c ee a0 d6 6b fc 28 15  .k.t.w[.,...k.(.
  00000100  8c 2c b1 b3 10 b2 ed 8b 8f 4e fa 81 91 92 36 98  .,.......N....6.
  00000110  64 01 38 88 71 62 52 4b 12 53 98 64 e8 69 cc b8  d.8.qbRK.S.d.i..
  00000120  d7 17 87 f2 fb 2f 17 d1 24 a8 10 fa f6 05 8a 7f  ...../..$.......
  00000130  27 5e cb 88 27 37 81 d5 2e 20 8e fd 9b e3 d4 b1  '^..'7... ......
  00000140  81 4e 14 40 12 14 13 65 46 2b 4a e3 33 f1 d4 cd  .N.@...eF+J.3...
  00000150  18 f7 3e f9 81 d7 e0 f3 f2 f8 56 f4 92 d2 0d     ..>.......V....
Incoming packet type 52 / 0x34 (SSH2_MSG_USERAUTH_SUCCESS)
 
 

3.3.3      Autentifikacija pomoću lozinke ("password")

 

Metoda autentifikacije lozinkom je najkorištenija metoda autentifikacije. Autentifikacijski protokol koristi prijenosni protokol SSH, koji nudi tajnost i integritet poslanih podataka. Sve što se prenosi je kriptirano pa se zbog toga lozinke koje se prenose tim kanalom ne mogu doznati prisluškivanjem kanala.

 
Klijent zahtijeva autentifikaciju lozinkom slanjem sljedeće poruke:
 
byte      SSH_MSG_USERAUTH_REQUEST
string    korisničko ime
string    ime usluge
string    "password"
boolean   NE
string    lozinka
 

Kao što se vidi metoda autentifikacije navedena u poruci mora biti "password". Lozinke se kodiraju UTF-8 kodom. Nakon primitka ove poruke zadaća je poslužitelja da provjeri ispravnost lozinke što ovisi o operacijskom sustavu koji se koristi i njegovoj konfiguraciji.

 

Ako je lozinka zastarila, poslužitelj ne smije dopustiti autentifikaciju starom lozinkom već mora zahtijevati njenu promjenu. To on radi slanjem poruke:

 
byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
string    poruka o tome kako je lozinka zastarila
string    identifikacijski kod jezika poruke
 

U tom slučaju klijent može nastaviti pokušati se autentificirati drugom metodom ili može prikazati klijentu poruku i zatražiti ga unos nove lozinke. Ako je korisnik unio novu lozinku ona se prosljeđuje poslužitelju u sljedećoj poruci:

 
byte      SSH_MSG_USERAUTH_REQUEST
string    korisničko ime
string    ime usluge
string    "password"
boolean   DA
string    stara lozinka
string    nova lozinka
 

Ako nova lozinka ne zadovoljava pravila o duljini i sastavu koja nameće poslužitelj, tada on ponovo šalje poruku sa zahtjevom za promjenom lozinke.

 

Na kraju, ako je autentifikacija uspjela, poslužitelj šalje SSH_MSG_USERAUTH_SUCCESS poruku, a ako nije on šalje SSH_MSG_USERAUTH_FAILURE poruku.

 

 

3.3.4      "hostbased" autentifikacija

 

Ova vrsta autentifikacije slična je metodi koju koriste UNIX r-naredbe, u kojima nakon što poslužitelj dobije zahtjev, on iz mrežne adrese klijenta pronalazi njegovo ime (FQDN – Fully Qualified Domain Name), i ako je to ime u lokalnoj datoteci (.rhosts) tada je klijent autentificiran. U "hostbased" metodi se osim provjeravanja da li je ime računala spremljeno u lokalnu bazu kao računalo kome je dopuštena autentifikacija, traži i javni ključ tog računala, a ako je on nađen u lokalnoj bazi, provjerava se  i poslani digitalni potpis.

 

Klijent inicira "hostbased" autentifikaciju slanjem poruke:

 

byte      SSH_MSG_USERAUTH_REQUEST
string    korisničko ime
string    ime usluge
string    "hostbased"
string    algoritam javnog ključa
string    javni ključ računala klijenta
string    ime (FQDN) klijentskog računala
string    korisničko ime na klijentskom računalu
string    digitalni potpis

 

Digitalni potpis se računa privatnim ključem računala klijenta, a kao poruka se uzima:

 

string    identifikator_sjednice
byte      SSH_MSG_USERAUTH_REQUEST
string    korisničko ime
string    ime usluge
string    "hostbased"
string    algoritam javnog ključa
string    javni ključ računala klijenta
string    ime (FQDN) klijentskog računala
string    korisničko ime na klijentskom računalu

 

Nakon primitka ove poruke, poslužitelj iz mrežne adrese klijenta provjerava da li je FQDM ime računala isto kao i u zahtjevu. Zatim provjerava u lokalnoj bazi da li poslani javni ključ stvarno pripada tom računalu i da li je tom računalu i prijavljenom korisniku dopuštena autentifikacija. Na kraju provjerava poslani digitalni potpis. Ako je autentifikacija uspjela poslužitelj šalje SSH_MSG_USERAUTH_SUCCESS paket, a ako nije on šalje SSH_MSG_USERAUTH_FAILURE paket sa podržanim metodama autentifikacije.

 

3.4      Spojni protokol

 

Spojni protokol je najviši sloj SSH protokola i vrti se iznad prijenosnog i autentifikacijskog sloja. Ta dva protokola i sigurnost koju oni nude nužni su za rad spojnog protokola. Spojni protokol nudi usluge kao što su interaktivne sjednice (interactive login session), udaljeno izvršavanje naredbi, prosljeđivanje TCP/IP prometa, i tuneliranje X11 konekcija.

Osnovni pojam u SSH spojnom protokolu je kanal. Sve interaktivne sjednice i prosljeđivanja vrše se kroz kanale. Oni su doduše samo virtualni koncept jer se svi otvoreni kanali multipleksiraju kroz jednu vezu, uspostavljenu još u prijenosnom sloju.

Svaki kanal je određen brojem ili identifikatorom na svakom svom kraju (lokalnom i udaljenom), i ti brojevi mogu čak i biti različiti za svaki kraj. Svaki zahtjev za otvaranjem novog kanala sadrži u sebi identifikator kanala koji pripada pošiljatelju. Sve druge poruke spojnog protokola u sebi sadrže identifikator kanala primatelja. Za kontrolu toka podataka (flow control) koristi se koncept klizećih prozora, što znači da nije dopušteno slanje podataka, ako suprotna strana nema dovoljno velik prozor sve dok ona ne dojavi da povećava veličinu prijemnog prozora.

 

3.4.1      Otvaranje kanala

 

Kada jedna strana želi otvoriti novi kanal ona prvo dodijeli lokalni identifikator tom kanalu i pošalje suprotnoj strani sljedeću poruku:

 

byte      SSH_MSG_CHANNEL_OPEN
string    vrsta kanala
uint32    broj kanala pošiljatelja
uint32    inicijalna veličina prozora
uint32    maksimalna veličina paketa
....      podaci ovisni o vrsti kanala

 

Inicijalna veličina prozora predstavlja broj bajtova koje je moguće poslati pošiljatelju ove poruke prije nego što on poveća veličinu prozora. Maksimalna veličina paketa označava maksimalnu veličinu pojedinačnog paketa, koju pošiljatelj ove poruke može primiti. Poželjno je da to bude što manje kod interaktivnih sjednica, da bi vrijeme odgovora bilo što manje.

 

Ako suprotna strana prihvaća zahtjev za otvaranjem kanala ona šalje sljedeću poruku:

 

byte      SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32    broj kanala primatelja 
uint32    broj kanala pošiljatelja
uint32    inicijalna veličina prozora
uint32    maksimalna veličina paketa
....      podaci ovisni o vrsti kanala

 

Broj kanala primatelja je broj koji je dobiven u originalnom CHANNEL_OPEN zahtjevu, dok je broj kanala pošiljatelja, broj koji ova strana generira i predstavlja lokalni identifikator za ovaj kanal.

Ako primatelj CHANNEL_OPEN zahtjeva ne želi otvoriti novi kanal on to dojavljuje slanjem sljedeće poruke:

 

byte      SSH_MSG_CHANNEL_OPEN_FAILURE
uint32    broj kanala primatelja
uint32    identifikator razloga odbijanja
string    opis razloga, kodirano UTF-8 kodom
string    identifikator jezika

 

Razlozi odbijanja mogu biti različiti, a definirana su četiri standarda identifikatora:

SSH_OPEN_ADMINISTRATIVELY_PROHIBITED
SSH_OPEN_CONNECT_FAILED
SSH_OPEN_UNKNOWN_CHANNEL_TYPE
SSH_OPEN_RESOURCE_SHORTAGE

 

3.4.2      Prijenos podataka

 

U ovom poglavlju definirane su poruke kojima se ostvaruje prijenos podataka kroz kanal. Već je rečeno da se kontrola toka podataka (flow control) vrši algoritmom klizećih prozora. Poruka kojom primatelj vrši povećavanje veličine prijemnog prozora izgleda ovako:

 

byte      SSH_MSG_CHANNEL_WINDOW_ADJUST
uint32    broj kanala primatelja
uint32    broj bajtova 

 

Nakon primitka ovakve poruke primatelj može poslati broj bajtova više podataka nego što je to mogao prije.

Podaci se prenose sljedećom porukom:

 

byte      SSH_MSG_CHANNEL_DATA
uint32    broj kanala primatelja
string    podaci

 

Najveća količina podataka koju jedna strana može poslati jednaka je veličini prijemnog prozora primatelja ili maksimalnoj veličina paketa za tog primatelja, što god je manje. Nakon slanja podataka, pošiljatelj umanjuje veličinu prozora za broj podataka koji je poslao.

Također je moguće slanje posebnog tipa podataka, kao na primjer slanje stderr izlaza iz interaktivnih sjednica. Slanje se vrši sljedećom porukom:

 

byte      SSH_MSG_CHANNEL_EXTENDED_DATA
uint32    broj kanala primatelja
uint32    tip podataka
string    podaci

 

Podaci poslani ovim putem također smanjuju veličinu prozora.

 

3.4.3      Zatvaranje kanala

 

Kada neka strana više ne želi slati podatke, ona to javlja slanjem poruke:

 

byte      SSH_MSG_CHANNEL_EOF
uint32    broj kanal primatelja

 

Nakon te poruke kanal ostaje i dalje otvoren i moguće je slanje podataka u drugom smjeru.

Kanal se u potpunosti zatvara slanjem poruke:

 

byte      SSH_MSG_CHANNEL_CLOSE
uint32    broj kanala primatelja

 

Nakon primanja ovog paketa, suprotna strana mora također poslati CHANNEL_CLOSE paket. Tek kada su obje strane poslale te pakete, kanal se smatra zatvorenim.

 

3.4.4      Interaktivne sjednice

 

Sjednica (session) je udaljeno izvršavanje programa. Taj program može biti ljuska operacijskog sustava (shell), aplikacija, neka sistemska naredba ili čak i neki ugrađeni podsustav (npr. scp, sftp).

Sjednica se pokreće slanjem poruke:

 

byte      SSH_MSG_CHANNEL_OPEN
string    "session"
uint32    broj kanala pošiljatelja
uint32    inicijalna veličina prozora
uint32    maksimalna veličina paketa

 

Ovakve zahtjeve bi trebali slati samo klijenti i ako je poslužitelj u kojem slučaju pošalje, klijent ih treba odbiti.

Kada klijent želi uz svoju već otvorenu sjednicu vezati pseudo-terminal (pty) on šalje poruku:

 

byte      SSH_MSG_CHANNEL_REQUEST
uint32    broj kanala primatelja
string    "pty-req"
boolean   želim odgovor
string    TERM varijabla okoline (npr. xterm)
uint32    širina u znakovima (npr. 80)
uint32    visina u znakovima (npr. 24)
uint32    širina u pikselima (npr. 640)
uint32    visina u pikselima (npr. 480)
string    op tty kodovi koje terminal razumije

 

Ako je vrijednost varijable želim odgovor istina, tada poslužitelj odgovara. Ako je stvaranje uspjelo on šalje:

 

byte      SSH_MSG_CHANNEL_SUCCESS
uint32    broj kanala primatelja

 

Ako stvaranje pseudo-terminala nije uspjelo poslužitelj šalje:

 

byte      SSH_MSG_CHANNEL_FAILURE
uint32    broj kanala primatelja

 

Kada klijent želi započeti preusmjeravanje X11 prometa sa poslužitelja, on to zatraži slanjem poruke:

 

byte      SSH_MSG_CHANNEL_REQUEST
uint32    broj kanala primatelja
string    "x11-req"
boolean   želim odgovor
boolean   samo jedna veza
string    x11 autentifikacijski protokol
string    x11 autentifikacijski cookie
uint32    x11 broj ekrana

 

Varijable okoline se prosljeđuju porukom:

 

byte      SSH_MSG_CHANNEL_REQUEST
uint32    broj kanala primatelja
string    "env"
boolean   želim odgovor
string    ime varijable
string    vrijednost varijable

 

 

Nakon što je uspostavljena sjednica, i svi njeni parametri postavljeni klijent će najčešće zatražiti pokretanje nekog programa. Taj program može biti neka aplikacija, ili ljuska operativnog sustava (shell) ili neki podsustav (scp, sftp). Dozvoljeno je pokretanje samo jednog ovakvog programa po sjednici, što znači da će nakon što program završi morati završiti i sjednica.

Pokretanje ljuske operacijskog sustava vrši se porukom:

 

byte      SSH_MSG_CHANNEL_REQUEST
uint32    broj kanala primatelja
string    "shell"
boolean   želim odgovor

 

Ovaj zahtjev rezultirat će pokretanjem korisnikove podrazumijevane ljuske (na UNIX sustavim ona je definirana u datoteci /etc/passwd). Ako je korisnik označio da želi odgovor, poslužitelj će odgovoriti slanjem CHANNEL_SUCCESS ili CHANNEL_FAILURE  ovisno da li je pokretanje ljuske uspjelo.

Ako korisnik ne želi pokretati ljusku operativnog sustava nego samo izvršiti jednu naredbu on šalje poruku:

 

byte      SSH_MSG_CHANNEL_REQUEST
uint32    broj kanala primatelja
string    "exec"
boolean   želim odgovor
string    naredba

 

Ugrađeni podsustavi (scp, sftp) se pokreću se slanjem poruke:

 

byte      SSH_MSG_CHANNEL_REQUEST
uint32    broj kanala primatelja
string    "subsystem"
boolean   želim odgovor
string    ime podsustava

 

Da bi pokretanje uspjelo, podsustav mora biti definiran i mora biti dostupan na poslužitelju.

 

Kada naredba ili program koju je klijent pokrenuo na drugoj strani završi ona vraća izlazni status. Taj broj može koristiti klijentu jer on može utvrditi da li je izvršavanje naredbe uspjelo ili je došlo do greške. Poslužitelj može poslati izlazni status sljedećom porukom:

 

byte      SSH_MSG_CHANNEL_REQUEST
uint32    broj kanala primatelja
string    "exit-status"
boolean   NE
uint32    izlazni status

 

3.4.5      Prosljeđivanje TCP/IP prometa

 

Ako jedna strana u komunikaciji želi da sav promet sa suprotne strane bude preusmjeren njoj može to postići metodom prosljeđivanja mrežnih pristupa (port forwarding).

Da bi se to postiglo šalje se poruka:

 

byte      SSH_MSG_GLOBAL_REQUEST
string    "tcpip-forward"
boolean   želim odgovor
string    adresa koju vežemo
uint32    broj pristupa koji vežemo

 

Nakon što je ova poruka poslana, svaki put kada pristigne konekcija na adresu i pristup (navedene u poruci), otvara se kanal koji će se koristiti za prijenos preusmjerenog prometa.

Ako je adresa na kojoj se klijent vezao na poslužitelju onda poslužitelj, nakon što mu pristigne zahtjev na toj adresi, otvara novi kanal slanjem poruke:

 

byte      SSH_MSG_CHANNEL_OPEN
string    "forwarded-tcpip"
uint32    broj kanala pošiljatelja
uint32    inicijalna veličina prozora
uint32    maksimalna veličina paketa
string    mrežna adresa koja je spojena
uint32    mrežni pristup koji je spojen
string    mrežna adresa originalnog zahtjeva
uint32    mrežni pristup originalnog zahtjeva

 

Ako je adresa koja je vezana za preusmjeravanje prometa na računalu klijentu, i ako na definiranu adresu i definiran pristup pristigne neki zahtjev, klijent će otvoriti novi kanal slanjem poruke:

 

byte      SSH_MSG_CHANNEL_OPEN
string    "direct-tcpip"
uint32    broj kanala pošiljatelja
uint32    inicijalna veličina prozora
uint32    maksimalna veličina paketa
string    adresa na koju se spaja
uint32    pristup na koji se spaja
string    adresa originalnog zahtjeva
uint32    pristup originalnog zahtjeva

 

Nakon toga sav mrežni promet preusmjerava se kroz SSH kanal.



4         Praktični rad

Praktični dio zadatka bila je izrada računalnog programa koji će simulirati rad SSH protokola. Ideja je bila da simulator omogućava uvid u sve važne podatke u svakom koraku simulacije, da omogućava dinamičko mijenjanje istih kako bi se ispitalo ponašanje i sigurnost protokola. Treba reći da zbog jednostavnosti i preglednosti program ne simulira apsolutno sve funkcije protokola, nego se bazira na najvažnije dijelove tj. jezgru protokola. Tako funkcije kao što su kompresija, prosljeđivanje portova (port forwarding) i interaktivne sjednice (interactivne login session) nisu implementirane.

 

4.1      Programska implementacija

 

Računalni program koji je izrađen zove se SSH Simulator. Program je implementiran u programskom jeziku Java. Za izradu je iskorištena biblioteka klasa Ganymed SSH-2 for Java (http://www.ganymed.ethz.ch/ssh2) koja pruža niz korisnih klasa. Tu su klase za kriptiranje algoritmima AES, Blowfish i 3DES, zatim klase za računanje sažetka algoritmima MD5 i SHA1, klase za dekodiranje datoteka s ključevima itd. Za izradu je korištena Eclipse razvojna okolina.

Slika 4 : Funkcioniranje programa SSH Simulator

 

Jezgru programa SSH Simulator čine klase koje su prikazane na slici 4. Glavna klasa je klasa imena SSHSimulator. Ona je zadužena za iscrtavanje korisničkog sučelja i komunikaciju s korisnikom. Sve podatke koje korisnik unese ova klasa prosljeđuje klasama Klijent i Server. Također, ova klasa upravlja tijekom simulacije. Nakon što korisnik stisne gumb za sljedeći korak simulacije ova klasa zove određene metode u klasama Klijent i Server. Klasa Klijent predstavlja klijentsku stranu u SSH komunikaciji i implementira sve potrebne strukture podataka i metode potrebe da bi klijent mogao uspješno sudjelovati u komunikaciji. Klasa Server implementira serversku stranu u komunikaciji i implementira sve strukture podataka i metode potrebne da bi server mogao uspješno sudjelovati u komunikaciji.

Na početku, nakon što korisnik stisne gumb za pokretanje simulacije, SSHSimulator objekt instancira objekte klijenta i servera i međusobno ih spaja sa dva para PipedInputStream/PipedOutputStream objekata. Ti objekti simuliraju mrežnu vezu koja u stvarnim implementacijama postoji između klijenta i servera. Sva komunikacija između njih ide kroz te objekte.

 

4.2      Korištenje programa

 

Slijedi opis korištenja programa.

 

Slika 5 : Područje za ispis paketa i gumbi za kontrolu simulacije

Prozor programa podijeljen je vertikalno na dva dijela. Lijevi dio predstavlja klijenta, a desni dio predstavlja server. Kao što se vidi na slici 5 u donjem dijelu prozora nalaze se dva gumba za kontrolu simulacije. Prvi gumb započinje simulaciju i poslije se koristi za prelazak na sljedeći korak simulacije. Do njega je gumb "Reset" koji se koristi za poništavanje tijeka simulacije i vraćanje na početak. Odmah pored nalazi se polje u kojem za svaki korak simulacije piše objašnjenje što se trenutno događa. Iznad tih polja nalaze se četiri tekstualna prozora, dva na klijentskoj strani te dva na serverskoj. U tim prozorima ispisuje se sav promet koji određena strana u komunikaciji dobiva. U gornjem prozoru ispisuje se sirovi (kriptirani) promet, dok se u donjem ispisuje dekriptirani promet (također se uklanja zaglavlje i dopuna).

 

Na početku simulacije korisnik može odabrati inicijalizacijske nizove koji se šalju. Također, moguće je odabrati algoritme koji se koriste u postupku pregovaranja. Taj dio sučelja prikazan je na slici 6. Na klijentskom dijelu prozora moguće je odabrati redoslijed algoritama. Redoslijed se mijenja gumbima "Gore" i "Dolje", a moguće je odabirati algoritme za razmjenu ključeva, za digitalni potpis, za enkripciju i MAC. Pozicija na listi određuje koliko je algoritam poželjan, tako da su algoritmi na vrhu najpoželjniji. Ovo će

Slika 6 : Sučelje za pregovaranje algoritama

imati utjecaja na postupak pregovaranja algoritama jer će onim redoslijedom koji korisnik odabere algoritmi biti poslani u KEXINIT paketu. Na serverskoj strani je moguće odabirati koje će algoritme server prijaviti u pregovaranju a koje neće. Ovdje redoslijed nije bitan jer se odabrani algoritmi biraju po prioritetu koji pošalje klijent. Neke algoritme nije moguće izbaciti. To su algoritmi koji su prema SSH standardu obavezni i sve strane ih moraju podržavati kako bi rad protokola bio moguć.

 

Slika 7 : Dijalog sa odabranim algoritmima

Na kraju postupka, nakon što i klijent i server pošalju svoje liste sa željenim algoritmima, oni se odabiru i korisniku se prikazuju u dijalogu kakav se može vidjeti na slici 7.

 

Sljedeći korak je Diffie-Hellman razmjena ključeva. Sučelje prikazuje sve parametar iz te razmjene (modulus p, generator g, parametri e i f, tajni ključ K) i moguće je u svakom trenutku mijenjati te parametre. Izgled sučelja prikazan je na slici 8.

U ovom dijelu simulacije također se vrši autentifikacija servera. Korisniku je omogućeno da sa datotečnog sustava odabere datoteke u kojima se nalaze DSS i RSA privatni ključevi servera. Javni ključevi i digitalni potpisi se također prikazuju korisniku i on ih može u svakom trenutku promijeniti.

 

Slika 8 : Sučelje za Diffie-Hellman razmjenu i autentificiranje servera

 

Slika 9 : Dijalog sa fingerprint nizom

 

Kao dio autentifikacije servera potrebno je utvrditi ispravnost njegovog javnog ključa. To se radi tako da se korisniku ispiše MD5 sažetak ključa (fingerprint) i pita ga se da li prihvaća taj ključ kao valjan, što je prikazano na slici 9.

 

Nakon Diffie-Hellman razmjene slijedi generiranje ključeva. Sučelje je prikazano na slici 10. Tu se odmah na početku nalaze parametri K i G koji su rezultat iz prošlog koraka, a koriste se za generiranje svih potrebnih ključeva. Njihove vrijednosti se mogu promijeniti u svakom trenutku. Iz te dvije vrijednosti generiraju se dva inicijalizacijska vektora i dva ključa enkripcija (po jedan za svaki smjer komuniciranja). Također se generiraju i dva MAC ključa. Vrijednosti na klijentskoj i serverovoj strani bi trebale biti jednake ako je sve bilo kako treba. Sve ove parametre moguće je mijenjati u svakom trenutku.

Slika 10 : Sučelje za generiranje ključeva

Sljedeći korak u postupku je autentificiranje korisnika. Korisniku je iz padajućeg izbornika ponuđeno biranje između dvije implementirane metode: "publickey" i "password". Ako korisnik odabere "password" metodu, on može upisati korisničko ime i lozinku u za to predviđena polja. Na serverskoj strani moguće je odabrati koje metode su dopuštene ("publickey" je prema standardu obavezna). Moguće je odabrati datoteku u kojoj se nalaze korisnička imena i lozinke. Format datoteke je jednostavan, u svakom redu nalazi se jedno korisničko ime, zatim ide razmak, i na kraju pripadajuća lozinka. Sve linije koje započinju znakom "#" se smatraju komentarima. Ako je odabrana "publickey" metoda na klijentskoj strani tada je korisniku moguće odabiranje datoteke sa privatnim ključem korisnika. Moguće je odabrati DSS ili RSA ključ. Inače datoteke su u PEM formatu, tj. iste su kao datoteke koje generira OpenSSH. Ključevi nisu kriptirani. Na serverskoj strani moguće je odabrati datoteku u kojoj se nalaze autorizirani javni ključevi, tj. oni kojima je dopušteno spajanje (isto kao datoteka authorized_keys na OpenSSH implementacijama). Poslani ključevi i potpisi se prikazuju korisniku i moguće ih je mijenjati.

 

Slika 11 : Sučelje za autentifikaciju

Zadnji korak je sučelje u kojem se može kontrolirati tijek spojnog protokola (slika 12). Ovdje nije implementirana najčešće korištena usluga spojnog protokola, a to je interaktivna sjednica (interactive login session) niti slabije korištena usluga kao što je prosljeđivanje mrežnih pristupa (port forwarding). Implementirano je obično udaljeno izvršavanje naredbe. Korisnik može podešavati identifikatore otvorenog kanala i na klijentu i na serveru. Također može podešavati veličinu prijemnog prozora na klijentu. Može se podesiti i naredba koja će se izvršiti na serveru (podrazumijevana naredba je dir ili ls ovisno na kojem operacijskom sustavu je program pokrenut). Naredba se izvrši i nakon toga server pošalje standardni izlaz naredbe klijentu koji to onda ispisuje na svojoj strani. Interaktivna sjednica nije implementirana zbog toga što bi implementacija bila jako komplicirana, a izmjena poruka koje se koriste (što je najbitnije za protokol) je skoro pa ista kao i kod udaljenog izvršavanja naredbe.

 

Slika 12 : Udaljeno izvršavanje naredbe


5         Zaključak

Nakon proučavanja SSH protokola mogu reći da to je to jedan od protokola koji će u budućnosti sve više dobivati na popularnosti, sve dok se ne pojavi neko globalno rješenje koje će učini Internet promet sigurnijim (npr. IPsec). Njegovi najveći aduti su njegov modularan dizajn, koji dopušta dodavanje novih algoritama i podsustava, kad se pokaže da su stari nesigurni ili ne pružaju dovoljnu funkcionalnost. Drugi adut je njegova jednostavnost, jer je to protokol lake kategorije koji praktički ne zahtijeva nikakvu infrastrukturu i njegove programske implementacije su velike nekoliko stotina kilobajta, i mogu biti prikladne za male mobilne uređaje. Njegova primjena će vjerojatno rasti u tom smjeru da će se SSH koristiti kao siguran prijenosni kanal za druge protokola (kao što je to npr. sftp), i mislim da će se u budućnosti pojaviti više alata koji će koristiti tu funkcionalnost.

Najveće mane su nedostatak PKI infrastrukture koja bi omogućavala provjeravanje vlasništva nad javnim ključevima, pa je SSH u današnjim implementacijama ranjiv na aktivne čovjek-u-sredini napade (man-in-the-middle). Drugi ozbiljniji napadi na SSH protokol nisu pronađeni, a manje ranjivosti pokazane u [13], [14] i [16], su u praksi jako teško ostvarive.

Praktični dio seminara tj. izrada simulatora SSH protokola mi je omogućilo puno bolje s upoznavanje sa samim protokolom, i mislim da je program dosta zgodan za vizualizaciju rada protokola i korištenje u edukativne svrhe. Znatiželjnici koji svakodnevno koriste taj protokol, a zapravo ne znaju kako on funkcionira, mogu vidjeti kako izgleda rad tog protokola korak po korak. 

 


6         Literatura

 

 

[1]          Ylönen, T., C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, 2006.

[2]          Ylönen, T., C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, 2006.

[3]          Ylönen, T., C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, 2006.

[4]          Ylönen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, 2006.

[5]          Lehtinen, S., C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, 2006.

[6]          Cusack, F., Forssen M., "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", RFC 4256, 2006.

[7]          Friedl M., Provos N., Simpson W. "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC4419, 2006.

[8]          Postel, J., J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, 1983.

[9]          Kantor, B., "BSD Rlogin", RFC 1282, 1991.

[10]      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC2104, 1997.

[11]      US National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-2, 2000.

[12]      Schneier, B., "Applied Cryptography Second Edition:  protocols algorithms and source in code in C", John Wiley and Sons, New York, 1996.

[13]      Dai, W., "An attack against SSH2 protocol", Email to the SECSH Working Group ftp://ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail, 2002.

[14]      Bellare, M., Kohno, T., C. Namprempre, "Authenticated Encryption in SSH: Fixing the SSH Binary Packet Protocol", Proceedings of the 9th ACM Conference on Computer and Communications Security, 2002.

[15]      Bellare, M., Kohno T., Namprempre C. "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC4344, 2006.

[16]      Song, X.D., Wagner, D., and X. Tian, "Timing Analysis of Keystrokes and SSH Timing Attacks" , Paper given at 10th USENIX Security Symposium, 2001.

[17]      Solar Designer and D. Song, "SSH Traffic Analysis Attacks", Presentation given at HAL2001 and NordU2002 Conferences,  2001.

 


7         Dodaci

Dodatak A – Identifikatori poruka

 

Protokolom su definirane sljedeće poruke, a njihovi identifikatori su predstavljeni kao cijeli brojevi veličine 8 bitova i dani su u sljedećoj tablici.

 

Identifikator poruke

Vrijednost

Sloj u kojem se koristi

SSH_MSG_DISCONNECT

1

Prijenosni

SSH_MSG_IGNORE

2

Prijenosni

SSH_MSG_UNIMPLEMENTED

3

Prijenosni

SSH_MSG_DEBUG

4

Prijenosni

SSH_MSG_SERVICE_REQUEST

5

Prijnosni

SSH_MSG_SERVICE_ACCEPT

6

Prijenosni

SSH_MSG_KEXINIT

20

Prijenosni

SSH_MSG_NEWKEYS

21

Prijenosni

SSH_MSG_USERAUTH_REQUEST

50

Autentifikacijski

SSH_MSG_USERAUTH_FAILURE

51

Autentifikacijski

SSH_MSG_USERAUTH_SUCCESS

52

Autentifikacijski

SSH_MSG_USERAUTH_BANNER

53

Autentifikacijski

SSH_MSG_GLOBAL_REQUEST

80

Spojni

SSH_MSG_REQUEST_SUCCESS

81

Spojni

SSH_MSG_REQUEST_FAILURE

82

Spojni

SSH_MSG_CHANNEL_OPEN

90

Spojni

SSH_MSG_CHANNEL_OPEN_CONFIRMATION

91

Spojni

SSH_MSG_CHANNEL_OPEN_FAILURE

92

Spojni

SSH_MSG_CHANNEL_WINDOW_ADJUST

93

Spojni

SSH_MSG_CHANNEL_DATA

94

Spojni

SSH_MSG_CHANNEL_EXTENDED_DATA

95

Spojni

SSH_MSG_CHANNEL_EOF

96

Spojni

SSH_MSG_CHANNEL_CLOSE

97

Spojni

SSH_MSG_CHANNEL_REQUEST

98

Spojni

SSH_MSG_CHANNEL_SUCCESS

99

Spojni

SSH_MSG_CHANNEL_FAILURE

100

Spojni