SVEUILITE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAUNARSTVA

DIPLOMSKI RAD br. 1697

ANALIZA I SIMULACIJA SSH PROTOKOLA

Tihomir Mei

Zagreb, 2007.

Sadraj :
1 2 Uvod ....................................................................................................... 1 Povijest, razvoj i slini protokoli ......................................................... 3

2.1 2.2 2.3

3

Povijest i razvoj SSH protokola ................................................ 3 R-naredbe................................................................................. 4 TELNET.................................................................................... 4 Pregled arhitekture ................................................................... 6
Podatkovne strukture SSH protokola........................................ 7 Brojevi poruka........................................................................... 8 Uspostavljanje veze.................................................................. 9 Kompatibilnost sa starim verzijama ........................................ 10 SSH binarni paketni protokol .................................................. 11 Algoritmi kompresije ............................................................... 12 Algoritmi enkripcije.................................................................. 12 Integritet podataka .................................................................. 14 Metode razmjene kljueva ...................................................... 15 Algoritmi javnog kljua ............................................................ 16 Pregovaranje algoritama......................................................... 17 Razmjena kljueva.................................................................. 19 Zahtjevi za autentifikacijom..................................................... 23 Autentifikacija pomou javnog kljua ("publickey") ................. 24 Autentifikacija pomou lozinke ("password")........................... 27 "hostbased" autentifikacija ...................................................... 28

Arhitektura SSH protokola ................................................................... 6

3.1 3.2

3.1.1 3.1.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 3.2.10

Prijenosni protokol .................................................................... 9

3.3

Autentifikacijski protokol ......................................................... 23

3.3.1 3.3.2 3.3.3 3.3.4

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 Praktini rad ........................................................................................ 36

4.1 4.2
5 6 7

Programska implementacija ................................................... 36 Koritenje programa ............................................................... 37

Zakljuak.............................................................................................. 42 Literatura ............................................................................................. 43 Dodaci .................................................................................................. 45

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 1

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.

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

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.

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-themiddle napadi, u kojima bi se potencijalni napada predstavljao kao TELNET server i doao 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 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.

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 7

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.

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 DiffieHellman 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

klijentskoj strani je program Putty, dok je na posluiteljskoj strani OpenSSH implementacija:

Event Event Event Event Event Log: Log: Log: Log: Log: Looking up host "192.168.145.2" Connecting to 192.168.145.2 port 22 Server version: SSH-1.99-OpenSSH_3.9p1 We claim version: SSH-2.0-PuTTY-Release-0.56 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.

10

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 duljina paketa duljina dopune korisne informacije

Tip podataka uint32 byte byte[n1]

dopuna

byte[n2]

MAC

byte[m]

Opis Oznaava duljinu paketa u bajtovima, bez MAC polja, i bez sebe samog Oznaava duljinu nasumine dopune u bajtovima Ovdje su pohranjene korisne informacije. Ako je kompresija dogovorena ovo polje je komprimirano. Duljina ovog polja je n1 = duljina_paketa duljina_dopune - 1 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. 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 11

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 none obavezno zlib opcionalno

Opis algoritma bez kompresije 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 klijentposluitelj, dok se za smjer posluitelj-klijent koristi drugi klju i inicijalizacijski vektor. Osim toga mogue je ak da se koristi jedan algoritam enkripcije za

12

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 3des-cbc blowfish-cbc twofish256-cbc twofish-cbc twofish192-cbc twofish128-cbc aes256-cbc

Zahtjev obavezno opcionalno opcionalno opcionalno opcionalno opcionalno opcionalno

aes192-cbc

opcionalno

aes128-cbc

preporueno

serpent256-cbc serpent192-cbc serpent128-cbc arcfour

opcionalno opcionalno opcionalno opcionalno

idea-cbc cast128-cbc none

opcionalno opcionalno opcionalno

Opis algoritma enkripcija-dekripcija-enkripcija DES algoritmom, sa tri kljua, u CBC nainu Blowfish algoritam u CBC nainu kriptiranja. Ima klju duljine 128 bitova. Twofish algoritam u CBC nainu sa 256bitovnim kljuem i 128-bitovnim blokovima Alias za twofish256-cbc Twofish algoritam u CBC nainu sa 192bitovnim kljuem i 128-bitovnim blokovima Twofish algoritam u CBC nainu sa 128bitovnim kljuem i 128-bitovnim blokovima AES (Advanced Encryption Standard) algoritam u CBC nainu sa 128-bitovnim blokovima i 256-bitovnim kljuem AES (Advanced Encryption Standard) algoritam u CBC nainu sa 128-bitovnim blokovima i 192-bitovnim kljuem AES (Advanced Encryption Standard) algoritam u CBC nainu sa 128-bitovnim blokovima i 128-bitovnim kljuem Serpent algoritam u CBC nainu sa 256bitovnim kljuem Serpent algoritam u CBC nainu sa 192bitovnim kljuem Serpent algoritam u CBC nainu sa 128bitovnim kljuem Arcfour algoritam koji kriptira tok podataka i ima klju duljine 128 bitova. Treba ga izbjegavati jer ima problem sa slabim kljuevima. IDEA algoritam kriptiranja u CBC nainu CAST-128 algoritam u CBC nainu, sa 128-bitovnim kljuem 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

13

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.

14

Tablica 4 : Definirani MAC algoritmi

Ime algoritma hmac-sha1 hmac-sha1-96

Zahtjev obavezno preporueno

hmac-md5 hmac-md5-96

opcionalno opcionalno

none

opcionalno

Opis algoritma HMAC-SHA1 algoritam, duljina saetka je 160 bitova, kao i duljina kljua Prvih 96 bitova HMAC-SHA1 algoritma se uzimaju kao saetak, klju je duljine 160 bitova HMAC-MD5 algoritam, duljina saetka je 128 bitova, kao i duljina kljua Prvih 96 bitova HMAC-MD5 algoritma se uzimaju kao saetak, klju je duljine 128 bitova 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 diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 diffie-hellman-group-exchange-sha1 diffie-hellman-group-exchange-sha256

Zahtjev obavezno obavezno opcionalno 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

15

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 29024E08 EF9519B3 E485B576 EE386BFB C2007CB8 83655D23 670C354E E39E772C DE2BCBF6 15728E5A FFFFFFFF 8A67CC74 CD3A431B 625E7EC6 5A899FA5 A163BF05 DCA3AD96 4ABC9804 180E8603 95581718 8AACAA68 C90FDAA2 020BBEA6 302B0A6D F44C42E9 AE9F2411 98DA4836 1C62F356 F1746C08 9B2783A2 3995497C FFFFFFFF 2168C234 3B139B22 F25F1437 A637ED6B 7C4B1FE6 1C55D39A 208552BB CA18217C EC07A28F EA956AE5 FFFFFFFF C4C6628B 514A0879 4FE1356D 0BFF5CB6 49286651 69163FA8 9ED52907 32905E46 B5C55DF0 15D22618 80DC1CD1 8E3404DD 6D51C245 F406B7ED ECE45B3D FD24CF5F 7096966D 2E36CE3B 6F4C52C9 98FA0510

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

16

ssh-dss ssh-rsa pgp-sign-rsa pgp-sign-dss

obavezno preporueno opcionalno opcionalno

Sirovi DSS klju Sirovi RSA klju OpenPGP certifikat (RSA klju) OpenPGP certifikat (DSS klju)

Format zapisa DSS javnog kljua je sljedei:

string mpint mpint mpint mpint "ssh-dss" p q g y

gdje su p, q, q i y parametri DSS algoritma kodirani kao mpint podaci. Format zapisa DSS digitalnog potpisa je sljedei:
string string "ssh-dss" 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 mpint mpint "ssh-rsa" e n

gdje su "e" i "n" parameri RSA algoritma kodirani kao mpint podaci. Format zapisa RSA potpisa je sljedei:
string string "ssh-rsa" 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 byte[16] SSH_MSG_KEXINIT cookie (nasumini bajtovi)

17

name-list name-list name-list name-list name-list name-list name-list name-list name-list name-list boolean uint32

algoritmi razmjene kljua algoritmi javnog kljua algoritmi enkripcije od klijenta prema posluitelju algoritmi enkripcije od posluitelja prema klijentu mac algoritmi od klijenta prema posluitelju mac algoritmi od posluitelja prema klijentu algoritmi kompresije od klijenta prema posluitelju algoritmi kompresije od posluitelja prema klijentu jezici od klijenta prema posluitelju jezici od posluitelja prema klijentu slijedi prvi KEXINIT paket 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 00000010 00000020 00000030 00000040 00000050 00000060 00000070 00000080 00000090 000000a0 000000b0 000000c0 000000d0 000000e0 000000f0 00000100 00000110 1c fb 09 b9 09 1a 5d 7b 8e d1 f0 fe 95 90 7f ad 00 00 00 59 64 69 66 66 69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70 2d 65 78 63 68 61 6e 67 65 2d 73 68 61 31 2c 64 69 66 66 69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70 31 34 2d 73 68 61 31 2c 64 69 66 66 69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70 31 2d 73 68 61 31 00 00 00 0f 73 73 68 2d 72 73 61 2c 73 73 68 2d 64 73 73 00 00 00 87 61 65 73 31 32 38 2d 63 62 63 2c 33 64 65 73 2d 63 62 63 2c 62 6c 6f 77 66 69 73 68 2d 63 62 63 2c 63 61 73 74 31 32 38 2d 63 62 63 2c 61 72 63 66 6f 75 72 2c 61 65 73 31 39 32 2d 63 62 63 2c 61 65 73 32 35 36 2d 63 62 63 2c 72 69 6a 6e 64 61 65 6c 2d 63 62 63 40 6c 79 73 61 74 6f 72 2e 6c 69 75 2e 73 65 2c 61 65 73 31 32 38 2d 63 74 72 2c 61 65 73 31 39 32 2d 63 74 72 2c 61 65 73 32 35 36 2d 63 74 72 00 00 00 87 61 65 73 31 32 38 2d 63 62 63 2c 33 64 65 73 2d 63 ......]{........ ...Ydiffie-hellm an-group-exchang e-sha1,diffie-he llman-group14-sh a1,diffie-hellma n-group1-sha1... .ssh-rsa,ssh-dss ....aes128-cbc,3 des-cbc,blowfish -cbc,cast128-cbc ,arcfour,aes192cbc,aes256-cbc,r ijndael-cbc@lysa tor.liu.se,aes12 8-ctr,aes192-ctr ,aes256-ctr....a es128-cbc,3des-c

18

00000120 00000130 00000140 00000150 00000160 00000170 00000180 00000190 000001a0 000001b0 000001c0 000001d0 000001e0 000001f0 00000200 00000210 00000220 00000230 00000240 00000250 00000260

62 63 2c 62 6c 6f 77 66 69 73 68 2d 63 62 63 2c 63 61 73 74 31 32 38 2d 63 62 63 2c 61 72 63 66 6f 75 72 2c 61 65 73 31 39 32 2d 63 62 63 2c 61 65 73 32 35 36 2d 63 62 63 2c 72 69 6a 6e 64 61 65 6c 2d 63 62 63 40 6c 79 73 61 74 6f 72 2e 6c 69 75 2e 73 65 2c 61 65 73 31 32 38 2d 63 74 72 2c 61 65 73 31 39 32 2d 63 74 72 2c 61 65 73 32 35 36 2d 63 74 72 00 00 00 55 68 6d 61 63 2d 6d 64 35 2c 68 6d 61 63 2d 73 68 61 31 2c 68 6d 61 63 2d 72 69 70 65 6d 64 31 36 30 2c 68 6d 61 63 2d 72 69 70 65 6d 64 31 36 30 40 6f 70 65 6e 73 73 68 2e 63 6f 6d 2c 68 6d 61 63 2d 73 68 61 31 2d 39 36 2c 68 6d 61 63 2d 6d 64 35 2d 39 36 00 00 00 55 68 6d 61 63 2d 6d 64 35 2c 68 6d 61 63 2d 73 68 61 31 2c 68 6d 61 63 2d 72 69 70 65 6d 64 31 36 30 2c 68 6d 61 63 2d 72 69 70 65 6d 64 31 36 30 40 6f 70 65 6e 73 73 68 2e 63 6f 6d 2c 68 6d 61 63 2d 73 68 61 31 2d 39 36 2c 68 6d 61 63 2d 6d 64 35 2d 39 36 00 00 00 09 6e 6f 6e 65 2c 7a 6c 69 62 00 00 00 09 6e 6f 6e 65 2c 7a 6c 69 62 00 00 00 00 00 00 00 00 00 00 00 00 00

bc,blowfish-cbc, cast128-cbc,arcf our,aes192-cbc,a es256-cbc,rijnda el-cbc@lysator.l iu.se,aes128-ctr ,aes192-ctr,aes2 56-ctr...Uhmac-m d5,hmac-sha1,hma c-ripemd160,hmac -ripemd160@opens sh.com,hmac-sha1 -96,hmac-md5-96. ..Uhmac-md5,hmac -sha1,hmac-ripem d160,hmac-ripemd 160@openssh.com, hmac-sha1-96,hma c-md5-96....none ,zlib....none,zl 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

19

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-themiddle napade. Slijedi opis poruka kojima se ostvaruje gore opisana razmjena. Klijent na poetku alje ovaj paket:
byte mpint SSH_MSG_KEXDH_INIT parametar e

Posluitelj odgovara slanjem paketa:

byte string mpint string SSH_MSG_KEXDH_REPLY javni klju posluitelja i eventualno certifikati(K_S) parametar f 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 00000010 00000020 00000030 00000040 00000050 00000060 00000070 00000080 00000090 000000a0 000000b0 000000c0 000000d0 000000e0 000000f0 00000100 00 00 01 00 7b 9b 14 1c 58 76 a8 a8 75 89 ee a5 cc 6f e1 7a c8 0a 1e 2c 98 de 7e fc 43 d2 b3 a0 4e 7f 17 11 81 34 72 b8 60 bb 0f f2 49 53 d0 0c e8 14 79 1c 7d 7a 64 43 da f3 3b cd 84 67 ab 33 e0 c5 3f 84 fb f6 f9 b7 df 94 f5 63 99 02 77 c4 48 2c 4e f0 39 aa ee 68 41 79 2a 1a 27 53 63 8d 69 be 06 2f 80 19 dc ac 4a 12 1c 5d 2e 99 cd 1c 19 d8 4e e4 10 08 b3 66 87 6c d6 35 3e 76 00 cc 93 74 93 13 06 3e 30 94 23 48 26 5a 17 1d a8 97 7b d7 db e4 21 86 d7 7d f6 1e 9e e7 1c 39 e9 69 54 43 0b 74 73 46 e1 5c 78 6b 7f d9 d2 eb 6c 1f 38 f8 fc 16 33 7f c2 13 ff 27 c9 bc 55 f2 08 ae c0 b3 c7 fc 89 56 f0 69 f6 42 da 60 b0 e2 90 2f dc 37 98 b4 c1 02 d3 1e a0 1a c3 b1 b8 62 45 31 38 d5 05 92 67 c7 4c 6b 93 9b aa b4 29 bc b8 8a a8 c5 de f8 22 13 11 54 f0 b6 00 8b 0b b1 61 b7 9a 3f 2d b9 ....{...Xv..u... .o.z...,..~.C... N....4r.`...IS.. ..y.}zdC..;..g.3 ..?........c..w. H,N.9..hAy*.'Sc. i../....J..].... ..N....f.l.5>v.. .t...>0.#H&Z.... {...!..}.....9.i TC.tsF.\xk....l. 8...3....'..U... .....V.i.B.`.../ .7...........bE1 8...g.Lk....)... ...."..T......a. .?-.

Incoming packet type 31 / 0x1f (SSH2_MSG_KEXDH_REPLY)

20

00000000 00000010 00000020 00000030 00000040 00000050 00000060 00000070 00000080 00000090 000000a0 000000b0 000000c0 000000d0 000000e0 000000f0 00000100 00000110 00000120 00000130 00000140 00000150 00000160 00000170 00000180 00000190 000001a0 000001b0 000001c0 000001d0 000001e0 000001f0 00000200 00000210 00000220

00 00 00 95 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 01 23 00 00 00 81 00 da b9 53 d1 51 28 36 a2 62 67 bb a4 56 f0 ae 37 86 56 88 56 4f 73 a3 5e f3 8a 9f 2f 11 86 ee 6f 1a 2b 76 11 83 61 d6 7f 44 ee 26 7d aa 2d ef 10 02 75 e0 f2 40 ba aa 4a a8 df 60 28 6a 49 f6 7b 36 95 1f f8 ab 34 5e f2 16 63 4e 20 31 64 ae 94 1e e9 dd 61 61 f3 c3 90 9f b3 8e 22 30 f1 08 50 83 68 ca 94 ad 82 d4 d3 25 26 69 66 91 79 ea 7c 7b 03 50 b1 fb 4a be e3 40 f6 b1 e2 51 40 32 f9 00 00 01 00 59 a2 72 68 b7 16 49 a3 c9 f1 59 0a 67 3a b6 04 24 50 29 dc ab 66 85 51 88 7b 1f 2d 34 96 bc ba ed 01 db 92 f7 d0 71 14 e8 57 28 f0 40 61 0f 0c 73 40 72 39 a9 51 59 f8 d7 02 d8 6a ff 5a be 48 95 90 ca ac 1d f5 2c 79 2e 7a a3 dd 18 da 30 a4 87 30 6f bd 05 d7 f6 87 69 22 87 03 e4 73 4f 13 a2 66 71 39 0e 0c 9e 5d a0 38 32 d8 fb 42 90 b8 44 7f 1a 92 c6 fe 0b b7 ac 72 3b f7 57 75 aa 49 fa 06 9a 3c ef 28 44 6f 80 97 fd a5 3a 31 4e 0e e0 86 4a 88 cb 66 6b b6 dd 84 e1 df ef 87 a0 41 6e ac 6c de 42 06 e9 48 13 40 62 b3 d0 f6 36 a6 49 94 0a 2d 9e 4d ce ef b9 3e 02 c1 90 f3 70 62 52 54 2f 90 27 b3 b2 f4 e2 64 8f 53 81 26 0a ff b0 cd bb ab 78 a3 1f 40 b4 3f aa 1f 98 b9 47 0a c5 34 2c c3 9a 9b 43 ac 22 f3 65 86 9e 81 56 d3 4b 81 53 a1 c6 24 a9 24 82 46 a9 b9 a1 37 49 ff 00 00 00 8f 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 80 74 bb 21 5e 51 c0 88 e7 25 be cf 87 62 c4 70 a1 0e 11 17 e8 ba 6a fb df 75 d8 e3 72 64 7e 26 13 34 95 41 4b 71 0b 62 c2 b7 5e f4 02 f1 3a 8d 8e ed 88 61 a3 be ce 38 6c be 00 9b 10 9b 31 99 d9 50 bf 51 a5 3e 1c 56 d9 72 7c 36 88 48 fb 62 2b 12 bc d7 da ed 03 af 8f bc dd e2 ec 9e 45 02 91 3f f4 c6 fe 82 a8 5a 7b d8 4d f6 89 1b 0d 20 f1 35 ee ba 91 de 44 93 f7 34 87 c1 16 50 b1 07 d9

........ssh-rsa. ...#.......S.Q(6 .bg..V..7.V.VOs. ^.../...o.+v..a. .D.&}.-...u..@.. J..`(jI.{6....4^ ..cN 1d.....aa.. ...."0..P.h..... .%&if.y.|{.P..J. .@...Q@2.....Y.r h..I...Y.g:..$P) ..f.Q.{.-4...... ...q..W(.@a..s@r 9.QY....j.Z.H... ...,y.z....0..0o .....i"...sO..fq 9...].82..B..D.. ......r;.Wu.I... <.(Do....:1N...J ..fk........An.l .B..H.@b...6.I.. -.M...>....pbRT/ .'....d.S.&..... .x..@.?....G..4, ...C.".e...V.K.S ..$.$.F...7I.... .....ssh-rsa.... t.!^Q...%...b.p. .....j..u..rd~&. 4.AKq.b..^...:.. ..a...8l.....1.. P.Q.>.V.r|6.H.b+ .............E.. ?.....Z{.M.... . 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)

21

= 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 string SSH_MSG_SERVICE_REQUEST 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 string SSH_MSG_SERVICE_ACCEPT ime usluge

Ako, ipak, posluitelj ne eli prihvatit klijentov zahtjev on to ini slanjem sljedee poruke i nakon toga se odspaja:
byte uint32 SSH_MSG_DISCONNECT identifikator razloga prekida

22

string string

opis razloga prekida veze u UTF-8 formatu 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 string string string .... SSH_MSG_USERAUTH_REQUEST korisniko ime ime usluge 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.

23

Tablica 7 : Najee metode autentifikacije

Ime metode publickey password keyboard-interactive hostbased none

Zahtjev obavezno preporueno opcionalno opcionalno 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 name-list boolean SSH_MSG_USERAUTH_FAILURE autentifikacijske metode koje prihvaam 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

24

"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 string string string boolean string string SSH_MSG_USERAUTH_REQUEST korisniko ime ime usluge "publickey" NE ime algoritma javnog kljua 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:

25

byte string string

SSH_MSG_USERAUTH_PK_OK ime algorima iz zahtjeva 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 string string string boolean string string string SSH_MSG_USERAUTH_REQUEST korisniko ime ime usluge "publickey" DA ime algoritma javnog kljua javni klju 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 byte string string string boolean string string identifikator_sjednice SSH_MSG_USERAUTH_REQUEST korisniko ime ime usluge "publickey" DA ime algoritma javnog kljua 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 00000000 00 00 00 00000010 63 6f 6e 00000020 6e 65 Incoming packet type 00000000 00 00 00 00000010 73 73 77 00000020 69 6e 74 Outgoing packet type 00000000 00 00 00 00000010 63 6f 6e 00000020 62 6c 69 00000030 72 73 61 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST) 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d 6e 65 63 74 69 6f 6e 00 00 00 04 6e 6f 51 27 6f 65 50 04 6e 63 00 / 0x33 (SSH2_MSG_USERAUTH_FAILURE) 70 75 62 6c 69 63 6b 65 79 2c 70 61 72 64 2c 6b 65 79 62 6f 61 72 64 2d 72 61 63 74 69 76 65 00 / 0x32 (SSH2_MSG_USERAUTH_REQUEST) 72 6f 6f 74 00 00 00 0e 73 73 68 2d 65 63 74 69 6f 6e 00 00 00 09 70 75 6b 65 79 00 00 00 00 07 73 73 68 2d 00 00 95 00 00 00 07 73 73 68 2d 72 ....tiho....sshconnection....no ne ...'publickey,pa ssword,keyboardinteractive. ....tiho....sshconnection....pu blickey.....sshrsa........ssh-r

26

00000040 73 61 00 00000050 8e ae 54 00000060 74 f3 9e 00000070 4a 30 e9 00000080 d6 92 bb 00000090 ed 12 da 000000a0 f5 79 29 000000b0 18 33 89 000000c0 18 06 bd Incoming packet type 00000000 00 00 00 00000010 00 00 07 00000020 00 00 81 00000030 d5 61 75 00000040 2a 5e 48 00000050 af 0e fa 00000060 f2 b9 eb 00000070 ea a3 17 00000080 22 e6 14 00000090 dc 91 fd 000000a0 2d e9 0f Outgoing packet type 00000000 00 00 00 00000010 63 6f 6e 00000020 62 6c 69 00000030 72 73 61 00000040 73 61 00 00000050 8e ae 54 00000060 74 f3 9e 00000070 4a 30 e9 00000080 d6 92 bb 00000090 ed 12 da 000000a0 f5 79 29 000000b0 18 33 89 000000c0 18 06 bd 000000d0 00 00 00 000000e0 84 94 17 000000f0 85 6b d7 00000100 8c 2c b1 00000110 64 01 38 00000120 d7 17 87 00000130 27 5e cb 00000140 81 4e 14 00000150 18 f7 3e Incoming packet type

00 85 44 68 ed 97 c8 05 bf 60 07 73 00 02 cd 12 0f d0 a5 63 e5 50 04 6e 63 00 00 85 44 68 ed 97 c8 05 bf 07 aa 74 b3 88 f2 88 40 f9 52

00 01 23 00 00 00 81 00 b8 fa 70 5c 47 3c 4d d5 61 75 02 23 8e c1 05 18 9c ba 2a 5e 48 cd 3c 01 9f b3 c4 46 ef af 0e fa 12 d5 8b 55 6c 64 b2 7d f2 b9 eb 0f d4 e1 bd be 12 a6 fe ea a3 17 d0 05 fa 01 a1 e5 ea 97 22 e6 14 a5 75 dc 79 ed 04 06 5d dc 91 fd 63 26 42 2e 21 98 0a 66 2d e9 0f e5 / 0x3c (SSH2_MSG_USERAUTH_PK_OK) 73 73 68 2d 72 73 61 00 00 00 95 73 68 2d 72 73 61 00 00 00 01 23 b8 fa 70 fb 8e ae 54 85 5c 47 3c 23 8e c1 09 74 f3 9e 44 05 18 9c 3c 01 9f d4 4a 30 e9 68 b3 c4 46 d5 8b 55 35 d6 92 bb ed 6c 64 b2 d4 e1 bd cc ed 12 da 97 be 12 a6 05 fa 01 a3 f5 79 29 c8 a1 e5 ea 75 dc 79 c0 18 33 89 05 ed 04 06 26 42 2e 63 18 06 bd bf 21 98 0a

fb 09 d4 35 cc a3 c0 63

sa....#.......p. ..T.\G<M.au.#... t..D....*^H.<... J0.h..F.......U5 ....ld.}........ ................ .y)....."...u.y. .3.....]...c&B.c ....!..f-... ....ssh-rsa..... ...ssh-rsa....#. ......p...T.\G<M .au.#...t..D.... *^H.<...J0.h..F. ......U5....ld.} ................ .........y)..... "...u.y..3.....] ...c&B.c....!..f -... ....tiho....sshconnection....pu blickey.....sshrsa........ssh-r sa....#.......p. ..T.\G<M.au.#... t..D....*^H.<... J0.h..F.......U5 ....ld.}........ ................ .y)....."...u.y. .3.....]...c&B.c ....!..f-....... ....ssh-rsa..... ......2{.e...DO. .k.t.w[.,...k.(. .,.......N....6. d.8.qbRK.S.d.i.. ...../..$....... '^..'7... ...... .N.@...eF+J.3... ..>.......V....

00 00 4d ba ef 7d fe 97 5d 66

/ 0x32 (SSH2_MSG_USERAUTH_REQUEST) 72 6f 6f 74 00 00 00 0e 73 73 68 2d 65 63 74 69 6f 6e 00 00 00 09 70 75 6b 65 79 01 00 00 00 07 73 73 68 2d 00 00 95 00 00 00 07 73 73 68 2d 72 00 01 23 00 00 00 81 00 b8 fa 70 fb 5c 47 3c 4d d5 61 75 02 23 8e c1 09 05 18 9c ba 2a 5e 48 cd 3c 01 9f d4 b3 c4 46 ef af 0e fa 12 d5 8b 55 35 6c 64 b2 7d f2 b9 eb 0f d4 e1 bd cc be 12 a6 fe ea a3 17 d0 05 fa 01 a3 a1 e5 ea 97 22 e6 14 a5 75 dc 79 c0 ed 04 06 5d dc 91 fd 63 26 42 2e 63 21 98 0a 66 2d e9 0f e5 00 00 00 8f 73 73 68 2d 72 73 61 00 00 00 80 0c 16 e0 32 7b 00 65 14 ed d2 44 4f c0 0d 77 5b fa 2c ee a0 d6 6b fc 28 15 10 b2 ed 8b 8f 4e fa 81 91 92 36 98 71 62 52 4b 12 53 98 64 e8 69 cc b8 fb 2f 17 d1 24 a8 10 fa f6 05 8a 7f 27 37 81 d5 2e 20 8e fd 9b e3 d4 b1 12 14 13 65 46 2b 4a e3 33 f1 d4 cd 81 d7 e0 f3 f2 f8 56 f4 92 d2 0d / 0x34 (SSH2_MSG_USERAUTH_SUCCESS)

3.3.3 Autentifikacija pomou lozinke ("password")

Metoda autentifikacije lozinkom je najkoritenija 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 prislukivanjem kanala. Klijent zahtijeva autentifikaciju lozinkom slanjem sljedee poruke:
byte string string string boolean string SSH_MSG_USERAUTH_REQUEST korisniko ime ime usluge "password" NE lozinka

27

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 string string SSH_MSG_USERAUTH_PASSWD_CHANGEREQ poruka o tome kako je lozinka zastarila 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 string string string boolean string string SSH_MSG_USERAUTH_REQUEST korisniko ime ime usluge "password" DA stara lozinka 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 SSH_MSG_USERAUTH_SUCCESS poruku, SSH_MSG_USERAUTH_FAILURE poruku. uspjela, a ako posluitelj nije on alje alje

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 string SSH_MSG_USERAUTH_REQUEST korisniko ime

28

string string string string string string string

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

Digitalni potpis se rauna privatnim kljuem raunala klijenta, a kao poruka se uzima:
string byte string string string string string string string identifikator_sjednice SSH_MSG_USERAUTH_REQUEST korisniko ime ime usluge "hostbased" algoritam javnog kljua javni klju raunala klijenta ime (FQDN) klijentskog raunala 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

29

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 string uint32 uint32 uint32 .... SSH_MSG_CHANNEL_OPEN vrsta kanala broj kanala poiljatelja inicijalna veliina prozora 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 uint32 uint32 uint32 uint32 .... SSH_MSG_CHANNEL_OPEN_CONFIRMATION broj kanala primatelja broj kanala poiljatelja inicijalna veliina prozora 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 uint32 uint32 string string SSH_MSG_CHANNEL_OPEN_FAILURE broj kanala primatelja identifikator razloga odbijanja opis razloga, kodirano UTF-8 kodom identifikator jezika

Razlozi odbijanja mogu biti razliiti, a definirana su etiri standarda identifikatora:

SSH_OPEN_ADMINISTRATIVELY_PROHIBITED

30

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 uint32 uint32 SSH_MSG_CHANNEL_WINDOW_ADJUST broj kanala primatelja 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 uint32 string SSH_MSG_CHANNEL_DATA broj kanala primatelja 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 uint32 uint32 string SSH_MSG_CHANNEL_EXTENDED_DATA broj kanala primatelja tip podataka 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 uint32 SSH_MSG_CHANNEL_EOF broj kanal primatelja

31

Nakon te poruke kanal ostaje i dalje otvoren i mogue je slanje podataka u drugom smjeru. Kanal se u potpunosti zatvara slanjem poruke:
byte uint32 SSH_MSG_CHANNEL_CLOSE 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 string uint32 uint32 uint32 SSH_MSG_CHANNEL_OPEN "session" broj kanala poiljatelja inicijalna veliina prozora 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 uint32 string boolean string uint32 uint32 uint32 uint32 string SSH_MSG_CHANNEL_REQUEST broj kanala primatelja "pty-req" elim odgovor TERM varijabla okoline (npr. xterm) irina u znakovima (npr. 80) visina u znakovima (npr. 24) irina u pikselima (npr. 640) visina u pikselima (npr. 480) op tty kodovi koje terminal razumije

Ako je vrijednost varijable elim odgovor istina, tada posluitelj odgovara. Ako je stvaranje uspjelo on alje:
byte uint32 SSH_MSG_CHANNEL_SUCCESS broj kanala primatelja

32

Ako stvaranje pseudo-terminala nije uspjelo posluitelj alje:

byte uint32 SSH_MSG_CHANNEL_FAILURE broj kanala primatelja

Kada klijent eli zapoeti preusmjeravanje X11 prometa sa posluitelja, on to zatrai slanjem poruke:
byte uint32 string boolean boolean string string uint32 SSH_MSG_CHANNEL_REQUEST broj kanala primatelja "x11-req" elim odgovor samo jedna veza x11 autentifikacijski protokol x11 autentifikacijski cookie x11 broj ekrana

Varijable okoline se prosljeuju porukom:

byte uint32 string boolean string string SSH_MSG_CHANNEL_REQUEST broj kanala primatelja "env" elim odgovor ime varijable 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 uint32 string boolean SSH_MSG_CHANNEL_REQUEST broj kanala primatelja "shell" 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:

33

byte uint32 string boolean string

SSH_MSG_CHANNEL_REQUEST broj kanala primatelja "exec" elim odgovor naredba

Ugraeni podsustavi (scp, sftp) se pokreu se slanjem poruke:

byte uint32 string boolean string SSH_MSG_CHANNEL_REQUEST broj kanala primatelja "subsystem" elim odgovor 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 uint32 string boolean uint32 SSH_MSG_CHANNEL_REQUEST broj kanala primatelja "exit-status" NE 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 string boolean string uint32 SSH_MSG_GLOBAL_REQUEST "tcpip-forward" elim odgovor adresa koju veemo 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:

34

byte string uint32 uint32 uint32 string uint32 string uint32

SSH_MSG_CHANNEL_OPEN "forwarded-tcpip" broj kanala poiljatelja inicijalna veliina prozora maksimalna veliina paketa mrena adresa koja je spojena mreni pristup koji je spojen mrena adresa originalnog zahtjeva 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 string uint32 uint32 uint32 string uint32 string uint32 SSH_MSG_CHANNEL_OPEN "direct-tcpip" broj kanala poiljatelja inicijalna veliina prozora maksimalna veliina paketa adresa na koju se spaja pristup na koji se spaja adresa originalnog zahtjeva pristup originalnog zahtjeva

Nakon toga sav mreni promet preusmjerava se kroz SSH kanal.

35

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 36

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

37

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

38

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.

39

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

40

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

41

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-themiddle). 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.

42

6 Literatura

[1] [2] [3] [4] [5] [6]

[7]

[8] [9] [10] [11]

[12]

[13]

[14]

[15] [16]

Ylnen, T., C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, 2006. Ylnen, T., C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, 2006. Ylnen, T., C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, 2006. Ylnen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, 2006. Lehtinen, S., C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, 2006. Cusack, F., Forssen M., "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", RFC 4256, 2006. Friedl M., Provos N., Simpson W. "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC4419, 2006. Postel, J., J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, 1983. Kantor, B., "BSD Rlogin", RFC 1282, 1991. Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC2104, 1997. US National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-2, 2000. Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", John Wiley and Sons, New York, 1996. 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. 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. Bellare, M., Kohno T., Namprempre C. "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC4344, 2006. Song, X.D., Wagner, D., and X. Tian, "Timing Analysis of Keystrokes and SSH Timing Attacks" , Paper given at 10th USENIX Security Symposium, 2001. 43

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

44

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. Sloj u kojem se koristi
Prijenosni Prijenosni Prijenosni Prijenosni Prijnosni Prijenosni Prijenosni Prijenosni Autentifikacijski Autentifikacijski Autentifikacijski Autentifikacijski Spojni Spojni Spojni Spojni Spojni Spojni Spojni Spojni Spojni Spojni Spojni Spojni Spojni Spojni

Identifikator poruke
SSH_MSG_DISCONNECT SSH_MSG_IGNORE SSH_MSG_UNIMPLEMENTED SSH_MSG_DEBUG SSH_MSG_SERVICE_REQUEST SSH_MSG_SERVICE_ACCEPT SSH_MSG_KEXINIT SSH_MSG_NEWKEYS SSH_MSG_USERAUTH_REQUEST SSH_MSG_USERAUTH_FAILURE SSH_MSG_USERAUTH_SUCCESS SSH_MSG_USERAUTH_BANNER SSH_MSG_GLOBAL_REQUEST SSH_MSG_REQUEST_SUCCESS SSH_MSG_REQUEST_FAILURE SSH_MSG_CHANNEL_OPEN SSH_MSG_CHANNEL_OPEN_CONFIRMATION SSH_MSG_CHANNEL_OPEN_FAILURE SSH_MSG_CHANNEL_WINDOW_ADJUST SSH_MSG_CHANNEL_DATA SSH_MSG_CHANNEL_EXTENDED_DATA SSH_MSG_CHANNEL_EOF SSH_MSG_CHANNEL_CLOSE SSH_MSG_CHANNEL_REQUEST SSH_MSG_CHANNEL_SUCCESS SSH_MSG_CHANNEL_FAILURE 1 2 3 4 5 6

Vrijednost

20 21 50 51 52 53 80 81 82 90 91 92 93 94 95 96 97 98 99 100

45

Saetak
U ovom radu opisan je Secure Shell (SSH) protokol za sigurno udaljeno spajanje i prenoenje podataka izmeu dva raunala preko nesigurne mree. Opisan je nastanak ovog protokola kao i protokoli sline 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.

46