SVEUILITE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAUNARSTVA

DIPLOMSKI RAD br. 1697

ANALIZA I SIMULACIJA SSH PROTOKOLA

Tihomir Mei

Zagreb, 2007.

Sadraj :

1 Uvod ....................................................................................................... 1 2 Povijest, razvoj i slini 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 kljueva ...................................................... 15 3.2.8 Algoritmi javnog kljua ............................................................ 16 3.2.9 Pregovaranje algoritama......................................................... 17 3.2.10 Razmjena kljueva.................................................................. 19

3.3 Autentifikacijski protokol ......................................................... 23 3.3.1 Zahtjevi za autentifikacijom..................................................... 23 3.3.2 Autentifikacija pomou javnog kljua ("publickey") ................. 24 3.3.3 Autentifikacija pomou 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 Prosljeivanje TCP/IP prometa............................................... 34

4 Praktini rad ........................................................................................ 36 4.1 Programska implementacija ................................................... 36 4.2 Koritenje programa ............................................................... 37

5 Zakljuak.............................................................................................. 42 6 Literatura ............................................................................................. 43 7 Dodaci .................................................................................................. 45

1

1 Uvod Secure Shell protokol (SSH) je mreni protokol za sigurno spajanje na udaljeno raunalo preko nesigurnog medija kao to je Internet. Bez obzira na njegovo ime, protokol prua puno veu funkcionalnost nego obini alati za udaljeno spajanje poput telnet-a ili rlogin-a. Ova dva prethodna protokola su sa sigurnosnog aspekta jako nesigurna, jer je sav promet izmeu klijenta i posluitelja nekriptiran, i tako su osjetljive informacije kao to su korisnike lozinke itljive svima koji mogu prislukivati mreni promet. Dizajn tih protokola je odraz vremena u kojem su oni nastajali. Tada su raunala bila relativno rijetka, obino su se nalazila u akademskim institucijama i umreavana su u male lokalne mree, tako da velika sigurnost i tajnost podataka i nije bila osobito potrebna. Meutim, porastom broja raunala i razvojem Interneta, rizici su postali puno vei. Sve se vie osjetljivih podataka poelo prenositi Internetom, i sve je vie raznih alata koji omoguavanju prislukivanje 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 moe funkcionirati i preko drugih prijenosnih protokola. On osigurava tajnost svih prenoenih podataka tako to kriptira sav promet izmeu klijenta i posluitelja. Takoer osigurava integritet prenoenih podataka raunanjem MAC (message authentication code) kodova za svaki paket. U postupku spajanja klijenta, SSH omoguava klijentu da autentificira posluitelj, tj. da utvrdi da je posluitelja ba onaj za kog se izdaje, i tako se osigura od mogueg ovjek-u-sredini (man-in-the-middle) napada gdje bi se potencijalni napada predstavljao kao posluitelj. Nadalje, SSH omoguava nekoliko mehanizama za autentifikaciju klijenta, od kojih su najee autentifikacija javnim kljuem i autentifikacija lozinkom. Za razliku od telnet protokola ovdje se lozinke prenose sigurnim kriptiranim kanalom, i tako onemoguuju prislukivanje (eavesdropping). Nakon uspostavljanja veze i meusobnog autentificiranja, spojni sloj SSH protokola omoguava razne usluge. Mogue je tradicionalno udaljeno koritenje ljuske operacijskog sustava (shell), ali je takoer mogue koristiti uspostavljenu vezu za prosljeivanje prometa nekih drugih protokola (port forwarding), ili je mogue pokrenuti neki podsustav (scp, sftp) koji e koristiti SSH kanal kao sigurni medij za prenoenje podataka. Protokol doputa i koritenje kompresije podataka za utedu mrenog prometa, ako to obje strane u komunikaciji zahtijevaju. Omogueno je i istovremeno koritenje vie kanala za prijenos, koji su zapravo samo logiki kanali, a sav promet se multipleksira u jedan kanal. Protokol ima modularan dizajn, tj. doputa implementacijama dodavanje novi usluga ili podsustava ve postojeim, jer se o svim uslugama vri pregovaranje. Takoer je mogue dodavanje novih kriptografskih algoritama ili metoda autentifikacije, ako se stare s vremenom pokau kao nesigurne. Ovaj rad e na poetku opisati povijest i razvoj ovog protokola, i protokole sline namjena koji su mu prethodili. Zatim, u drugom poglavlju e biti opisana kompletna

2

arhitektura ovog protokola kroz pregled prijenosnog, autentifikacijskog i spojnog sloja i njihovih funkcija. U etvrtom poglavlju bit e opisan praktini dio ovog rada, a to je izrada raunalnog programa koji simulira rad SSH protokola, prikazuje sve podatke koji su relevantni za simulaciju, i omoguava mijenjanje istih. Bit e opisani detalji programske implementacije, kao i upute za koritenje programa. Treba rei 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 znai SSH-2 protokol, osim ako nije drukije navedeno.

3

2 Povijest, razvoj i slini protokoli

U ovom poglavlju bit e opisani nastanak i razvoj SSH protokola, razliite verzije tog protokola, zatim e biti dan pregled protokola sline namjere koji su prethodili SSH protokolu.

2.1 Povijest i razvoj SSH protokola

SSH protokol je u svojoj inaici SSH-1 nastao 1995. godina a razvio ga je Finac Tatu Ylnen, koji tada bio istraiva na tehnolokom sveuilitu u Helsinkiju (University of Technology, Helsinki). Motivacija za izradu tog protokola bio je sluaj napada na raunalnu mreu njegovog sveuilita u kojem su napadai, doznavali lozinke korisnika prislukivanjem prometa na mrei. 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 doputeno 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 traili razne informacije o koritenju programa. Ylnen 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 inenjer zaduen za razvoj protokola. Prva verzija (SSH1) dokumentirana je 1995. godine i predloena kao IETF Internet Draft. Meutim, ta verzija je imala puno sigurnosnih problema, a sve ih se vie 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 zadaa standardizacija i razvoj protokola. Radna grupa podnosi prvi Internet Draft za SSH-2 protokol u veljai 1997. godine. Godine 1998. tvrtka SSH Communications izdaje program naziva "SSH Secure Shell" koji je baziran na SSH-2 verziji protokola. Meutim, zbog toga to je program bio komercijalan, tj. nije bio besplatan kao prva verzija, on ne biva dobro prihvaen i SSH-1 verzija protokola jo par godina ostaje popularnija i koritenija 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 znai da je potpuno besplatna i otvorenog izvornog koda. Open SSH implementacija je u poetku bila bazirana na posljednjoj besplatnoj inaici originalnog SSH programa (1.2.12). Popularnost joj je jako brzo rasla zbog svoje otvorenosti, dostupnosti za razne operacijske sustave i podrci za obje verzije SSH

4

protokola. Godine 2006. SSH-2 kao ve zreo protokol postaje predloeni 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. Suelja prema korisniku su skoro potpuno identina. Meutim, r-naredbe za razliku od svojih ssh dvojnika ne kriptiraju promet i imaju autentifikacijske mehanizme koje je lako prevariti. rsh naredba koristi se za izvravanje naredbe na udaljenom raunalu, rlogin naredba spaja se na udaljeni terminal dok rcp naredba slui za kopiranje datoteka sa udaljenog posluitelja ili kopiranje datoteka na udaljeni posluitelj. Zajednika stvar im je nain autentifikacije korisnika. Nakon spajanja klijenta na udaljeni posluitelj, posluitelj iz poslane mrene adrese klijenta nalazi ime raunala pomou servisa kao to su NIS (network information service) ili DNS (domain name system). Nakon toga server provjerava lokalne konfiguracijske datoteke, najee su to /etc/hosts.equiv i $HOME/.rhosts. U tim datotekama se nalaze imena raunala i imena korisnika kojima je doputeno spajanje na to raunalo. Ako je ime raunala i korisnika pronaeno u jednoj od tih datoteka, korisniku je doputeno spajanje sa svim ovlastima koje inae ima na tom raunalu. Ovaj sustav autentifikacije je jako nesiguran, s obzirom servisi kao DNS imaju sigurnosne rupe koje bi omoguile da raunalo potencijalnog napadaa nakon kompromitiranja DNS servera, posluitelju izgleda kao raunalo kojem moe vjerovati. Napada bi tada dobio potpuni pristup tom raunalu bez da zna korisniku lozinku. Ako su r-naredbe konfigurirane da trae lozinku, ona se prenosi kao isti tekst. r-naredbe se mogu koristiti u malim mreama gdje se moe vjerovati svim raunalima. Meutim, koritenje u nesigurnim mreama kao to je Internet bi predstavljalo prevelik rizik tako da ove naredbe polako odlaze u prolost. Dodatni nedostatak im je i taj to se mogu koristiti samo na UNIX raunalima.

2.3 TELNET

TELNET (TELecommunication NETwork) je do pojave SSH protokola, bio daleko najkoriteniji 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. Obino se koristi iznad TCP/IP konekcije, iako je sam TELNET protokol stariji od samog TCP/IP protokolnog stoga. Tipian mreni pristup (port) na kojem TELNET posluitelj oslukuje zahtjeve je 23.

5

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 koritenje TELNET protokola nikako ne preporuuje. To je stoga to se svi podaci (ukljuujui i lozinke) prenose u istom, nekriptiranom obliku. Tako je mogue da svatko tko ima pristup mrenom usmjerniku na mrei izmeu dva raunala koja komuniciraju TELNET-om i ima pokrenut nekakav alat kao to je tcpdump, moe proitati korisnike lozinke. Drugi razlog zato se TELNET treba izbjegavati je stoga to on nema mehanizme za autentificiranje posluitelja, tako da su mogui man-in-the-middle napadi, u kojima bi se potencijalni napada predstavljao kao TELNET server i doao do tajnih podataka klijenta.

6

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 znaajke i njihova povezanost te najvaniji algoritmi koji su potrebni za funkcioniranje protokola.

3.1 Pregled arhitekture

Kao to je ve reeno SSH protokol je protokol za sigurno udaljeno logiranje i druge mrene usluge preko nesigurne mree kao to je Internet koji koristi klijent-posluitelj model . Protokol je definiran u nizu RFC dokumenta ([1] do [4]) i trenutno ima status predloenog Internet standarda. Sastoji se od tri glavne komponente/sloja:

Prijenosni protokol (The Transport Layer Protocol) koji prua autentifikaciju posluitelja, tajnost prijenosa, i integritet prenoenih podataka. Takoer, opcionalno prua i uslugu kompresije podataka. Obino radi kao aplikacijski protokol iznad TCP/IP protokolnog stoga, ali nije ovisan o njemu, ve moe raditi na iznad svakog protokola koji prua pouzdan prijenos podataka

Autentifikacijski protokol (The User Authentication Protocol) koji je zaduen za autentifikaciju korisnika posluitelju na koji se on pokuava spojiti. Za njegov rad je potrebno da prijenosni sloj protokola ve bude u funkciji.

Spojni protokol (The Connection Protocol) je zaduen za multipleksiranje vie logikih kanala u jedan kriptirani tunel. Takoer upravlja zahtjevima korisnika za uslugama kao to su to zahtjev za pokretanjem pseudoterminala (pty) i ljuske operacijskog sustava (shell) ili izvravanje naredbe na posluitelju ili pokretanje podsustava (scp, sftp) ili pak prosljeivanje mrenih pristupa (port forwarding). Radi iznad prijenosnog i autentifikacijskog sloja.

Nakon uspostave sigurnog prijenosnog kanala klijent obino poalje zahtjev za pokretanjem autentifikacijskog servisa (ssh-userauth). Takoer, nakon uspjene autentifikacije klijent e poslati zahtjev za pokretanjem spojnog protokola (ssh-connection). To omoguava da novi protokoli budu definirani i da koegzistiraju sa postojeim protokolima.

7

Slika 1 : Arhitektura SSH protokola

3.1.1 Podatkovne strukture SSH protokola

Slijedi pregled podatkovnih tipova koji se koristi u SSH protokolu i njihova objanjenja:

byte - ovaj podatak predstavlja proizvoljni niz duine osam bitova (oktet). Neke podatkovne strukture predstavljaju se kao polje bajtova, to se pie byte[n], gdje je n broj lanova u tom polju.

boolean ovaj podatkovni tip predstavlja logiku varijablu koja se pohranjuje kao jedan bajt. Vrijednost 0 predstavlja logiko NE, dok vrijednost 1 predstavlja logiko DA. Sve vrijednosti koje nisu nula se takoer tumae kao logiko DA, ali implementacijama protokola nije preporueno pohranjivati boolean vrijednosti razliite 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 najznaajniji, a zadnji bajt najmanje znaajan (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 doputeno je pojavljivanje svih moguih znakova pa tako i null znaka, i znakova iji je najznaajniji bit jednak 1. Zapisuje se tako da se prvo zapie duljina niza (broj bajtova koji slijede) kao uint32 podatak, pa zatim 0 ili vie znakova koji predstavljaju taj string. Zavrni null znak se ovdje ne koristi (kao na primjer u C stringovima), jer je kraj niza odreen njegovom

8

duljinom. Stringovi se takoer koriste za zapisivanje tekstualnih podataka. U tom sluaju, 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, zavrni 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 viestruke preciznosti (multiple precision integer) u dvojnom komplementu, zapisan kao string (znai prvo ide uint32 podatak u kojem je zapisan broj bajtova koji slijede), tako da najvaniji bajt ide na poetku zapisa broja. Negativne vrijednosti imaju postavljen bit 1 kao najznaajniji bit prvog bajta koji predstavlja broj. Ako se, meutim, radi o pozitivnom broju koji bi imao bit 1 kao najznaajniji bit, tada se na poetak 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 sadraj lista imena odvojenih zarezom. To znai da prvo ide uint32 podatak u kojem je zapisana ukupna duljina liste (broj bajtova koji slijedi), a zatim ide lista od 0 ili vie imena koja su odvojena zarezom. Ime u listi mora biti dugako minimalno jedan bajt i ne smije u sebi sadrati 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 ogranienje da navedena imena moraju biti ispravna imena algoritama (npr. za simetrine algoritme "aes-128-cbc", "blowfish-cbc" itd.). Zavrni null znak se ne koristi, niti za pojedinana 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 poetku imaju identifikacijski broj koji predstavlja vrstu poruke. Na temelju tog broja primatelj poruke zna koji su podaci sadrani 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 nai u dodatku A.

9

3.2 Prijenosni protokol

Prijenosni sloj SSH protokola je najnii sloj od kojeg zavise ostala dva sloja. Najee se protokol vrti iznad TCP/IP protokola, ali mogue je rad i iznad drugih protokola. On prua jaku enkripciju, autentifikaciju posluitelja, i uva integritet prenesenih podataka. Autentifikacija korisnika se ne vri u ovoj fazi, nego samo autentifikacija posluitelja. Ovaj protokol je dizajniran da bude jednostavan i fleksibilan, i da omogui pregovaranje o algoritmima i parametrima konekcije, i minimizira broj poruka kod pregovaranja. Algoritmi o kojima se pregovara su metode razmjene kljueva, algoritmi simetrine enkripcije, algoritam javnog kljua za autentifikaciju posluitelja, algoritmi za raunanje saetka poruke (hash) i MAC algoritmi (message authentication code). Protokol predvia da potpunu razmjena kljueva i autentifikacija servera zavri nakon dvije razmjene poruka. U najgorem sluaj sve e biti gotovo u 3 razmjene.

3.2.1 Uspostavljanje veze

Posluitelj oslukuje konekcije na TCP/IP pristupu broj 22 (to je slubeni broj pristupa registriran od strane IANA-e), ali to moe biti i bilo koji drugi pristup. Vezu inicira klijent. Nakon to je veza uspostavljena obje strane alju identifikacijske nizove. Nizovi imaju sljedei format:

SSH-verzijaprotokola-verzijaprograma razmak komentari CR LF

Na poetku 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 ii komentari, ali oni su opcionalni. Ako su komentari prisutni, tada nakon niza koji oznaava verziju programa mora doi 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 duina ovog niza je 255 znakova (ukljuujui i CR i LF znakove). Ako bilo koja strana primi identifikacijski niz koji ne poinje 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 kljueva. Odmah nakon to su poslani identifikacijski nizovi sa obje strane poinje proces razmjene kljueva. 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 moe vidjeti kako izgleda inicijalno uspostavljanje veze u praksi. Na

10

klijentskoj strani je program Putty, dok je na posluiteljskoj 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 moe vidjeti, ni klijent ni posluitelj nemaju opcionalni komentar nego iza verzije programa odmah slijede CR i LF znakovi. Klijent je prijavio da koristi verziju protokola "2.0", dok je posluitelj prijavio verziju "1.99".

3.2.2 Kompatibilnost sa starim verzijama

Kao to je napomenuto u prolom dijelu, u postupku uspostavljanja veze bi sve implementacije trebale poslati da koriste verziju protokola "2.0" (tj. identifikacijski niz mora poeti sa "SSH-2.0-"). Za stare verzije protokola ovaj niz je poinjao 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 omoguiti kompatibilnost i sa tim programima.

Ako imamo sluaj da klijent koristi stari protokol (SSH-1), a posluitelj koristi novi (SSH-2), tada bi posluitelj trebao prijaviti svoju verziju protokola kao 1.99 (tj. identifikacijski niz poinje sa "SSH-1.99", kao u primjeru gore). U tom sluaju novi klijenti trebaju prepoznati ovo kao ekvivalent protokola 2.0 i poeti razmjenu kljueva prema SSH-2 verziji protokola. Stare verzije klijenta niz "1.99" protumae kao verziju SSH-1 protokol i poinju razmjenu koristei stariji protokol. Naravno, posluitelj treba prijaviti verziju kao 1.99 samo ako podrava i staru verziju protokola i ako je konfiguriran tako da prihvaa i SSH-1 konekcije.

Ako imamo sluaj da klijent koristi novi protokol, a posluitelj koristi stari protokol, tada je mogue da e klijent odmah nakon slanja svog identifikacijskog niza (a prije primanja posluiteljevog) poslati i podatke za razmjenu kljueva. S obzirom da je posluitelj koristi stariju verziju protokola on nee razumjeti podatke i prekinut e konekciju. Rjeenje je to, da ako je klijent primio posluiteljev 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.

11

3.2.3 SSH binarni paketni protokol

Nakon slanja identifikacijskih nizova, poinje 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 : Znaenje pojedinih polja u SSH binarnom paketu Naziv polja Tip podataka Opis

duljina paketa uint32 Oznaava duljinu paketa u bajtovima, bez MAC polja, i bez sebe samog

duljina dopune byte Oznaava duljinu nasumine 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] Nasumina dopuna, takva da je ukupna duljina spojenih polja (duljina_paketa || duljina_dopune || koristan_teret || dopuna) viekratnik broja 8 ili duljine bloka enkripcije, to god je vee. Obavezno mora biti barem 4 bajta dopune. Dopuna bi trebala biti nasumina ali to nije obavezno. Maksimalna veliina 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 poinje sa etiri bajta koja predstavljaju ukupnu duljinu paketa nakon tog polja, bez MAC polja koje je opcionalno. Slijedi jedan bajt u kojem je zapisana veliina dopune sa kraja

12

paketa. Minimalna veliina dopune je 4 bajta, a maksimalna je 255 bajtova. Dopuna bi trebala biti nasumina, to oteava napade na algoritam kriptiranja koji se koristi. Veliina dopune se odabire tako da bi duljina ukupnog paketa bez MAC polja bila viekratnik broja 8 ili duljine bloka algoritma enkripcije, to god je vee. 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 znai da e kod pogrene dekripcije i ovo polje biti pogreno, te se nee moi 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 izraunati koristei kompresirane podatke. Enkripcija e takoer biti izvrena nakon kompresije. Kompresija je nezavisna za svaki smjer, tj. moemo koristiti jedan algoritam za smjeru klijent-posluitelj, a drugi algoritam za kompresiju u smjeru posluitelj-klijent. Meutim, preporueno 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 oznaava da nema kompresije, i prema SSH protokolu ta je metoda obavezna u svim SSH implementacijama. Druga metoda, oznaena 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 kljueva. Nakon to je zavrena razmjena kljueva, svaki paket se kriptira, tj. sva polja osim MAC polja. Enkripcija se vri nezavisno u oba smjera, tj. postoji poseban klju i inicijalizacijski vektor za smjer enkripcije klijent-posluitelj, dok se za smjer posluitelj-klijent koristi drugi klju i inicijalizacijski vektor. Osim toga mogue je ak da se koristi jedan algoritam enkripcije za

13

jedna smjer, a drugi algoritam za drugi smjer, meutim to nije preporuljivo. Duljina kljueva enkripcije bi trebala biti minimalno 128 bitova. Algoritmi koji su predvieni za koritenje u originalnom protokolu dani su u sljedeoj tablici:

Tablica 3 : Definirani algoritmi enkripcije Ime algoritma Zahtjev Opis algoritma

3des-cbc obavezno enkripcija-dekripcija-enkripcija DES algoritmom, sa tri kljua, u CBC nainu

blowfish-cbc opcionalno Blowfish algoritam u CBC nainu kriptiranja. Ima klju duljine 128 bitova.

twofish256-cbc opcionalno Twofish algoritam u CBC nainu sa 256- bitovnim kljuem i 128-bitovnim blokovima

twofish-cbc opcionalno Alias za twofish256-cbc twofish192-cbc opcionalno Twofish algoritam u CBC nainu sa 192-

bitovnim kljuem i 128-bitovnim blokovima twofish128-cbc opcionalno Twofish algoritam u CBC nainu sa 128-

bitovnim kljuem i 128-bitovnim blokovima aes256-cbc opcionalno AES (Advanced Encryption Standard)

algoritam u CBC nainu sa 128-bitovnim blokovima i 256-bitovnim kljuem

aes192-cbc opcionalno AES (Advanced Encryption Standard) algoritam u CBC nainu sa 128-bitovnim blokovima i 192-bitovnim kljuem

aes128-cbc preporueno AES (Advanced Encryption Standard) algoritam u CBC nainu sa 128-bitovnim blokovima i 128-bitovnim kljuem

serpent256-cbc opcionalno Serpent algoritam u CBC nainu sa 256- bitovnim kljuem

serpent192-cbc opcionalno Serpent algoritam u CBC nainu sa 192- bitovnim kljuem

serpent128-cbc opcionalno Serpent algoritam u CBC nainu sa 128- bitovnim kljuem

arcfour opcionalno Arcfour algoritam koji kriptira tok podataka i ima klju duljine 128 bitova. Treba ga izbjegavati jer ima problem sa slabim kljuevima.

idea-cbc opcionalno IDEA algoritam kriptiranja u CBC nainu cast128-cbc opcionalno CAST-128 algoritam u CBC nainu, sa

128-bitovnim kljuem none opcionalno bez enkripcije, ne preporua 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 najkoriteniji, a i dalje je skoro svugdje podran. Iako 3DES ima klju duljine 192 bita, taj klju zapravo ima efektivnu

14

duljinu od 112 bitova, to je manje od preporuenog, pa je puno bolje koritenje nekog drugog algoritma, kao to je npr. "aes128-cbc". Svi algoritmi rade u CBC (cipher block chaining) nainu (osim arcfour algoritma), to znai da se prije kriptiranja vri XOR operacija izmeu istog teksta i prethodnog kriptiranog bloka (ili inicijalizacijskog vektora ako se radi o prvom paketu). Princip rada u tom nainu prikazan je na slici 3.

Slika 3 : CBC nain enkripcije

3.2.6 Integritet podataka

Integritet podataka zatien je tako to se uz svaki paket alje i MAC (message authentication code) koji se rauna iz tajnog kljua, rednog broja paketa i sadraja samog paketa. Tijekom procesa dogovaranja algoritama, dogovara se i koji e se MAC algoritam koristiti. Ako je odabran neki MAC algoritam razliit od "none" (to oznaava da se ne koristi nikakav MAC algoritam) tada e se iz tajnog kljua izraunati MAC kljuevi, jedan za smjer klijent-posluitelj i drugi za smjer posluitelj-klijent. Nakon toga e uz svaki poslani paket biti poslano i MAC polje. Ono se rauna na sljedei nain:

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

gdje MAC oznaava dogovoreni MAC algoritam, mac_klju je klju dobiven nakon razmjene kljueva, 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 koritenje navedenog kljua i rezultat je mac polje koje se alje zajedno s paketom. Strana koja primi paket, prvo ga dekriptira, primijeni mac algoritam na isti nain, i ako dobivena vrijednost nije jednaka primljenoj to znai 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 mogue da klijent i posluitelj koriste razliite MAC algoritme ali to se ne preporua.

15

Tablica 4 : Definirani MAC algoritmi

Ime algoritma Zahtjev Opis algoritma hmac-sha1 obavezno HMAC-SHA1 algoritam, duljina saetka je

160 bitova, kao i duljina kljua hmac-sha1-96 preporueno Prvih 96 bitova HMAC-SHA1 algoritma se

uzimaju kao saetak, klju je duljine 160 bitova

hmac-md5 opcionalno HMAC-MD5 algoritam, duljina saetka je 128 bitova, kao i duljina kljua

hmac-md5-96 opcionalno Prvih 96 bitova HMAC-MD5 algoritma se uzimaju kao saetak, klju je duljine 128 bitova

none opcionalno ne koristi se MAC, ne preporua se

Svi HMAC-* algoritmi opisani su u [10], a zapravo predstavljaju obine algoritme za raunanje saetka (hash) koji se primjenjuju na spoj tajnog kljua i teksta, a ne samo na tekst kao to to rade obini algoritmi za raunanje saetka.

3.2.7 Metode razmjene kljueva

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

Tablica 5 : Definirani algoritmi razmjene kljua 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 kljueva, i sve osim ("diffie-hellman-group-exchange-sha256") koriste sha1 algoritam za raunanje saetka.

Metoda "diffie-hellman-group1-sha1" oznaava Diffie-Hellman algoritam uz koritenje 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

16

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 poalje paket sa zahtjevom u kojem trai te parametre i definira minimalnu i eljenu veliinu u bitovima. Nakon toga, server koji ima veliku bazu izgeneriranih parametra alje modulus i generator klijentu.

3.2.8 Algoritmi javnog kljua

SSH protokol je dizajniran tako da moe raditi s bilo kojim algoritmom javnog kljua. Ti algoritmi se takoer dogovaraju nakon inicijaliziranja konekcije. Ipak, daleko su najkoriteniji DSS (Digital Signature Standard) i RSA algoritmi. Format zapisa njihovih kljueva za primjenu u SSH protokolu definiran je u [2], i oznaen kao "ssh-dss" i "ssh-rsa". DSS algoritam obavezno moraju podravati sve implementacije dok je RSA opcionalan. Oni se koriste za generiranje digitalnog potpisa, to omoguava autentificiranje posluitelja.

Tablica 6 : Definirani formati javnih kljueva Ime formata Zahtjev Opis formata

17

ssh-dss obavezno Sirovi DSS klju ssh-rsa preporueno Sirovi RSA klju pgp-sign-rsa opcionalno OpenPGP certifikat (RSA klju) pgp-sign-dss opcionalno OpenPGP certifikat (DSS klju)

Format zapisa DSS javnog kljua je sljedei: 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 sljedei: 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 kljua je sljedei: string "ssh-rsa" mpint e mpint n

gdje su "e" i "n" parameri RSA algoritma kodirani kao mpint podaci.

Format zapisa RSA potpisa je sljedei: 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" oznaavaju da su kljuevi, certifikati i potpisi u OpenPGP binarnom formatu.

3.2.9 Pregovaranje algoritama

Pregovaranje algoritama poinje tako to obje strane poalju liste (name-list) algoritama koje podravaju. Liste se formiraju po prioritetu i to tako da preferirani algoritmi budu na vrhu liste. Paketi moraju imati sljedei format :

byte SSH_MSG_KEXINIT byte[16] cookie (nasumini bajtovi)

18

name-list algoritmi razmjene kljua name-list algoritmi javnog kljua name-list algoritmi enkripcije od klijenta prema posluitelju name-list algoritmi enkripcije od posluitelja prema klijentu name-list mac algoritmi od klijenta prema posluitelju name-list mac algoritmi od posluitelja prema klijentu name-list algoritmi kompresije od klijenta prema posluitelju name-list algoritmi kompresije od posluitelja prema klijentu name-list jezici od klijenta prema posluitelju name-list jezici od posluitelja prema klijentu boolean slijedi prvi KEXINIT paket uint32 0 (rezervirano za budua proirenja)

Dakle, prvi bajt je SSH_MSG_KEXINIT i govori primatelju o kojoj vrsti paketa se radi, zatim slijedi "cookie", koji je niz od 16 nasuminih bajtova, i slui za oteavanje napada. Nakon toga slijede liste eljenih algoritama odvojenih zarezom (name-list). Algoritam za utvrivanje dogovorenih algoritama je vrlo jednostavan:

1. ako je prvi algoritam u listi klijenta i u listi posluitelja isti, tada je to odabrani algoritam

2. ako prvi algoritam u listama nije isti, tada se ide po listi klijentovih algoritama od poetka do kraja, i prvi algoritam koji se nalazi i na posluiteljevoj listi je odabrani algoritam

3. ako nema niti jednog istog algoritma u listama klijenta i posluitelja, tada je pregovaranje neuspjeno, i klijent i posluitelj prekidaju vezu

Na ovom primjeru koji je preuzet iz log datoteke programa Putty moe 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

19

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 kljueva

Nakon to su utvreni svi potrebni algoritmi koji e se koristiti, kree postupak razmjene kljueva i autentificiranja posluitelja. Iako je teoretski mogue koristiti bilo koju metodu oko koje se klijent i posluitelj dogovore, algoritam razmjene kljua 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 posluitelja. Slijedi opis kompletnog postupka korak po korak. U opisu V_C oznaava klijentov identifikacijski niz, V_S je posluiteljev 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 posluiteljev javni klju, I_C je klijentova SSH_MSG_KEXINIT poruka, a I_S je posluiteljeva SSH_MSG_KEXINIT poruka.

1. klijent generira veliki sluajni broj x i rauna broj e, e = g^x mod p. Klijent alje broj e posluitelju.

2. Posluitelj generira sluajni broj y i rauna broj f, f = g^y mod p. Posluitelj prima broj e. Tada rauna tajni klju K, K = e^y mod p. Takoer rauna H, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K). Posluitelj potpisuje H svojim privatnim kljuem i dobiva potpis s. Posluitelj alje (K_S || f || s) klijentu.

3. Klijent provjerava da javni klju K_S stvarno pripada posluitelju (bilo pomou certifikata ili pomou lokalne baze kljueva). Klijent moe prihvatiti posluiteljev klju i bez provjere, ali to ini protokol ranjivim na man-in-the-middle napade. Klijent takoer

20

rauna tajni klju K, K = f^x mod p, rauna 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 posluitelju, a ne potencijalnim napadaima koji su prislukivali promet. To je osigurano zbog teine raunanja diskretnog logaritma na vrijednostima e i f. Ako nismo provjerili da javni kju stvarno pripada posluitelju tada je mogu aktivni napad, u kojem bi se potencijalni napada nalazio izmeu klijenta i posluitelja i tako iskoristio slabost Diffie-Helman algoritma na man-in-the-middle napade.

Slijedi opis poruka kojima se ostvaruje gore opisana razmjena.

Klijent na poetku alje ovaj paket: byte SSH_MSG_KEXDH_INIT mpint parametar e

Posluitelj odgovara slanjem paketa:

byte SSH_MSG_KEXDH_REPLY string javni klju posluitelja i eventualno certifikati(K_S) mpint parametar f string potpis posluitelja s

Na sljedeem isjeku 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)

21

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 ....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 kljueva kao rezultat imamo vrijednosti K (tajni klju) i H (saetak razmjene). Svi kljuevi za enkripciju i MAC dobivaju se iz te dvije vrijednosti. Saetak H iz prve razmjene se takoer koristi kao identifikator sjednice (session identifier), koji se koristi u autentifikacijskim metodama kao dio podataka koji se digitalno potpisuje privatnim kljuem korisnika. Taj identifikator ostaje isti tokom cijelog trajanja veze.

Kljuevi se generiraju koritenjem hash funkcije koja je dio algoritma razmjene kljueva. Tako se u algoritmu "diffie-hellman-group1-sha1" koristi SHA1 funkcija. Generiraju se drugi kljuevi za svaki smjer enkripcije. Kljuevi se raunaju na sljedei nain: Inicijalni IV (klijent -> posluitelj) = hash (K || H || "A" || identifikator_sjednice) Inicijalni IV (posluitelj -> klijent)

22

= hash (K || H || "B" || identifikator_sjednice) Klju enkripcije (klijent -> posluitelj) = hash (K || H || "C" || identifikator_sjednice) Klju enkripcije (posluitelj -> klijent) = hash (K || H || "D" || identifikator_sjednice) MAC klju (klijent -> posluitelj) = hash (K || H || "E" || identifikator_sjednice) MAC klju (klijent -> posluitelj) = hash (K || H || "F" || identifikator_sjednice) Ovdje su znakovi od "A" do "F" zapravo obini ASCII znakovi, a identifikator sjednice i vrijednost H, su jednaki kod prve razmjene kljueva.

Razmjena kljueva zavrava tako to sva strana poalje paket:

byte SSH_MSG_NEWKEYS

Ovaj paket se alje primjenjujue stare kljueve. Svaka poruka poslana nakon ove mora koristiti nove kljueve i algoritme. Nakon to jedna strana primi ovu poruku ona od tog trenutka pa nadalje mora koristiti nove kljueve za primanje podataka. Nakon zavretka razmjene kljueva klijent e zatraiti pokretanje odreene usluge sljedeim paketom:

byte SSH_MSG_SERVICE_REQUEST string ime usluge

Svaka usluga ima svoje dodijeljeno ime. Najznaajnije su ove dvije usluge: - ssh-userauth - ssh-connection

koje redom oznaavaju autentifikacijski i spojni protokol. Gotovo uvijek nakon zavretka razmjene kljueva klijent e zatraiti pokretanje usluge autentifikacije (ssh-userauth).

Ako posluitelj podrava traenu uslugu i eli prihvatiti poslani zahtjev on to dojavljuje klijentu paketom:

byte SSH_MSG_SERVICE_ACCEPT string ime usluge

Ako, ipak, posluitelj ne eli prihvatit klijentov zahtjev on to ini slanjem sljedee poruke i nakon toga se odspaja:

byte SSH_MSG_DISCONNECT uint32 identifikator razloga prekida

23

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 posluitelj odobri zahtjev poinje proces autentifikacije. Na poetku ovaj protokol prima identifikator sjednice od prijenosnog protokola (to je saetak razmjene H, iz prve razmjene kljueva). Taj identifikator e se koristiti za digitalno potpisivanje ako to odabrana metoda autentifikacije bude zahtijevala. Autentifikacijski proces predvodi posluitelj, tako da klijentu alje poruke u kojima navodi metode autentifikacije koje on podrava. Klijent moe 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 takoer i "none" metoda koja oznaava da nema autentifikacije i da je svakom korisniku doputen pristup. Tu metodu posluitelj ne smije navesti kao jednu od doputenih metoda autentifikacije. Meutim, klijent smije poslati zahtjev za "none" autentifikacijom. U najveem broju sluajeva to e rezultirati time da e mu posluitelj poslati poruku da autentifikacija nije uspjela i u toj poruci navesti autentifikacijske metode koje on podrava. Ako je pak posluitelj konfiguriran tako da prihvaa "none" autentifikaciju, klijentu e biti omoguen pristup. Nakon svakog neuspjenog pokuaja autentifikacije klijentu je omoguen ponovni pokuaj. Ipak, standard preporua da se broj neuspjelih pokuaja ogranii na 20. Nakon tog broja pokuaja posluitelj bi trebao prekinuti vezu.

3.3.1 Zahtjevi za autentifikacijom

Zahtjeve za autentifikacijom klijent ostvaruje slanjem sljedee poruke:

byte SSH_MSG_USERAUTH_REQUEST string korisniko ime string ime usluge string naziv metode autentifikacije .... specifina polja za svaku metodu

Poslani paket je tipa SSH_MSG_USERAUTH_REQUEST, nakon toga ide korisniko ime tog korisnika na raunalu na koje se spaja. Zatim ide polje s nazivom usluge koju treba pokrenuti ako autentifikacija uspije (to je gotovo uvijek "ssh-connection", to oznaava spojni protokol). Nakon toga ide naziv metode autentifikacije koju klijent eli. Najvanije metode dane su u tablici 7.

24

Tablica 7 : Najee metode autentifikacije Ime metode Zahtjev

publickey obavezno password preporueno

keyboard-interactive opcionalno hostbased opcionalno

none ne preporua se

Od navedenih metoda jedino "publickey" metodu moraju podravati sve implementacije. Ovaj popis nije konaan, i mogue je definirati i nove metode.

Ako posluitelj odbije autentifikacijski zahtjev klijenta on e to uiniti slanjem sljedee poruke:

byte SSH_MSG_USERAUTH_FAILURE name-list autentifikacijske metode koje prihvaam boolean djelomian uspjeh

Dakle, posluitelj alje listu metoda koje on u tom trenutku moe prihvatiti. Logika vrijednost djelomian uspjeh koristi se ako je za autentifikaciju potrebno vie od jedne metode. Na primjer, posluitelj moe zahtijevati da se korisnik mora autentificirati i "password" metodom i "publickey" metodom. Nakon to korisnik poalje "password" zahtjev sa ispravnom lozinkom, posluitelj e mu odgovoriti sa SSH_MSG_USERAUTH_FAILURE paketom u kojem e vrijednost varijable djelomian uspjeh biti istina, a u listi prihvatljivih metoda nee biti navedena "password" metoda. To govori klijentu da je autentifikacija lozinkom prola uspjeno, ali da posluitelj zahtjeva jo jednu metodu autentifikacije da bi proces uspjeno zavrio.

Kada posluitelj u potpunosti prihvati autentifikaciju on alje paket:

byte SSH_MSG_USERAUTH_SUCCESS

3.3.2 Autentifikacija pomou javnog kljua ("publickey")

Ova metoda je jedina koju obavezno moraju podravati sve implementacije. Meutim, to ne znai da ona mora biti i jedina doputena, s obzirom da dosta korisnika nema svoj privatni klju za autentifikaciju.

Ova metoda funkcionira tako da klijent poalje posluitelju digitalni potpis koji on stvara svojim privatnim kljuem. Takoer poalje i svoj javni klju. Posluitelj provjerava da taj javni klju pripada tom korisniku. Najee se to radi tako da svaki korisnik u svom direktoriju na posluitelju ima stvorenu datoteku u kojoj se nalaze njegovi javni kljuevi. Na UNIX operacijskim sustavima to je datoteka "authorized_keys2" za verziju 2 protokola i

25

"authorized_keys" za verziju 1 protokola. Sadaj te datoteke moe 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 kljua, jedan RSA i jedan DSS klju, kodirano base64 algoritmom. Da bi taj korisnik uspjeno izvrio autentifikaciju "publickey" metodom, u njegovom zahtjevu mora biti jedan od ta dva kljua. Takoer, digitalni potpis koji on poalje provjeravat e se tim javnim kljuem.

Privatni kljuevi klijenta obino su pohranjeni na njegovom osobnom raunalu, i da bi se ouvala sigurnost ove metode potrebno je da oni budu dobro zatieni. Najbolja metoda za to je, da korisnik prilikom generiranja kljua, zatiti istog unoenjem takozvanog passphrase niza, to e rezultirati time da e privatni klju biti kriptiran. Passphrase niz je dui od lozinke i moe sadravati i znakove razmaka. Svaki put kad on bude potreban, korisnik e biti upitan za unoenje passphrase niza.

Slijedi opis razmjene poruka ovom metodom autentifikacije. Da bi klijent provjerio da li posluitelj prihvaa njegov javni klju on alje sljedeu poruku:

byte SSH_MSG_USERAUTH_REQUEST string korisniko ime string ime usluge string "publickey" boolean NE string ime algoritma javnog kljua string javni klju

Kao to se vidi to je standardna SSH_MSG_USERAUTH_REQUEST poruka kako je opisana gore. Specifina polja su ovdje "publickey" to oznaava da koristimo autentifikaciju javnim kljuem. Logika varijabla NE oznaava da ovaj paket ne sadri digitalni potpis. Zatim ide ime algoritma javnog kljua, najee su to "ssh-rsa" ili "ssh-dss", i na kraju ide javni klju u formatu opisanom u poglavlju 3.2.8.

Ako posluitelj ne prihvaa ponueni javni klju on odgovara slanjem SSH_MSG_USERAUTH poruke. Ako posluitelj prihvaa ponueni klju on e dojaviti klijentu slanjem poruke:

26

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

Nakon to dozna da posluitelj prihvaa njegov javni klju, klijent pomou svog privatnog kljua stvara digitalni potpis i alje sljedeu poruku:

byte SSH_MSG_USERAUTH_REQUEST string korisniko ime string ime usluge string "publickey" boolean DA string ime algoritma javnog kljua 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 logika varijabla sada ima vrijednost DA, to oznaava da je potpis prisutan. Inae, klijent moe odmah poslati ovu poruku bez da prvo provjerava da li posluitelj prihvaa njegov javni klju, ali tada postoji rizik da e klijent uzalud raunati potpis (to je raunski skupa operacija).

Potpis se rauna primjenom odabranog algoritma, pomou klijentovog privatnog kljua nad porukom koja izgleda ovako:

string identifikator_sjednice byte SSH_MSG_USERAUTH_REQUEST string korisniko ime string ime usluge string "publickey" boolean DA string ime algoritma javnog kljua string javni klju

Primitkom ovog paketa, posluitelj provjerava da li je ponueni javni klju prihvatljiv, i zatim provjerava poslani digitalni potpis poslanim javnim kljuem. Ako je potpis ispravan posluitelj alje SSH_MSG_USERAUTH_SUCCESS poruku, ako nije alje SSH_MSG_USERAUTH_FAILURE poruku.

U ovom isjeku iz log datoteke programa Putty moe 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

27

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

28

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

Ako je lozinka zastarila, posluitelj 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 sluaju klijent moe nastaviti pokuati se autentificirati drugom metodom ili moe prikazati klijentu poruku i zatraiti ga unos nove lozinke. Ako je korisnik unio novu lozinku ona se prosljeuje posluitelju u sljedeoj poruci:

byte SSH_MSG_USERAUTH_REQUEST string korisniko 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 namee posluitelj, tada on ponovo alje poruku sa zahtjevom za promjenom lozinke.

Na kraju, ako je autentifikacija uspjela, posluitelj alje SSH_MSG_USERAUTH_SUCCESS poruku, a ako nije on alje SSH_MSG_USERAUTH_FAILURE poruku.

3.3.4 "hostbased" autentifikacija

Ova vrsta autentifikacije slina je metodi koju koriste UNIX r-naredbe, u kojima nakon to posluitelj dobije zahtjev, on iz mrene 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 raunala spremljeno u lokalnu bazu kao raunalo kome je doputena autentifikacija, trai i javni klju tog raunala, a ako je on naen u lokalnoj bazi, provjerava se i poslani digitalni potpis.

Klijent inicira "hostbased" autentifikaciju slanjem poruke:

byte SSH_MSG_USERAUTH_REQUEST string korisniko ime

29

string ime usluge string "hostbased" string algoritam javnog kljua string javni klju raunala klijenta string ime (FQDN) klijentskog raunala string korisniko ime na klijentskom raunalu string digitalni potpis

Digitalni potpis se rauna privatnim kljuem raunala klijenta, a kao poruka se uzima:

string identifikator_sjednice byte SSH_MSG_USERAUTH_REQUEST string korisniko ime string ime usluge string "hostbased" string algoritam javnog kljua string javni klju raunala klijenta string ime (FQDN) klijentskog raunala string korisniko ime na klijentskom raunalu

Nakon primitka ove poruke, posluitelj iz mrene adrese klijenta provjerava da li je FQDM ime raunala isto kao i u zahtjevu. Zatim provjerava u lokalnoj bazi da li poslani javni klju stvarno pripada tom raunalu i da li je tom raunalu i prijavljenom korisniku doputena autentifikacija. Na kraju provjerava poslani digitalni potpis. Ako je autentifikacija uspjela posluitelj alje SSH_MSG_USERAUTH_SUCCESS paket, a ako nije on alje SSH_MSG_USERAUTH_FAILURE paket sa podranim metodama autentifikacije.

3.4 Spojni protokol

Spojni protokol je najvii sloj SSH protokola i vrti se iznad prijenosnog i autentifikacijskog sloja. Ta dva protokola i sigurnost koju oni nude nuni su za rad spojnog protokola. Spojni protokol nudi usluge kao to su interaktivne sjednice (interactive login session), udaljeno izvravanje naredbi, prosljeivanje TCP/IP prometa, i tuneliranje X11 konekcija. Osnovni pojam u SSH spojnom protokolu je kanal. Sve interaktivne sjednice i prosljeivanja vre se kroz kanale. Oni su dodue samo virtualni koncept jer se svi otvoreni kanali multipleksiraju kroz jednu vezu, uspostavljenu jo u prijenosnom sloju. Svaki kanal je odreen brojem ili identifikatorom na svakom svom kraju (lokalnom i udaljenom), i ti brojevi mogu ak i biti razliiti za svaki kraj. Svaki zahtjev za otvaranjem novog kanala sadri u sebi identifikator kanala koji pripada poiljatelju. Sve druge poruke spojnog protokola u sebi sadre identifikator kanala primatelja. Za kontrolu toka podataka (flow control) koristi se koncept klizeih prozora, to znai da nije doputeno slanje podataka, ako

30

suprotna strana nema dovoljno velik prozor sve dok ona ne dojavi da poveava veliinu prijemnog prozora.

3.4.1 Otvaranje kanala

Kada jedna strana eli otvoriti novi kanal ona prvo dodijeli lokalni identifikator tom kanalu i poalje suprotnoj strani sljedeu poruku:

byte SSH_MSG_CHANNEL_OPEN string vrsta kanala uint32 broj kanala poiljatelja uint32 inicijalna veliina prozora uint32 maksimalna veliina paketa .... podaci ovisni o vrsti kanala

Inicijalna veliina prozora predstavlja broj bajtova koje je mogue poslati poiljatelju ove poruke prije nego to on povea veliinu prozora. Maksimalna veliina paketa oznaava maksimalnu veliinu pojedinanog paketa, koju poiljatelj ove poruke moe primiti. Poeljno je da to bude to manje kod interaktivnih sjednica, da bi vrijeme odgovora bilo to manje.

Ako suprotna strana prihvaa zahtjev za otvaranjem kanala ona alje sljedeu poruku:

byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION uint32 broj kanala primatelja uint32 broj kanala poiljatelja uint32 inicijalna veliina prozora uint32 maksimalna veliina paketa .... podaci ovisni o vrsti kanala

Broj kanala primatelja je broj koji je dobiven u originalnom CHANNEL_OPEN zahtjevu, dok je broj kanala poiljatelja, 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 sljedee 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 razliiti, a definirana su etiri standarda identifikatora: SSH_OPEN_ADMINISTRATIVELY_PROHIBITED

31

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 reeno da se kontrola toka podataka (flow control) vri algoritmom klizeih prozora. Poruka kojom primatelj vri poveavanje veliine prijemnog prozora izgleda ovako:

byte SSH_MSG_CHANNEL_WINDOW_ADJUST uint32 broj kanala primatelja uint32 broj bajtova

Nakon primitka ovakve poruke primatelj moe poslati broj bajtova vie podataka nego to je to mogao prije. Podaci se prenose sljedeom porukom:

byte SSH_MSG_CHANNEL_DATA uint32 broj kanala primatelja string podaci

Najvea koliina podataka koju jedna strana moe poslati jednaka je veliini prijemnog prozora primatelja ili maksimalnoj veliina paketa za tog primatelja, to god je manje. Nakon slanja podataka, poiljatelj umanjuje veliinu prozora za broj podataka koji je poslao. Takoer je mogue slanje posebnog tipa podataka, kao na primjer slanje stderr izlaza iz interaktivnih sjednica. Slanje se vri sljedeom porukom:

byte SSH_MSG_CHANNEL_EXTENDED_DATA uint32 broj kanala primatelja uint32 tip podataka string podaci

Podaci poslani ovim putem takoer smanjuju veliinu prozora.

3.4.3 Zatvaranje kanala

Kada neka strana vie ne eli slati podatke, ona to javlja slanjem poruke:

byte SSH_MSG_CHANNEL_EOF uint32 broj kanal primatelja

32

Nakon te poruke kanal ostaje i dalje otvoren i mogue 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 takoer 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 izvravanje programa. Taj program moe biti ljuska operacijskog sustava (shell), aplikacija, neka sistemska naredba ili ak i neki ugraeni podsustav (npr. scp, sftp). Sjednica se pokree slanjem poruke:

byte SSH_MSG_CHANNEL_OPEN string "session" uint32 broj kanala poiljatelja uint32 inicijalna veliina prozora uint32 maksimalna veliina paketa

Ovakve zahtjeve bi trebali slati samo klijenti i ako je posluitelj u kojem sluaju poalje, 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 posluitelj odgovara. Ako je stvaranje uspjelo on alje:

byte SSH_MSG_CHANNEL_SUCCESS uint32 broj kanala primatelja

33

Ako stvaranje pseudo-terminala nije uspjelo posluitelj alje:

byte SSH_MSG_CHANNEL_FAILURE uint32 broj kanala primatelja

Kada klijent eli zapoeti preusmjeravanje X11 prometa sa posluitelja, on to zatrai 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 prosljeuju 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 najee zatraiti pokretanje nekog programa. Taj program moe biti neka aplikacija, ili ljuska operativnog sustava (shell) ili neki podsustav (scp, sftp). Dozvoljeno je pokretanje samo jednog ovakvog programa po sjednici, to znai da e nakon to program zavri morati zavriti i sjednica. Pokretanje ljuske operacijskog sustava vri 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 oznaio da eli odgovor, posluitelj 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 izvriti jednu naredbu on alje poruku:

34

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

Ugraeni podsustavi (scp, sftp) se pokreu 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 posluitelju.

Kada naredba ili program koju je klijent pokrenuo na drugoj strani zavri ona vraa izlazni status. Taj broj moe koristiti klijentu jer on moe utvrditi da li je izvravanje naredbe uspjelo ili je dolo do greke. Posluitelj moe poslati izlazni status sljedeom porukom:

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

3.4.5 Prosljeivanje TCP/IP prometa

Ako jedna strana u komunikaciji eli da sav promet sa suprotne strane bude preusmjeren njoj moe to postii metodom prosljeivanja mrenih 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 veemo uint32 broj pristupa koji veemo

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 posluitelju onda posluitelj, nakon to mu pristigne zahtjev na toj adresi, otvara novi kanal slanjem poruke:

35

byte SSH_MSG_CHANNEL_OPEN string "forwarded-tcpip" uint32 broj kanala poiljatelja uint32 inicijalna veliina prozora uint32 maksimalna veliina paketa string mrena adresa koja je spojena uint32 mreni pristup koji je spojen string mrena adresa originalnog zahtjeva uint32 mreni pristup originalnog zahtjeva

Ako je adresa koja je vezana za preusmjeravanje prometa na raunalu 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 poiljatelja uint32 inicijalna veliina prozora uint32 maksimalna veliina paketa string adresa na koju se spaja uint32 pristup na koji se spaja string adresa originalnog zahtjeva uint32 pristup originalnog zahtjeva

Nakon toga sav mreni promet preusmjerava se kroz SSH kanal.

36

4 Praktini rad Praktini dio zadatka bila je izrada raunalnog programa koji e simulirati rad SSH protokola. Ideja je bila da simulator omoguava uvid u sve vane podatke u svakom koraku simulacije, da omoguava dinamiko mijenjanje istih kako bi se ispitalo ponaanje i sigurnost protokola. Treba rei da zbog jednostavnosti i preglednosti program ne simulira apsolutno sve funkcije protokola, nego se bazira na najvanije dijelove tj. jezgru protokola. Tako funkcije kao to su kompresija, prosljeivanje portova (port forwarding) i interaktivne sjednice (interactivne login session) nisu implementirane.

4.1 Programska implementacija

Raunalni program koji je izraen zove se SSH Simulator. Program je implementiran u programskom jeziku Java. Za izradu je iskoritena biblioteka klasa Ganymed SSH-2 for Java (http://www.ganymed.ethz.ch/ssh2) koja prua niz korisnih klasa. Tu su klase za kriptiranje algoritmima AES, Blowfish i 3DES, zatim klase za raunanje saetka algoritmima MD5 i SHA1, klase za dekodiranje datoteka s kljuevima itd. Za izradu je koritena 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 zaduena za iscrtavanje korisnikog suelja i komunikaciju s korisnikom. Sve podatke koje korisnik unese ova klasa prosljeuje klasama Klijent i Server. Takoer, ova klasa upravlja tijekom simulacije. Nakon to korisnik stisne gumb za sljedei korak simulacije ova klasa zove odreene 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 uspjeno sudjelovati u komunikaciji. Klasa Server implementira serversku stranu u

37

komunikaciji i implementira sve strukture podataka i metode potrebne da bi server mogao uspjeno sudjelovati u komunikaciji. Na poetku, nakon to korisnik stisne gumb za pokretanje simulacije, SSHSimulator objekt instancira objekte klijenta i servera i meusobno ih spaja sa dva para PipedInputStream/PipedOutputStream objekata. Ti objekti simuliraju mrenu vezu koja u stvarnim implementacijama postoji izmeu klijenta i servera. Sva komunikacija izmeu njih ide kroz te objekte.

4.2 Koritenje programa

Slijedi opis koritenja programa.

Slika 5 : Podruje 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 zapoinje simulaciju i poslije se koristi za prelazak na sljedei korak simulacije. Do njega je gumb "Reset" koji se koristi za ponitavanje tijeka simulacije i vraanje na poetak. Odmah pored nalazi se polje u kojem za svaki korak simulacije pie objanjenje to se trenutno dogaa. Iznad tih polja nalaze se etiri tekstualna prozora, dva na klijentskoj strani te dva na serverskoj. U tim prozorima ispisuje se sav promet koji odreena strana u komunikaciji dobiva. U gornjem prozoru ispisuje se sirovi (kriptirani) promet, dok se u donjem ispisuje dekriptirani promet (takoer se uklanja zaglavlje i dopuna).

Na poetku simulacije korisnik moe odabrati inicijalizacijske nizove koji se alju. Takoer, mogue je odabrati algoritme koji se koriste u postupku pregovaranja. Taj dio suelja prikazan je na slici 6. Na klijentskom dijelu prozora mogue je odabrati redoslijed algoritama. Redoslijed se mijenja gumbima "Gore" i "Dolje", a mogue je odabirati algoritme za razmjenu kljueva, za digitalni potpis, za enkripciju i MAC. Pozicija na listi odreuje koliko je algoritam poeljan, tako da su algoritmi na vrhu najpoeljniji. Ovo e

38

Slika 6 : Suelje 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 mogue odabirati koje e algoritme server prijaviti u pregovaranju a koje nee. Ovdje redoslijed nije bitan jer se odabrani algoritmi biraju po prioritetu koji poalje klijent. Neke algoritme nije mogue izbaciti. To su algoritmi koji su prema SSH standardu obavezni i sve strane ih moraju podravati kako bi rad protokola bio mogu.

Slika 7 : Dijalog sa odabranim algoritmima Na kraju postupka, nakon to i klijent i server poalju svoje liste sa eljenim algoritmima, oni se odabiru i korisniku se prikazuju u dijalogu kakav se moe vidjeti na slici 7.

Sljedei korak je Diffie-Hellman razmjena kljueva. Suelje prikazuje sve parametar iz te razmjene (modulus p, generator g, parametri e i f, tajni klju K) i mogue je u svakom trenutku mijenjati te parametre. Izgled suelja prikazan je na slici 8. U ovom dijelu simulacije takoer se vri autentifikacija servera. Korisniku je omogueno da sa datotenog sustava odabere datoteke u kojima se nalaze

39

DSS i RSA privatni kljuevi servera. Javni kljuevi i digitalni potpisi se takoer prikazuju korisniku i on ih moe u svakom trenutku promijeniti.

Slika 8 : Suelje za Diffie-Hellman razmjenu i autentificiranje servera

Slika 9 : Dijalog sa fingerprint nizom

Kao dio autentifikacije servera potrebno je utvrditi ispravnost njegovog javnog kljua. To se radi tako da se korisniku ispie MD5 saetak kljua (fingerprint) i pita ga se da li prihvaa taj klju kao valjan, to je prikazano na slici 9.

Nakon Diffie-Hellman razmjene slijedi generiranje kljueva. Suelje je prikazano na slici 10. Tu se odmah na poetku nalaze parametri K i G koji su rezultat iz prolog koraka, a koriste se za generiranje svih potrebnih kljueva. Njihove vrijednosti se mogu promijeniti u svakom trenutku. Iz te dvije vrijednosti generiraju se dva inicijalizacijska vektora i dva kljua enkripcija (po jedan za svaki smjer komuniciranja). Takoer se generiraju i dva MAC kljua. Vrijednosti na klijentskoj i serverovoj strani bi trebale biti jednake ako je sve bilo kako treba. Sve ove parametre mogue je mijenjati u svakom trenutku.

40

Slika 10 : Suelje za generiranje kljueva Sljedei korak u postupku je autentificiranje korisnika. Korisniku je iz padajueg izbornika ponueno biranje izmeu dvije implementirane metode: "publickey" i "password". Ako korisnik odabere "password" metodu, on moe upisati korisniko ime i lozinku u za to predviena polja. Na serverskoj strani mogue je odabrati koje metode su doputene ("publickey" je prema standardu obavezna). Mogue je odabrati datoteku u kojoj se nalaze korisnika imena i lozinke. Format datoteke je jednostavan, u svakom redu nalazi se jedno korisniko ime, zatim ide razmak, i na kraju pripadajua lozinka. Sve linije koje zapoinju znakom "#" se smatraju komentarima. Ako je odabrana "publickey" metoda na klijentskoj strani tada je korisniku mogue odabiranje datoteke sa privatnim kljuem korisnika. Mogue je odabrati DSS ili RSA klju. Inae datoteke su u PEM formatu, tj. iste su kao datoteke koje generira OpenSSH. Kljuevi nisu kriptirani. Na serverskoj strani mogue je odabrati datoteku u kojoj se nalaze autorizirani javni kljuevi, tj. oni kojima je doputeno spajanje (isto kao datoteka authorized_keys na OpenSSH implementacijama). Poslani kljuevi i potpisi se prikazuju korisniku i mogue ih je mijenjati.

Slika 11 : Suelje za autentifikaciju

41

Zadnji korak je suelje u kojem se moe kontrolirati tijek spojnog protokola (slika 12). Ovdje nije implementirana najee koritena usluga spojnog protokola, a to je interaktivna sjednica (interactive login session) niti slabije koritena usluga kao to je prosljeivanje mrenih pristupa (port forwarding). Implementirano je obino udaljeno izvravanje naredbe. Korisnik moe podeavati identifikatore otvorenog kanala i na klijentu i na serveru. Takoer moe podeavati veliinu prijemnog prozora na klijentu. Moe se podesiti i naredba koja e se izvriti na serveru (podrazumijevana naredba je dir ili ls ovisno na kojem operacijskom sustavu je program pokrenut). Naredba se izvri i nakon toga server poalje 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 izvravanja naredbe.

Slika 12 : Udaljeno izvravanje naredbe

42

5 Zakljuak Nakon prouavanja SSH protokola mogu rei da to je to jedan od protokola koji e u budunosti sve vie dobivati na popularnosti, sve dok se ne pojavi neko globalno rjeenje koje e uini Internet promet sigurnijim (npr. IPsec). Njegovi najvei aduti su njegov modularan dizajn, koji doputa dodavanje novih algoritama i podsustava, kad se pokae da su stari nesigurni ili ne pruaju dovoljnu funkcionalnost. Drugi adut je njegova jednostavnost, jer je to protokol lake kategorije koji praktiki ne zahtijeva nikakvu infrastrukturu i njegove programske implementacije su velike nekoliko stotina kilobajta, i mogu biti prikladne za male mobilne ureaje. 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 budunosti pojaviti vie alata koji e koristiti tu funkcionalnost. Najvee mane su nedostatak PKI infrastrukture koja bi omoguavala provjeravanje vlasnitva nad javnim kljuevima, pa je SSH u dananjim implementacijama ranjiv na aktivne ovjek-u-sredini napade (man-in-the-middle). Drugi ozbiljniji napadi na SSH protokol nisu pronaeni, a manje ranjivosti pokazane u [13], [14] i [16], su u praksi jako teko ostvarive. Praktini dio seminara tj. izrada simulatora SSH protokola mi je omoguilo puno bolje s upoznavanje sa samim protokolom, i mislim da je program dosta zgodan za vizualizaciju rada protokola i koritenje u edukativne svrhe. Znatieljnici koji svakodnevno koriste taj protokol, a zapravo ne znaju kako on funkcionira, mogu vidjeti kako izgleda rad tog protokola korak po korak.

43

6 Literatura

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

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

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

[4] Ylnen, 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.

44

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

45

7 Dodaci Dodatak A Identifikatori poruka

Protokolom su definirane sljedee poruke, a njihovi identifikatori su predstavljeni kao cijeli brojevi veliine 8 bitova i dani su u sljedeoj 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_AD