Mindig azt szoktam mondogatni kezdőbb rendszergazdáknak, hogy ne adjanak, vagyis csak végső megoldásként adjanak SSH hozzáférést a rendszereikhez, és csakis olyan embernek akikben egyrészt 100%-ban megbíznak, másrészt az SSH hozzáférés egész időtartama alatt a kiskutyájukat kilógatják az Empire States Building legfelső emeletéről, és az első gyanús mozdulatra száttárják a kezüket. Most leírom azt is, hogy miért van ez. Később egyszerűbb lesz minden egyes magyarázat helyett egy linket dobni ide. :-)

Az SSH nem gonosz, de két okból igen veszélyes:

1. Shell szintű hozzáférés, ami mindenképpen magasabb minőség egy alkalmazás-szintű (pl. webes adminisztrációs felület) hozzáféréshez. Lehetnek hibák, amikről még nem tudunk és kihasználhatók privilégium-emelésre vagy (akár nem szándékos) rombolásra.
2. Az SSH egy irgalmatlanul rugalmas protokoll, amely képes más protokollokat a testébe ágyazni (tunneling). Ezt úgy kell érteni, hogy mondjuk a tűzfalra adott egyetlen SSH hozzáféréssel kiadtuk az összes belső gépünket mondjuk egy kiadós szkennelésre. Ha mi építünk ki egy ilyen tunnelt, mert mondjuk el kell érni egy belső Intranet szervert HTTP-n de ez (nyilván) nincs engedélyezve a tűzfalon, azaz nincs port forward befelé, akkor ez a featúra hasznos, ha más csinálja ugyanezt a tudtunk nélkül, az inkább kínos.

Szóval első ötletként jónak tűnik adni egy SSH hozzáférést, hiszen biztonságos. Naja, de ebből adódóan nehezen is karbantartható, figyelhető, hiszen a titkosított forgalmat nekünk is nehéz kontrollálni. Néhány lehetőség:

Fájl transzfer

Talán a legtriviálisabb, hogy az SSH használható fájlok átvitelére is. Ilyen módon az SSH hozzáféréssel rendelkező ember jogosultsága erejéig tud fájlokat fel-le másolgatni a szerverünkre.

X11 forwarding

Ha a szerveren valamilyen rendkívüli körülmény következtében van X, akkor jó tudni, hogy az X11 DISPLAY-t át lehet irányítani SSH-n keresztül. Ha ez működik (SSH szerver és kliens beállítás is kell hozzá), akkor a távoli terminálban elindított program a kliens gépre küldi át a képét, azaz a grafikus ablak hirtelen megjelenik a kliensen, pedig valójában a szerveren dolgozunk. Jó trükk, jó lehetőség hackokra.

Traffic Forwarding

Ugyan nem tudom, hogy az előző folyományaként, továbbfejlesztéseként működik, de az SSH képes arra, hogy egy tetszőleges forgalmat befedjen a titkosított kapcsolatba. Úgy kell ezt elképzelni, hogy tegyük fel az alap 22-es portot használva bejelentkezünk a szerverre (maradjunk előző példánknál, és legyen ez egy tűzfal); egyúttal elindítunk a kliensen egy kis háttérben futó szolgáltatást, amely általunk meghatározott porton figyel a localhost (Lo) interfészen. Ha csatlakozunk rá, akkor a forgalmat elkapja, belevágja a kiépült SSH csatornába, a túloldalon kiesik, és ott továbbküldődik a szintén általunk meghatározott gép meghatározott portjára. Magyarul itt három gép dolgozik, a kliens, a tűzfal (ami csak egy továbbító, forwarder), és a távoli szerver, amire ténylegesen csatlakozunk ("Hé, SSH, titkosítsd a lokális gépem X portjára érkező forgalmat, hogy eljusson Y gép Z portjára, és ehhez használd a Q ssh-szervert!").

Vegyünk egy példát! Mondjuk sima POP3 elérés működik bent egy cégnél, hogy a belső szerverről le tudják tölteni az emberek a leveleiket. Tudjuk, hogy a POP3 nem igazán biztonságos, hiszen lehallgathhatók a mailek, de kis cégen belül még elmegy. Főnökünk kiadja a parancsot, hogy mostantól 0 - 24 órában kell figyelnünk a levelesládánkat. Nyilván nagyon rossz ötlet a POP3-at engedélyezni kívülről, még akkor is, ha legalább minimális biztonsági tudatosságról téve bizonyságot, mondjuk a 9999-es portot forwardoljuk be a tűzfalon a belső levelezőszerver 110-es portjára. Ez ugye csak addig segít, amíg meg nem találják a nyitott portot, aztán jöhet mindenféle brute force próbálkozás, relayként való trükközés, a levelezőszerver gyengeségeinek kihasználása stb.

Legtutibb tehát az lenne, ha csak akkor épülne ki ez a kapcsolat ha ténylegesen használjuk is, és természetesen akkor is legyen titkosított. Ekkor azt csináljuk, hogy (feltéve hogy a 22-es port engedélyezve van a tűzfalon; persze tudom hogy ez is ad teret brute force próbálkozásnak de például ezek visszafoghatók egy iptables-szel ha beállítjuk hogy egy hostról egy percen belül csak 2 kapcsolat jöhet a többit eldobálja. Meg persze ott a jó öreg knocking technológia. Ez két nagyon más téma, nem mennék bele); szóval azt csináljuk, hogy benyomulunk SSH-val, majd a lokális gép 110-es portját beirányítjuk a kihúzott titkosított csatornába, az a másik oldalon kiesve pedig megy a szerverünk 110-es portjára és minden működik szépen.

Az egyetlen fura dolog nyilván az, hogy a kiépített forwarding esetén úgy tűnik, mintha a kliens, azaz a saját gépünk lenne a szerver, mert a levelezőprogramban is localhost:110-et állítunk be a levél letöltéshez, de ez csak technikai kérdés. Az előbb leírtak megvalósítása:

ssh -L110:192.168.1.10:110 tuzfal.cegem.hu


Ez elég egyszerű, nem? A 192.168.1.10-et természetesen a belső szerver (belső) címére kell lecserélni, a két 110-es érték közül az első az, hogy a lokális gépen hányas porton figyeljen, a másik értelemszerűen az elérni kívánt gép portja. Ha több levelezőszervert akarunk elérni, akkor lehet több csatornát is kiépíteni, de egy csatorna lefoglal a lokál gépen egy portot, tehát a második csatornát már pl. a 111-es portra kell tennünk és a levelezőprogramot is így kell beállítani. Természetesen a parancs kiadása után a szokott módon be kell jelentkeznünk. Azt hiszem, túlragoztam. Még annyit, hogy a kapcsolatot állandóvá lehet tenni a konfig fájlunkban (normál esetben ~/.ssh/config), és akkor egyszerűen csak ssh tuzfal.cegem.hu, a csatornák pedig egyből kiépülnek. Ezt így lehet:


LocalForward 110 192.168.1.10:110
LocalForward 111 192.168.1.11:110

A konfigba én még nem írtam ilyet, nem tudom, hogy ez most ténylegesen működik-e...

Figyelem! Fontos dolgok, amiket érdemes tudni: Ha a kliens gépünket többen használják, akkor a megnyitott 110-es portot mindenki fogja látni, tudja használni! Ez persze jó dolog is lehet, de tudjunk róla. A másik, hogy az 1024 alatti portok megnyitásához root jog kell, ezt ne felejtsük! Ha nem akarjuk root joggal csinálni, akkor a -L110 helyett -L9110-et is adhatunk.

És persze a legfontosabb, amiért tépem az ujjaimat: Bármelyik SSH-joggal rendelkező felhasználó ki tudja forwardolni ezzel a módszerrel egy belső gépünk belső portját egy másik gépen keresztül akár az Internetre is!!! (Készít kívülről egy tunnelt, majd a lokális portot a -g kapcsoló segítségével elérhetővé teszi más távoli hozzáférőknek. Tehát tud készíteni egy gonoszceg.com-ot, ahol megcsinálja az előbb említett SSH sort, kiegészítve a -g paraméterrel; ekkor a gonoszceg.com 110-es portjára csatlakozók bekerülnek egy titkosított csatornába, ami átviszi őket a tuzfal.cegem.com-on keresztül szépen a belső hálózati mailszerver 110-es portjára. A vicces az, hogy ezek után a kliensek és a gonoszceg.com közötti forgalom megint nem titkosított! Hiszen csak a gonoszceg.com és a tuzfal.cegem.com közötti kapcsolat van letitkosítva.

Tehát ha nem akarunk ilyen trükköket, akkor a /etc/ssh/sshd_config fájlbe leszünk szíves beírni:

AllowTcpForwarding no

Távoli parancsfuttatás

Csak egy-két rövid példa a távoli parancsfuttatásra. Azt gondolnánk, hogy az SSH-val bejelentkező felhasználó, még ha ilyen sok joga van is, egy interaktív shellben gépelve nem sokra mehet. Ez egyrészt azért is tévedés, mert akár egy kijelölt szövegfájlt is belemásolhat a termináljába, másrészt szkriptet is tud készíteni, amely kis ügyességgel automatikusan igen sokat megtehet. Példák:

bagoj@tarantula:~$ ssh user@host w
bagoj@tarantula:~$ cat myfile | ssh user@host lpr
bagoj@tarantula:~$ tar -cf - source_dir | ssh user@desktop 'cat > dest.tar'
bagoj@tarantula:~$ for i in "server1 server2 server3"; do echo `ssh $i "uptime"`; done


•  Az első bejelentkezik a távoli host nevű gépre, lefuttat egy "who" parancsot és rögtön kilép.
• A második arra mutat példát, hogy a pipe-ok is működnek; itt a cat-tal kiírjuk egy fájlunk tartalmát és beleirányítjuk a távoli hoston a nyomtatósorba, ahol szépen kinyomtatódik.
• Harmadikként ismét egy pipe-os példa; a tar-ral összecsomagolt fájl nem saját gépünkön, hanem egy távoli könyvtárban fog landolni.
• A negyediknél már szkriptezünk; bejelentkezünk sorban a server1, server2, server3 ... gépekre és lefuttatjuk az uptime parancsot, ami infót ad a gépek pillanatnyi terheltségéről és arról hogy mikot bootoltak utoljára. Az eredmény egy komolyabb perl szkripttel értelemszerűen fel is dolgozható.

Gondolhatnánk, hogy nade a bejelentkezéshez jelszó kell, tehát utóbbi példánkban 3-szor kellene beírni a jelszót. "Természetesen" ez is simán kitrükközhető - lássuk az azonosítás részt!

Azonosítás

Elég sokféle azonosítás lehetséges az SSH-ban; számunkra most a jelszavas és a kulcsos bejelentkezés az érdekes. Alapból ugyebár a jelszópromptos azonosítás dukál, ezen sokan nem is lépnek túl. De miért ne legyünk lusták, ha a kulcsos titkosítás még biztonságosabb (kell a bejelentkezéshez jelszó ÉS egy privát kulcs) és megtehetjük, hogy nem kell jelszót gépelni (azaz mégsem kell jelszó CSAK a privát kulcs)?

Azt nem várhatjátok hogy most a nyilvános kulcsú titkosításra kitérjek; szintén nagy téma, persze ha igazán szívhez szólóan könyörögtök, akkor szívesen firkálok róla. :-))) Röviden: A privát kulcs a saját gépünkön van, a publikus párja a szerveren, ahová bejelentkezünk. Egymás nélkül nem érnek fabatkát sem, ennek matematikai alapján már 30 éve próbálnak hibát találni, egyelőre hiába. A módszer lépései:

1. Egy ilyen kulcspárt le tudunk generálni az Openssl segítségével, a privát kulcsunkhoz való hozzáférést pedig jelszóhoz köthetjük. Ha itt megadunk jelszót, akkor ezt kell megadnunk majd a kapcsolódáskor. Ha nem adunk meg semmit, akkor pedig jelszó nélkül, mégis biztonságos azonosítással tudunk belépni (jelszó nem utazik a hálózaton, egyértelműen azonosítva van a kliens gépünk stb). Természetesen ha a privát kulcsot lenyúlják, az ugyanakkora szívás, mintha a jelszót nyúlták volna le... Csináljuk hát meg (jelszó helyett csak entert ütöttem):
   bagoj@tarantula:~ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/bagoj/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/bagoj/.ssh/id_rsa.
Your public key has been saved in /home/bagoj/.ssh/id_rsa.pub.
2. A publikus kulcsot ezek után szét kell másolni mindazon szerverekre, ahová ezzel a módszerrel jelentkeznénk be. A publikus kulcs szolgál az elkódolásra, a privát a dekódolásra, ez utóbbira kell nagyon ügyelnünk. Az algoritmus biztosítja, hogy csak a mi privát kulcsunkkal lehet kikódolni a mi publikus kulcsunkkal titkosított üzenetet. A publikus kulcs helye a távoli szerveren a saját könyvtárunkban a ~/.ssh/authorized_keys fájl, ha több kulcsunk van akkor ezeket egymás után másoljuk. Hogy melyik kulcs a publikus, mindenkinek feladom házi feladatként... :-)
   bagoj@tarantula:~$ scp /home/bagoj/.ssh/id_rsa.pub tuzfal.cegem.com:.ssh/authorized_keys

bagoj@tuzfal.cegem.com's password:
id_rsa.pub                                    100%  395     0.4KB/s   00:00
3. Ezután ha egy ssh tuzfal.cegem.com-ot kiadunk, jelszó nélkül ott vagyunk. Jó, mi? Ugyanezt bárki megteheti, akinek SSH hozzáférést adtunk. 

Remélem, nem lomboztam le senkit ezzel, hiszen ez csak a biztonságot szolgálja; de természetesen használható arra is, hogy jelszó megadása nélkül automatikusan parancsokat futtassunk. Természetesen mindenkit arra bátorítok, hogy védje privát kulcsát jelszóval, amely egyébként 3DES (szimmetrikus) kódolással véd.

Hab a tortán - Azonosítási Ügynök (Authentication Agent)

Ez a kis fejezet kivételesen nem arról szól, hogy mit tehetnek meg mások a szerverünkkel, hanem hogy mit tehetünk mi saját kényelmünk érdekében. Kapcsolódva az előzőkhöz, ha jelszóval védjük privát kulcsunkat, akkor ismét csak meg kell adni minden bejelentkezéskor a jelszót. De használhatjuk az ssh-agent nevű programocskát is, amely az első alkalommal elteszi a memóriába a begépelt jelszavunkat, így nem kell többször megadnunk. Csak a tisztánlátás kedvéért: nem a távoli géphez szükséges jelszavunkat tárolja el, mert azt nem is használjuk, hiszen kulcs van helyette; hanem a privát kulcsunk kinyitásához (bármekkora képzavar is ez) szükséges jelszót. Ha olyan a disztibúciónk, akkor az X11 elindításakor elindul az ssh-agent is, mint például Ubuntu alatt, így azt külön nem kell futtatnunk. Elég hát kiadni az

ssh-add

parancsot, és a saját kulcsunk rákerül erre a "kulcskarikára". Ezt bármikor lekérdezhetjük az ssh-add -L parancs segítségével.

A legnagyobb vicc persze nem ez, hanem hogy ha bejelentkezünk egy szerverre, és onnan szintén ugyanazzal a kulccsal mennénk tovább, akkor a józan paraszti észnek adódik, hogy ott is futnia kellene ennek az ssh-agentnek. Nos, a helyzet ennél egyszerűbb: Az ssh tudja ezt a tárolt jelszót is továbbítani a titkosított csatornán. Ilyen módon a távoli gépről egy újabb gépre belépés esetén sem fog még egyszer jelszót kérni, tényleg egyszer kell csak megadnunk a kulcs jelszót, az ssh-add parancs futtatásakor. Ha nem mi vagyunk a távoli gép adminisztrátorai, akkor én egyáltalán nem javaslom ennek a használatát! Hála az égnek, ez nem automatikus! Ahhoz, hogy ez működjön, a -A paramétert kell használni az ssh parancs közben, vagy a ~/.ssh/config fájlunkba a kliensen be kell írni a

ForwardAgent     yes

paramétert.

Biztonságos SSH-szerver beállítások

Azt már tudjuk, hogy mit lehet megtenni egy egyszerű SSH hozzáféréssel. Tegyük fel, hogy mi szeretnénk ez ellen védekezni! Mit kell a szerverünkön beállítani, hogy senki ne csúnyálkodhasson? Szerkesszük a /etc/ssh/sshd_config fájlt:

# Tudom nem sokat ved, de megis, ne a standard porton futtassuk
Port 2222
# Csak 2-es protokollt használjunk, ha megtehetjuk (nincs nagyon osdi UNIXunk)
Protocol 2
# Nem kene engedni, hogy a root tavolrol bejelentkezzen. Jelentkezzunk be
# sajat nevunk alatt, aztan su vagy sudo
PermitRootLogin no
# X11 forwarding nem kell, foleg ha nincs is X11. Desktop
# gepen szukseg lehet ra!!!!
X11Forwarding no
# Ha no-ra allitjuk, nem fog menni a kulcsos bejelentkezes. Szerintem megis
# hasznosabb, mint veszelyes, ezert megengedem
PubkeyAuthentication yes
# Itt a traffic forwardingban is leírt rész. A manual szerint
# ez sem er tul sokat, hiszen shell hozzaferessel barki
# telepitheti sajat forwarderet, de azert az mar nem olyan
# trivialis
AllowTcpForwarding noMit tegyünk, ha mi magunk akarunk mondjuk X11 forwardot, másoknak viszont nem akarjuk megengedni? Háttt ittt a nagyon nagyszerű Match lehetőség, amely képes felhasználó, csoport, host vagy cím alapján eltéríteni a globális beállításokat. Arra figyeljünk, hogy a Match után következő sorok az adott szűrt csapatra lesznek érvényesek mindaddig, amíg egy újabb Match vagy a fájl vége nem jön. Tehát globális szekció előre, Match-ek a végére!

Tegyük fel, hogy szegény jó Bagojtól megvonjuk a jogot az SCP-re, és csak egyetlen belső szerver traffic forwardját hagyjuk meg neki. Ekkor a konfig fájl végére ezt illesszük be:

Match User bagoj
PermitOpen bagojgepe:22
ForceCommand /bin/bashEbben az esetben Bagoj Uraság pofára esik, ha SCP-zni akar, mert azt nem lehet bash-sel, tehát ott fog várakozni a sor és a másolás nem fog végbemenni. A forward pedig csak Bagoj saját gépére lehetséges (a fenébe, egy újabb SSH jogot kapott, és ez a fickó dörzsölt, jó lesz vele vigyázni... :-))