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 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.
2
2 Povijest, razvoj i slini protokoli
3
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
4
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.
5
3 Arhitektura SSH protokola
6
Slika 1 : Arhitektura SSH protokola
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.
8
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.
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
9
klijentskoj strani je program Putty, dok je na posluiteljskoj strani OpenSSH
implementacija:
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
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.
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:
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.
14
Tablica 4 : Definirani MAC algoritmi
15
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
Generator:
2
Generator:
2
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.
16
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)
gdje dss_potpis predstavlja string zapis 160-bitnih brojeva "r" i "s" koji su
rezultat potpisivanja DSS algoritmom.
gdje su "e" i "n" parameri RSA algoritma kodirani kao mpint podaci.
gdje rsa_potpis predstavlja string zapis broja "s" koji se dobije kao rezultat
potpisivanja neke poruke RSA algoritmom.
byte SSH_MSG_KEXINIT
byte[16] cookie (nasumini bajtovi)
17
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)
18
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.............
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.
byte SSH_MSG_KEXDH_REPLY
string javni klju posluitelja i eventualno certifikati(K_S)
mpint parametar f
string potpis posluitelja s
20
00000000 00 00 00 95 00 00 00 07 73 73 68 2d 72 73 61 00 ........ssh-rsa.
00000010 00 00 01 23 00 00 00 81 00 da b9 53 d1 51 28 36 ...#.......S.Q(6
00000020 a2 62 67 bb a4 56 f0 ae 37 86 56 88 56 4f 73 a3 .bg..V..7.V.VOs.
00000030 5e f3 8a 9f 2f 11 86 ee 6f 1a 2b 76 11 83 61 d6 ^.../...o.+v..a.
00000040 7f 44 ee 26 7d aa 2d ef 10 02 75 e0 f2 40 ba aa .D.&}.-...u..@..
00000050 4a a8 df 60 28 6a 49 f6 7b 36 95 1f f8 ab 34 5e J..`(jI.{6....4^
00000060 f2 16 63 4e 20 31 64 ae 94 1e e9 dd 61 61 f3 c3 ..cN 1d.....aa..
00000070 90 9f b3 8e 22 30 f1 08 50 83 68 ca 94 ad 82 d4 ...."0..P.h.....
00000080 d3 25 26 69 66 91 79 ea 7c 7b 03 50 b1 fb 4a be .%&if.y.|{.P..J.
00000090 e3 40 f6 b1 e2 51 40 32 f9 00 00 01 00 59 a2 72 .@...Q@2.....Y.r
000000a0 68 b7 16 49 a3 c9 f1 59 0a 67 3a b6 04 24 50 29 h..I...Y.g:..$P)
000000b0 dc ab 66 85 51 88 7b 1f 2d 34 96 bc ba ed 01 db ..f.Q.{.-4......
000000c0 92 f7 d0 71 14 e8 57 28 f0 40 61 0f 0c 73 40 72 ...q..W(.@a..s@r
000000d0 39 a9 51 59 f8 d7 02 d8 6a ff 5a be 48 95 90 ca 9.QY....j.Z.H...
000000e0 ac 1d f5 2c 79 2e 7a a3 dd 18 da 30 a4 87 30 6f ...,y.z....0..0o
000000f0 bd 05 d7 f6 87 69 22 87 03 e4 73 4f 13 a2 66 71 .....i"...sO..fq
00000100 39 0e 0c 9e 5d a0 38 32 d8 fb 42 90 b8 44 7f 1a 9...].82..B..D..
00000110 92 c6 fe 0b b7 ac 72 3b f7 57 75 aa 49 fa 06 9a ......r;.Wu.I...
00000120 3c ef 28 44 6f 80 97 fd a5 3a 31 4e 0e e0 86 4a <.(Do....:1N...J
00000130 88 cb 66 6b b6 dd 84 e1 df ef 87 a0 41 6e ac 6c ..fk........An.l
00000140 de 42 06 e9 48 13 40 62 b3 d0 f6 36 a6 49 94 0a .B..H.@b...6.I..
00000150 2d 9e 4d ce ef b9 3e 02 c1 90 f3 70 62 52 54 2f -.M...>....pbRT/
00000160 90 27 b3 b2 f4 e2 64 8f 53 81 26 0a ff b0 cd bb .'....d.S.&.....
00000170 ab 78 a3 1f 40 b4 3f aa 1f 98 b9 47 0a c5 34 2c .x..@.?....G..4,
00000180 c3 9a 9b 43 ac 22 f3 65 86 9e 81 56 d3 4b 81 53 ...C.".e...V.K.S
00000190 a1 c6 24 a9 24 82 46 a9 b9 a1 37 49 ff 00 00 00 ..$.$.F...7I....
000001a0 8f 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 80 .....ssh-rsa....
000001b0 74 bb 21 5e 51 c0 88 e7 25 be cf 87 62 c4 70 a1 t.!^Q...%...b.p.
000001c0 0e 11 17 e8 ba 6a fb df 75 d8 e3 72 64 7e 26 13 .....j..u..rd~&.
000001d0 34 95 41 4b 71 0b 62 c2 b7 5e f4 02 f1 3a 8d 8e 4.AKq.b..^...:..
000001e0 ed 88 61 a3 be ce 38 6c be 00 9b 10 9b 31 99 d9 ..a...8l.....1..
000001f0 50 bf 51 a5 3e 1c 56 d9 72 7c 36 88 48 fb 62 2b P.Q.>.V.r|6.H.b+
00000200 12 bc d7 da ed 03 af 8f bc dd e2 ec 9e 45 02 91 .............E..
00000210 3f f4 c6 fe 82 a8 5a 7b d8 4d f6 89 1b 0d 20 f1 ?.....Z{.M.... .
00000220 35 ee ba 91 de 44 93 f7 34 87 c1 16 50 b1 07 d9 5....D..4...P...
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.
byte SSH_MSG_NEWKEYS
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).
byte SSH_MSG_SERVICE_ACCEPT
string ime usluge
byte SSH_MSG_DISCONNECT
uint32 identifikator razloga prekida
22
string opis razloga prekida veze u UTF-8 formatu
string oznaka jezika
byte SSH_MSG_USERAUTH_REQUEST
string korisniko ime
string ime usluge
string naziv metode autentifikacije
.... specifina polja za svaku metodu
23
Tablica 7 : Najee metode autentifikacije
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.
byte SSH_MSG_USERAUTH_SUCCESS
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.
byte SSH_MSG_USERAUTH_REQUEST
string korisniko ime
string ime usluge
string "publickey"
boolean NE
string ime algoritma javnog kljua
string javni klju
25
byte SSH_MSG_USERAUTH_PK_OK
string ime algorima iz zahtjeva
string javni klju iz zahtjeva
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
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
26
00000040 73 61 00 00 00 01 23 00 00 00 81 00 b8 fa 70 fb sa....#.......p.
00000050 8e ae 54 85 5c 47 3c 4d d5 61 75 02 23 8e c1 09 ..T.\G<M.au.#...
00000060 74 f3 9e 44 05 18 9c ba 2a 5e 48 cd 3c 01 9f d4 t..D....*^H.<...
00000070 4a 30 e9 68 b3 c4 46 ef af 0e fa 12 d5 8b 55 35 J0.h..F.......U5
00000080 d6 92 bb ed 6c 64 b2 7d f2 b9 eb 0f d4 e1 bd cc ....ld.}........
00000090 ed 12 da 97 be 12 a6 fe ea a3 17 d0 05 fa 01 a3 ................
000000a0 f5 79 29 c8 a1 e5 ea 97 22 e6 14 a5 75 dc 79 c0 .y)....."...u.y.
000000b0 18 33 89 05 ed 04 06 5d dc 91 fd 63 26 42 2e 63 .3.....]...c&B.c
000000c0 18 06 bd bf 21 98 0a 66 2d e9 0f e5 ....!..f-...
Incoming packet type 60 / 0x3c (SSH2_MSG_USERAUTH_PK_OK)
00000000 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 95 00 ....ssh-rsa.....
00000010 00 00 07 73 73 68 2d 72 73 61 00 00 00 01 23 00 ...ssh-rsa....#.
00000020 00 00 81 00 b8 fa 70 fb 8e ae 54 85 5c 47 3c 4d ......p...T.\G<M
00000030 d5 61 75 02 23 8e c1 09 74 f3 9e 44 05 18 9c ba .au.#...t..D....
00000040 2a 5e 48 cd 3c 01 9f d4 4a 30 e9 68 b3 c4 46 ef *^H.<...J0.h..F.
00000050 af 0e fa 12 d5 8b 55 35 d6 92 bb ed 6c 64 b2 7d ......U5....ld.}
00000060 f2 b9 eb 0f d4 e1 bd cc ed 12 da 97 be 12 a6 fe ................
00000070 ea a3 17 d0 05 fa 01 a3 f5 79 29 c8 a1 e5 ea 97 .........y).....
00000080 22 e6 14 a5 75 dc 79 c0 18 33 89 05 ed 04 06 5d "...u.y..3.....]
00000090 dc 91 fd 63 26 42 2e 63 18 06 bd bf 21 98 0a 66 ...c&B.c....!..f
000000a0 2d e9 0f e5 -...
Outgoing packet type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
00000000 00 00 00 04 72 6f 6f 74 00 00 00 0e 73 73 68 2d ....tiho....ssh-
00000010 63 6f 6e 6e 65 63 74 69 6f 6e 00 00 00 09 70 75 connection....pu
00000020 62 6c 69 63 6b 65 79 01 00 00 00 07 73 73 68 2d blickey.....ssh-
00000030 72 73 61 00 00 00 95 00 00 00 07 73 73 68 2d 72 rsa........ssh-r
00000040 73 61 00 00 00 01 23 00 00 00 81 00 b8 fa 70 fb sa....#.......p.
00000050 8e ae 54 85 5c 47 3c 4d d5 61 75 02 23 8e c1 09 ..T.\G<M.au.#...
00000060 74 f3 9e 44 05 18 9c ba 2a 5e 48 cd 3c 01 9f d4 t..D....*^H.<...
00000070 4a 30 e9 68 b3 c4 46 ef af 0e fa 12 d5 8b 55 35 J0.h..F.......U5
00000080 d6 92 bb ed 6c 64 b2 7d f2 b9 eb 0f d4 e1 bd cc ....ld.}........
00000090 ed 12 da 97 be 12 a6 fe ea a3 17 d0 05 fa 01 a3 ................
000000a0 f5 79 29 c8 a1 e5 ea 97 22 e6 14 a5 75 dc 79 c0 .y)....."...u.y.
000000b0 18 33 89 05 ed 04 06 5d dc 91 fd 63 26 42 2e 63 .3.....]...c&B.c
000000c0 18 06 bd bf 21 98 0a 66 2d e9 0f e5 00 00 00 8f ....!..f-.......
000000d0 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 80 0c ....ssh-rsa.....
000000e0 84 94 17 aa 16 e0 32 7b 00 65 14 ed d2 44 4f c0 ......2{.e...DO.
000000f0 85 6b d7 74 0d 77 5b fa 2c ee a0 d6 6b fc 28 15 .k.t.w[.,...k.(.
00000100 8c 2c b1 b3 10 b2 ed 8b 8f 4e fa 81 91 92 36 98 .,.......N....6.
00000110 64 01 38 88 71 62 52 4b 12 53 98 64 e8 69 cc b8 d.8.qbRK.S.d.i..
00000120 d7 17 87 f2 fb 2f 17 d1 24 a8 10 fa f6 05 8a 7f ...../..$.......
00000130 27 5e cb 88 27 37 81 d5 2e 20 8e fd 9b e3 d4 b1 '^..'7... ......
00000140 81 4e 14 40 12 14 13 65 46 2b 4a e3 33 f1 d4 cd .N.@...eF+J.3...
00000150 18 f7 3e f9 81 d7 e0 f3 f2 f8 56 f4 92 d2 0d ..>.......V....
Incoming packet type 52 / 0x34 (SSH2_MSG_USERAUTH_SUCCESS)
byte SSH_MSG_USERAUTH_REQUEST
string korisniko ime
string ime usluge
string "password"
boolean NE
string 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.
byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
string poruka o tome kako je lozinka zastarila
string identifikacijski kod jezika poruke
byte SSH_MSG_USERAUTH_REQUEST
string korisniko ime
string ime usluge
string "password"
boolean DA
string stara lozinka
string nova lozinka
byte SSH_MSG_USERAUTH_REQUEST
string korisniko ime
28
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
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
29
suprotna strana nema dovoljno velik prozor sve dok ona ne dojavi da
poveava veliinu prijemnog prozora.
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
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
byte SSH_MSG_CHANNEL_OPEN_FAILURE
uint32 broj kanala primatelja
uint32 identifikator razloga odbijanja
string opis razloga, kodirano UTF-8 kodom
string identifikator jezika
30
SSH_OPEN_CONNECT_FAILED
SSH_OPEN_UNKNOWN_CHANNEL_TYPE
SSH_OPEN_RESOURCE_SHORTAGE
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
Kada neka strana vie ne eli slati podatke, ona to javlja slanjem poruke:
byte SSH_MSG_CHANNEL_EOF
uint32 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 SSH_MSG_CHANNEL_CLOSE
uint32 broj kanala primatelja
byte SSH_MSG_CHANNEL_OPEN
string "session"
uint32 broj kanala poiljatelja
uint32 inicijalna veliina prozora
uint32 maksimalna veliina paketa
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
byte SSH_MSG_CHANNEL_SUCCESS
uint32 broj kanala primatelja
32
Ako stvaranje pseudo-terminala nije uspjelo posluitelj alje:
byte SSH_MSG_CHANNEL_FAILURE
uint32 broj kanala primatelja
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
byte SSH_MSG_CHANNEL_REQUEST
uint32 broj kanala primatelja
string "env"
boolean elim odgovor
string ime varijable
string vrijednost varijable
byte SSH_MSG_CHANNEL_REQUEST
uint32 broj kanala primatelja
string "shell"
boolean elim odgovor
33
byte SSH_MSG_CHANNEL_REQUEST
uint32 broj kanala primatelja
string "exec"
boolean elim odgovor
string naredba
byte SSH_MSG_CHANNEL_REQUEST
uint32 broj kanala primatelja
string "subsystem"
boolean elim odgovor
string ime podsustava
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
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
34
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
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
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.
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.
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.
38
DSS i RSA privatni kljuevi servera. Javni kljuevi i digitalni potpisi se
takoer prikazuju korisniku i on ih moe u svakom trenutku promijeniti.
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.
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.
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.
42
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.
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
Sloj u kojem
Identifikator poruke Vrijednost
se koristi
SSH_MSG_DISCONNECT 1 Prijenosni
SSH_MSG_IGNORE 2 Prijenosni
SSH_MSG_UNIMPLEMENTED 3 Prijenosni
SSH_MSG_DEBUG 4 Prijenosni
SSH_MSG_SERVICE_REQUEST 5 Prijnosni
SSH_MSG_SERVICE_ACCEPT 6 Prijenosni
SSH_MSG_KEXINIT 20 Prijenosni
SSH_MSG_NEWKEYS 21 Prijenosni
SSH_MSG_USERAUTH_REQUEST 50 Autentifikacijski
SSH_MSG_USERAUTH_FAILURE 51 Autentifikacijski
SSH_MSG_USERAUTH_SUCCESS 52 Autentifikacijski
SSH_MSG_USERAUTH_BANNER 53 Autentifikacijski
SSH_MSG_GLOBAL_REQUEST 80 Spojni
SSH_MSG_REQUEST_SUCCESS 81 Spojni
SSH_MSG_REQUEST_FAILURE 82 Spojni
SSH_MSG_CHANNEL_OPEN 90 Spojni
SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 Spojni
SSH_MSG_CHANNEL_OPEN_FAILURE 92 Spojni
SSH_MSG_CHANNEL_WINDOW_ADJUST 93 Spojni
SSH_MSG_CHANNEL_DATA 94 Spojni
SSH_MSG_CHANNEL_EXTENDED_DATA 95 Spojni
SSH_MSG_CHANNEL_EOF 96 Spojni
SSH_MSG_CHANNEL_CLOSE 97 Spojni
SSH_MSG_CHANNEL_REQUEST 98 Spojni
SSH_MSG_CHANNEL_SUCCESS 99 Spojni
SSH_MSG_CHANNEL_FAILURE 100 Spojni
45
Saetak
46