Van az a pillanat - kinek előbb, kinek később - amikor egyszercsak magábaszippantja a szerver. Mert kénytelen belenézni, vagy mert csak úgy érdeklődik, hogy mi is történik ott. Ilyenkor szokott elhangozni az a bizonyos felvetés:
- Akkor küld át a kulcsodat és betesszük.
És ilyenkor ülünk bután egy percig, már ha nem vagynk benne nap mint nap a CGI zrééében, hogy akkor mi a tüdő legyen.
De miért is SSH - SecureSHell?
Ha robosztus és üzletileg fontos rendszereket fejelsztünk, üzemeltetük, akkor - nem bull-shit - üzleti kockázatot jelent a szervereink és szoftvereint rendelkezésreállása, sérthetetlensége, azok védelme. Igyekszünk megvédeni a cuccainkat az illetéktelenektől. Ennek egyik kézenfekvő módja, hogy elhagyjuk a standard FTP vagy sima TELNET alapú hozzáféréseket, becsukjuk a kritikus rendszereket, a felesleges és nehezen védhető kapukat. De valahogy kell beszélgetni a szerverrel. Erre használjuk az SSH protokollt, mely segít biztonságban tudni a kommunikációt a kliens és a szerver között.
Az SSH (szolgáltatás és egyben protokoll) publikus-kulcs alapú titkosítást használ, melyhez szükséges kulcspárt bárki elkészítheti magának. Egyrészt a publikus kulcsot melyet a rendszergazdák szoktak elkérni azért, hogy azt elhelyezzék a megfelelő szerveren. Másrészt a privát kulcsot - aminek nincs a végén .pub felirat, - biztonságba kell helyezni azon a gépen, melyről majd be fogunk jelentkezni.
Bevallom, halogattam soká a kulcsgenerálást, nem véletlenül. Szinte rituális a jelentősége eme tevékenységnek. Bizonyos szempontból olyan hogy megvan a szolgálatba helyezhetőség lehetősége. És az nem mindig tud jó lenni.
De azt vallom, jobb ha van és nem kell, mint ha nincs mikor kéne!
SSH keygen
És Én is néztem bambán, a fenti kérdésre, igaz csak 10 másodpercig. Aztán megérdeztem Kövit, hogy mivel is generálom a kulcsom OSX alatt - mert persze, hogy a Windows világban ott az univerzál Putty, de szerencsére nincs Windows.
Hát ez mint kiderült pofon egyszerű. Mindössze nyitni kell egy terminált és bepötyögni:
ssh-keygen -t RSA
Csupán azért RSA, mert leginkább ez a használatos. A program megfut és megkérdezi, hogy mi is legyen a keyfile neve. Ez esetben jobb egy olyan filenevet adni, ami alapján majd a remote rendszergazda azonosítani tud minket, mint forrást. Persze a keygen kiírja azt is, hogy defaultból hová is kéne tenni ezeket a file-okat - az esetek nagy százalélában csak meggenerálja a kulcsokat abba a könyvtárba ahonan éppen futtatjuk.
A generáltor még bekér egy jelszót is, amivel a keyfile-t tudjuk védeni. Ha elsőként csinálunk ilyet, inkább ne adjunk meg semmit, csak próbáljuk beüzemelni a környezetet.
Két file jön létre:
lenikulcsa
lenikulcsa.pub
Értelem szerűen az utóbbi a publikus kulcsunk - azaz amelyet majd át kell lőni a rendzergazninak. Az előbbi pedig a mi privát kulcsunk, amit viszont érdemes jó biztonságba helyezni. (chmod 600)
Igen ám, de hová is kell tenni a kulcsot?
mint a keygen is mondja, és ezze egybehangzóan Kövi is, a privát kulcsot el kell helyezni az ssh számára megfelelő könyvtárba. Ez pedig az alábbi:
~/.ssh/
Ha ide berakjuk a kulcspot akkor remek. Persze lehet szofisztikát az ember és berakja a ~/.ssh/id_rsa alá, de akkor garantáltan ugat majd az SSH, hogy úr isten nem álltítottad be megfelelően a jogosultságokat. Ehhez jo tolni egy chmod 600 -t a kulcs filera.
És akkor várunk míg meg nem jön a visszaigazolás, hogy az elküldött .pub kulcs a helyére került.
Küzd és bízva bízzál.
Mindig figyelni kell arra amit a rendszergazik mondanak. Minden egyes szóra! Alapesetben a helyzet az, hogy a kulcspár valójában géphez és emberhez - azaz a gépen a userhez - tartozik. Amikor defaultból nekiduráljuk magunkat, hogy akkor ssh leniszerver.com akkor érhetnek nagy meglepetések. Erre az esetre jó ha megjegyezzük - amit én is Kövitől lestem el - a verbose mód kapcsolóját.
ssh -v leniszerver.com
Ilyenkor az SSH szépen mutatja a konzoon a folyamatokat. Az esetleges probléma okat. Gyorsan fény derülhet arra, hogy még sincs helyén a kulcs, vagy arra, hogy rossz userrel próbálkozunk.
Defaultból az SSH lepattintja a környezetből, hogy ki is a user a munkamentben. Ha azonban ez a user nem létezik a remote host-on akkor lehet nekünk bármilyen kulcsunk gondban vagyunk. Ugyanakkor a rendszergazda szokta mondani, hogy akkor most Pityipalko-ként kell bejelentkezni. Na ez amit én is elfelejtettem.
ssh -v pityipalko@leniszerver.com
Ezzel lehet is garázdálkoni. Ugyanakkor innentől csak óvatosan. Ha véletlen rossz felé nyúlnk, akár a full rendszert beleküldhetük a dev null-ba!
Geek Update
Kövi már minap mondta, hogy Ő személy szerint konfigot szokott írni, mert ki tudja, hogy melyik géphez melyik kulcs és különben is. Beláttam tök igaza van. Főleg miután megírta a konfigot, amit szintén a fent említett könyvtárba kell helyezni config név alatt.
Host leniserver
HostName leniserver.com
IdentifyFile ~/.ssh/leni
User pityipalko
ForwardAgent yes
Ha ezzel megvagyunk akkor már kezdődhet is rutinból a garázdálkodás. De tényleg, csak óvatosan.
Linkek: SSH config Unprotect WIKI
