SSH azonosítás nyilvános kulcsal, jelszó nélkül

 ( tovis | 2011. április 11., hétfő - 18:24 )

Egy, már ugyanebben a fórumban indított kérdés tovább gördült. http://hup.hu/node/101021
Szépen be lehet jelentkezni, működik a "reverse tunnel". Most ezt automatizálni kell, vagyis meg kell valósítani a jelszónélküli login -t.
Találtam, parancssori megoldásokat, mint az sshpass vagy az expect nevű kis programok, amivel a parancssorba beilleszthetőek a jelszavak. Mindenütt megjegyzik, hogy a helyes megoldás nyilvános kulcsok használata. Próbálom ezt a dolgot értelmezni, alkalmazni de van néhány homályos pont.
1. Ugye jól értem, hogy a nyilvános kulcsok generálásakor ahhoz, hogy ne kelljen jelszó, azt üresen kell hagyni - az interaktív generálás során "enter" és kész?
2. Esetenként, egyidejűleg akár egy tucat ilyen igény is lehet, ugyanazzal a felhasználóval, különböző gépekről. Le tud ez a mechanizmus ilyet kezelni? Vagyis több különféle gépről, egyidejűleg, azonos felhasználó, különféle egyedi nyilvános kulccsal?

A port kiosztást még nem tudom pontosan, hogy oldom meg, de ez nem tűnik annyira rázósnak - akár explicite beállíthatom van elég szabad port :)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

1. igen
2. igen. a ~/.ssh/authorized_keys file-ba tetszőleges számú publikus kulcsot felvehetsz, az azokhoz tartozó privát kulcsok bármelyikével be lehet jelentkezni.

Kösz! Kicsit nyugodtabb vagyok.
Szerinted a nyilvános kulcsok hordozhatóak? Mondjuk csinálok egy teljes másolatot a rendszerről és felteszem egy azonos vagy nagyon hasonló vasra akkor mi lesz ezekkel a kulcsokkal? Újra kell generálni, vagy sem?

* Én egy indián vagyok. Minden indián hazudik.

a kulcs maga hordozható, de a gép azonosításával gondok lehetnek, ezért az első bejelentkezést lehet, hogy személyesen kellene csinálnod.

No problemo, ha nem vagy paranoiás.
ssh ... -o StrictHostKeyChecking=no
Ezt elhelyezteted a lentebb említett ~/.ssh/config-ban is, ha szükség van rá.

BOCS, amit írtam nagy butaság volt.

* Én egy indián vagyok. Minden indián hazudik.

1. Igen.
2. Miért kell több kulcs ? Ugyan az a kulcs mindenhol... ? Nem ismerem az előzményeket... bocsi az értetlenségért.

3. Szívesen segítek ha kell, ez igen ismerős dolog számomra... na meg gondolom sok ember számára, de sokan nem érnek rá... :)

Az expect-et, meg minden olyat, ami a jelszó begépelését szimulálja, szerintem felejtsd el. Én most hármat tudok mondani a meglévő kulcspár jelszó (passphrase) nélküli használatára, meg egyet a generálására / telepítésére.

I.

A kulcspár a kliens gépen generálandó (ssh-keygen -t rsa -b 4096). A pár két fel külön file-okba kerül (alapból ~/.ssh/id_rsa és ~/.ssh/id_rsa.pub). A kulcspár publikus felét (.pub), ami egyetlen sor, hozzá kell fűzni a szerveren található ~/.ssh/authorized_keys file-hoz. Erre újabban tartanak kliens oldalon utility-t (ssh-copy-id), de kézzel sem nehéz megcsinálni (ssh user@server 'umask 077 && mkdir -pv .ssh && cat >>.ssh/authorized_keys' < ~/.ssh/id_rsa.pub). A szerver oldalon a jogosultságokra ügyelni kell, mert ha az sshd nem olyat lát, ami tetszik neki, akkor nem veszi figyelembe az authorized_keys-t.

Az authorized_keys formátuma sor-orientált (legalábbis OpenSSH-nál). Ahol más formátum van, pl. OpenVMS sshd-nél, ott "RFC 4716 SSH Public Key File Format"-ra lehet szükség szerveroldalon, ehhez ajánlott az "ssh-keygen -e".

Akárhány ilyen kulcspár lehet egy szerveren (az ssh-keygen-nél lásd az -f opciót a generáláshoz, az ssh-nál az -i opciót, vagy a ~/.ssh/config-ban egy Host blokkon belül az IdentityFile opciót a használathoz). Egy szerver account alatti authorized_keys-ben akárhány kulcs lehet. Tehát N:M-ről beszélünk.

Ennyit a generálásról. A jelszó nélküli használatról:

II.1. Az első lehetőség az, hogy a kulcspárt jelszó nélkül generáljuk.

II.2. A második lehetőség, hogy így vagy úgy, de bejelentkezünk egyszer a user@remote account alá, interaktív csatorna (shell session) megnyitása nélkül, ugyanakkor az ssh kliensből egy helyi ssh multiplexort vagy mifenét csinálunk. Ezt a processzt jól félretesszük, majd a további bejelentkezéseknél ezen keresztül megyünk. Ez az utóbbi típusú bejelentkezés nagyon gyors, ugyanis nincs újrahitelesítés, csak a meglévő connection-ön belül nyit új session-t; pont úgy, mint az -L nél az új sockethez.

A master ssh kliens elindításához (-f kapcsoló megadható, ha még háttérbe is akarjuk forkolni, de ekkor a -v-ket ne adjuk meg):

ssh -v -v -v -N -M {... forwarding & compression options ...} -o ControlPath=$HOME/tmp/ssh-socket-%r@%h:%p user@remote

A slave ssh kliensek elindításához pedig:

ssh -o ControlPath=$HOME/tmp/ssh-socket-%r@%h:%p {... forwarding options ...} user@remote

Természetesen ezt a rengeteg opciót nem érdemes mindig beírni, hanem a kliens oldalon létre kell hozni összesen két blokkot a ~/.ssh/config-ban, amelyek azonos remote hostname-re és user-re vonatkoznak, de más alias alatt, és más opciókkal. Egy példa:

Host XXXX-gateway
        HostName                        XXXX-fqdn
        User                            XXXX-remote-user
        ForwardX11                      yes
        ForwardX11Trusted               yes
        ControlMaster                   yes
        ExitOnForwardFailure            yes
        LocalForward                    127.0.0.1:5009 XXXX-other-fqdn:PORT

Host XXXX
        HostName                        XXXX-fqdn
        User                            XXXX-remote-user
        ForwardX11                      yes
        ForwardX11Trusted               yes

Host *
        Compression                     yes
        CompressionLevel                9
        ControlPath                     /home/hupper/ssh-socket-%r@%h:%p
        ServerAliveInterval             60
        ServerAliveCountMax             10

Ezek után az alábbit elindítjuk egy terminálban, és félretesszük: ssh -v -v -v -N XXXX-gateway, majd az egyedi shell-bejelentkezésekhez ssh XXXX. A master processzt kinyírhatjuk ^C-vel a saját termináljával, vagy ssh -O exit XXXX paranccsal bárhonnan.

II.3. A harmadik használati mód a következő. Elindítjuk az ssh-agent-et, és a munkakörnyezetünk gyökerét alkotó processzt (window manager, akármi) meggyőzzük arról, hogy ismerje ennek az agent-nek az elérhetőségét. Ezzel a gyakorlatban egyáltalán nem kell foglalkoznunk, mert évek óta minden disztróban úgy indul az X session, hogy az ssh-agent már fut, és a session-ben futó minden processz örökül kapja az elérhetőségét.

Az ssh-add paranccsal betölthetjük a kulcspárt az ssh-agent-be. Operandusként opcionálisan megadhatjuk azt a publikus kulcsfile-t, amelyet használni akarunk. Megadható még a kulcs agent-beli élettartama a -t kapcsolóval (ennyi idő után automatikusan lejár). Kulcsokat az agent-ből kézzel is takaríthatunk (-d, -D), illetve az agent zárolható is.

Ha a kulcsot jelszóval védtük, akkor az agent-be töltéskor meg kell adnunk, de utána a belépésekkor már nem.

Az agent-nél az igazán durva az, hogy az agent connection minden máshoz hasonlóan forwardolható. Így a helyi gépünkön betölthetjük a helyi agent-be az a@b, c@d, e@f account-jainkhoz való, potenciálisan különböző kulcsokat. Ezután bejelentkezhetünk az a@b-re, majd onnan a c@d-re, majd ismét onnan az e@f-re, és egyszer sem kell jelszót megadnunk (feltéve persze, hogy előtte ezen account-ok alatt mindenhol rendesen beállítottuk az authorized_keys file tartalmát). Mindeközben az érzékeny kulcsanyag sosem hagyja el a lokális gépünket, tehát még biztonságosabb is, mintha a c@d-n begépelnénk az e@f-hez tartozó jelszavunkat, vagy a c@d-n tárolnánk az e@f-hez való privát kulcsunkat.

Az OpenSSH az egyik legjobb program a világon.

[off]
"SSH azonosítás nyilvános kulcsal, tövis nélkül" - én így olvastam. Néztem nagyot, aztán rájöttem, hogy az csak a nicked. Úgy látszik nagymamám félreolvasása örökletes.
[/off]
---
O Fortuna! Velut luna! Statu variabilis! --- műűvelt aláírás http://bit.ly/gut42V

Nincs SSH kulcs tovis nelkul... :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hűha! Ennyi infót egyszerre már régen kaptam :D Nagyon köszönöm!
Most alaposan átolvasom.

* Én egy indián vagyok. Minden indián hazudik.

Még egy kurfli!
Mi van akkor ha más nevében akarok bejelentkezni?
Normálisan, interaktív jelszóval ez gond nélkül megy (már ha ismered a jelszót)

  tovis@mybox$ssh 
  password:

És benn vagy, a notme úr nevében, de mi van a nyilvános kulcsommal? Másoljam be magamnak az övét? Akkor a saját nevemben nem tudok bejelentkezni? Lesz itt mit vacakolni.

* Én egy indián vagyok. Minden indián hazudik.

ahova a saját publikus kulcsodat bemásoltad, oda be tudsz jelentkezni. Ha a távoli gépen a root alá, akkor rootnak, ha notme home-ja alá, akkor notme-nek.

Ez jól hangzik, de alig értem.
Tehát, én magamnak generálok egy nyilvános kulcsot ami normálisan a /home/tovis/.ssh/id_rsa.pub
Ezt másoljam anotmybox -on a /home/notme/.ssh/authorized_keys2 és bejelentkezhetem, jelszó nélkül mint notme?
Az id_rsa.pub, nem tartalmazza a felhasználói nevemet?

* Én egy indián vagyok. Minden indián hazudik.

nem keys2 hanem keys, de egyébként igen.
az authorized_keys fájlba soronként egy kulcsot rakva, mindenki be fog tudni menni.

az id_rsa.pub emlékeim szerint azt az accot tartalmazza, amin a kulcsot generáltad. azt, ahova mész, tudtommal nem.

Igen, pontosabban:
~/.ssh/authorized_keys2
Obsolete name for ~/.ssh/authorized_keys. This file may still be present on some old systems, but should not be created if it is missing.

Tehát működni fog keys2-vel is, de elavult.

Egyébként idétlen idők óta használom az ssh -t de még mindig rengeteg dolgot nem tudok róla, még a logikai felépítésében sem.

* Én egy indián vagyok. Minden indián hazudik.

Sajnos az a baj, hogy ez többek között azért is lehet, mert sok minden nincs rendesen ledokumentálva.
Ha valaki jó kis linkekkel tudja ezt megcáfolni, akkor ezt megköszönöm.

Nem tudom jó lesz ez, én is most találtam.
http://ebookee.org/SSH-The-Secure-Shell-The-Definitive-Guide-SE_167061.html
Jellemző "chm" sem a hh sem a winhlp32.exe nem tudja kezelni? Mi kell ehhez :o(

* Én egy indián vagyok. Minden indián hazudik.

Köszi. Megnézzük :)
xCHM nevű progi Linux alatt szépen nyitotta nekem ezeket mindig.
Ezzel sincs baja.

chmsee
--
unix -- több, mint kód. filozófia.
Life is feudal

GnoCHM. Nagyon jo kis cucc, es nem csak azert, mert en keszitettem a magyar lokalizaciojat ;-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

kulccsal

t

No akkor még egy - lehet, hogy buta - kérdés a témához:

A generált ssh kulcs géphez, felhasználóhoz, vagy egyszerre mind a kettőhöz kötődik?

Értem ez alatt, hogy csak arról a gépről tudom-e használni, amelyen létrehoztam, vagy csak abból a felhasználói fiókból, amely alatt létrehoztam, vagy mind a két feltételnek egyszerre meg kell felelnem, ha be akarok lépni egy távoli gépre?

Egyikhez sem... az csak egy kulcs.
--
HUPbeszolas FF extension

Ha a célon elérhető a nyilvános kulcsod, akkor bárhonnan, ahol ott van a nyilvános és privát kulcsod, tudsz kulcs alapon authentikálni.
--
unix -- több, mint kód. filozófia.
Life is feudal

Csak a privátnak kell nálad lennie.
--
HUPbeszolas FF extension

Igen. Csak annak.
--
unix -- több, mint kód. filozófia.
Life is feudal

Mindenkinek köszönöm szépen a válaszokat!

Az bizonytalanított el, hogy minden publikus kulcsom végén ott van a user@gépnév

Az bizonytalanított el, hogy minden publikus kulcsom végén ott van a user@gépnév

Az 'információs mező', az neked szól, az a célja, hogy tudhasd, hol generáltad a kulcsot.

Ha pl. egy accountra 42 különböző felhasználó be van engedve kulcsos authentikációval, akkor praktikus, ha tudjuk, melyik kulcs melyik useré!

Érdemes csak arról a gépről és account alól használnod, ahol létrehoztad.

Érdekelne az indoklás is. Miért "érdemes"? Van valami biztonsági kockázata?

Csak azért kérdezem, mert eddig én is így gondoltam az eredeti kérdésemben megfogalmazott bizonytalanságokkal együtt, de a többi bejegyzés e témában nem ezt sugallja.

Gondolom azért, hogy ne kelljen a kulcspár másik felét magaddal "cipelni".

"A +1 az a proletárlájk."

Épp most "klónozok" egy rendszert ami ssh tunneleket használ, az én felhasználói nevem alatt a szerveren már ott van a kulcs - szó nélkül működik. Kicsit ijesztő, hiszen ezek szerint aki a kulcsomhoz hozzáfér és tudja a felhasználói nevemet simán, jelszó nélkül beléphet - az én kulcsomat egy csomagkapkodóval le lehet szedni!
Mondjuk én sosem használtam ilyen csomag kapkodókat, így én magamat sem tudnám meg fogni.

* Én egy indián vagyok. Minden indián hazudik.

"Kicsit ijesztő, hiszen ezek szerint aki a kulcsomhoz hozzáfér..."

Mi ijesztő és miért?

Meg mi az a csomagkapkodó? Én madárvédő golyókapkodót ismerek, meg órarugógerincű felpattanót, meg vastalpú cölöpverőt, de ezt nem :) (bocs)

Használd a passphrase-t.
--
unix -- több, mint kód. filozófia.
Life is feudal

Ha egyszer tudja a támadó a jelszavadat, akkor mi abban az ijesztő, hogy tudja használni a kulcsodat, hiszen akkor már mindenhez hozzáfér. Az ijesztő az, hogy tudja a jelszavadat :) De ahogy lzrd írta, jelszavazd le a kulcsodat (passphrase). Értelemszerűen ne ugyanazzal, mint a felhasználói jelszavad.

Akkor ugyanott van, mintha simán csak a jelszavas bejelentkezést használná. Szerintem.
--
HUPbeszolas FF extension

Miért is?

Mit nem értesz?
--
HUPbeszolas FF extension

Téged?!

Akkor jó, már azt hittem azt nem érted, hogy miért van szinte ugyanott ha passphrase-t használ a kulcsoknál, mintha csak begépelné a jelszót.
--
HUPbeszolas FF extension

Amennyiben úgy érted, hogy munkaigényében van ugyanott, akkor igen. Valóban le kell ütni pár billentyűt. Viszont kettős hitelesítéssel nagyobb biztonságban lesz.
--
unix -- több, mint kód. filozófia.
Life is feudal

Te jó ég! - így felborzoltam a kedélyeket?
A "csomagkapkodó" egy olyan kis program ami egy adott gép felé irányuló kommunikációs csomagokat képes összeszedni (értelmezni, összerakni stb.). A publikus kulcsom nyílt szerintem simán megy ki a netre - miután ez elmegy máris be lehet lépni a távoli gépre, jelszó nélkül. Mi ebben a nem érthető?
Más kérdés, hogy ki az ördögnek kellenének az én kis okosságaim, hogy ennyi melót belefeccöljön? _ jelenleg senki :(

* Én egy indián vagyok. Minden indián hazudik.

Miért menne ki a kulcsod a net-re?
--
HUPbeszolas FF extension

A publikus kulcsom nyílt szerintem simán megy ki a netre - miután ez elmegy máris be lehet lépni a távoli gépre, jelszó nélkül.

A publikus kulcs nem elég ahhoz, hogy valaki jelszó nélkül be tudjon lépni a távoli gépre. Hiába lopja el valaki csak a publikus kulcsot, azzal kb. nem megy semmire.

> A publikus kulcsom nyílt szerintem simán megy ki a netre - miután ez elmegy máris be lehet lépni a távoli gépre, jelszó nélkül. Mi ebben a nem érthető?

Csak az, hogy nem így működik. A publikus kulcs "nem megy ki a netre", hanem a ~/.ssh/authorized_keys fájlban van jó előre letárolva. Jelszó nélkül pedig akkor lehet belépni, ha bizonyítani tudod az sshd-nek, hogy a birtokodban van egy letárolt publikus kulcs privát párja.

Miért nem nézem a dátumokat ???????????????
-------------------------------------------

A publikus kulcsod "simán" megy keresztül a neten:

% cat ~/.ssh/id_rsa.pub | ssh user@server "cat >> .ssh/authorized_keys"

simán:

  1. local-od bekopogtat remote-hoz a kijelölt:porton

  2. remote elküldi ssh_host_rsa_key.pub (remote-pubkey)
    kulcsát local-odnak

  3. local-od ezzel kódolva elküldi saját
    ssh_host_rsa_key.pub (local-pubkey) kulcsát remote-nak

  4. remote "local.pubkey" kódolva küld local-nak egy ServerKeyBits hosszú "live" generált véletlenszámot.

  5. local "remote-pubkey" kódolva visszaküldi remote-nak.

  6. ha stimmel, ugyanezzel a "kulcsos" protokollal lekérdezi
    a login-name/password párost.

  7. és most "simán" átmegy a titkosított kapcsolaton keresztül a saját
    "~/.ssh/id_rsa.pub" kulcsod a megfelelő helyre

  8. letilthatod magadnál a jelszavas bejelentkezést egy egysoros remote/~/.ssh/ssh_config file segítségével:
    PasswordAuthentication no

  9. Jó, ha ezt másik (párhuzamos) bejelentkezéssel ki is próbálod, mielőtt kizárod magad

... legalábbis így emlékszem

Vagyis a te publikus kulcsodat a saját local-privát-kulcsod nélkül feldughatja bárki oda, ahova.

Érdekelne az indoklás is. Miért "érdemes"? Van valami biztonsági kockázata?

Azért érdemes a kulcspár privát felét egyetlen helyen tartani, mert így a target server-en egyedileg tudod később eltávolítani a publikus kulcsokat. Ha a privát kulcsot felviszed a G generálási helyen kívül még A, B, C szerverekre is, akkor később nem tudod úgy eltávolítani a G publikus kulcsát a célban, hogy ne kellene A, B, C-n új kulcsokat generálnod.

Fontos észrevenni, hogy azt a kulcsot, amit ki akarsz tiltani, mindenképpen ki tudod, tehát az a veszély nem áll fenn, hogy túl kicsit nyisszantanál. Az a kényelmetlenség viszont előfodulhat, hogy a nyisszantás után más szervereken új kulcspárokat kell majd generálni.

Nyilván ez a (tájékoztató) szerepe az információs mezőnek is a publikus kulcs végén. Csak akkor van értelme, ha a privát kulcsot egyetlen helyről használod.

Egyszóval a kérdés csak annyi, hogy mikor generálsz új kulcsot A, B, C szervereken. Ha nem osztod meg a privát kulcsot, hanem újat generálsz, akkor az adminisztrációt akkor végzed, amikor a belépést lehetővé akarod tenni. Ha megosztod a privát kulcsot, akkor viszont akkor generálsz negyvenklienc gépen új kulcsot (vagy másolgatsz, megint), amikor az ötvenedik kulcsát (= a megosztott kulcsot) eltávolítod.

Persze normális esetben a privát kulcsod a személyedhez köthető, és sosem hagyja el a laptop-odat / asztali gépedet. (Ja és persze passphrase védi.) Ha láncolva ssh-zol, akkor agent forwarding-ot használsz. Az agent arra is jó, hogy egy munkamenetben elég a passphrase-t egyetlen alkalommal begépelned.

A generált ssh kulcs géphez, felhasználóhoz, vagy egyszerre mind a kettőhöz kötődik?

Értem ez alatt, hogy csak arról a gépről tudom-e használni, amelyen létrehoztam, vagy csak abból a felhasználói fiókból, amely alatt létrehoztam, vagy mind a két feltételnek egyszerre meg kell felelnem, ha be akarok lépni egy távoli gépre?

Egyik sem.
Ahhoz, hogy be tudjál lépni, ahhoz a generáláskor készült privát kulcs kell csak.

Alapból a kulcs a .ssh könyvtárba kerül (de a generáláskor akárhová rakhatod), típus szerint valamelyik id_... fájlba, a hozzátartozó nyilvános kulcs pedig a melléje kerülő .pub fájlba. Az ssh-nak pedig induláskor a -i opcióval megadhatod, hogy ne alapból a .ssh-ban levő privát kulcsot használja, hanem helyette valami másikat.

A fentiekből következik, hogy arról a gépről, ahol tárolod a privát kulcsot, simán ellopható, és ha nem adtál meg passphrase-t (jelszót) a generáláskor, azaz jelszó nélkül lehet használni a privát kulcsot, akkor ha ellopják, bárki más is ugyanígy jelszó nélkül tudja használni.

Jó. Ugorjuk most a nyilvános kulcs biztonsági kockázatait.
Lehetséges, hogy azonos localhoston több private/public kulcsunk is legyen (azonos felhasználó)?

* Én egy indián vagyok. Minden indián hazudik.

Igen, több kulcsot is generálhatsz az ssh-keygen paranccsal. Sőt, az ssh-nál -i kapcsolóval külön megadhatod a privát kulcs helyét.

meselj ezekrol a biztonsagi kockazatokrol... felteve, hogy a kulcson jelszo is van, a privat kulcsom meg el van titkositva a gepemen.

oh wait, fent latom, hogy teljesen inkompetens vagy a temaban. pedig azt hittem, megtudok ma valami ujat ;)

Pont azért mondtam, hogy "ugorjuk" a témát. Biztonsági kockázatok mindig vannak (nem én mondtam), de ha valami akkor az ssh "egyszerűségével" és rugalmasságával, az egyik legbiztonságosabb eszköz amivel találkoztam eddig.
OFF: Én már lassan semmiben sem leszek kompetens, mert annyi mindenbe "beleszagoltam" és semmibe sem "ástam bele" magam.

* Én egy indián vagyok. Minden indián hazudik.

Most hogy az n+1 -ik géppel kapcsolódom a kiszolgálómhoz, felötlött bennem, hogy mi lenne ha ugyanazt a public és private keyt másolgatnám minden általam használt gépen a profilomba/home -ba? Akár mindkettőt, elkülönítve (esetleg titkosítva) tárolhatnám a kiszolgálón, és a konfigurálás során átmásolnám az aktuális célgépre?
Nem tudom mekkora a biztonsági kockázata egy ilyen megoldásnak, de nem tűnik megvalósíthatatlannak.

* Én egy indián vagyok. Minden indián hazudik.

Nem kell ugyanazt másolgatni. Több publikus és több privát kulcsod is lehet. Így tehetsz külön kulcsot minden gépre amihez hozzáférést akarsz.

Most pont ezt csinálom, azért gondoltam, hogy egyszerűbb megoldás ugyanazt másolgatni, minden gépre mint mindegyikhez létrehozni egy újat.

SZERK: Jut eszembe, a klónozott konfigurációk amúgy is tartalmaznak egy ilyen kulcsot, minden klón ugyanazt.

* Én egy indián vagyok. Minden indián hazudik.

Nem tudom mekkora a biztonsági kockázata egy ilyen megoldásnak,

1. Ha ugyanaz a kulcs mindegyik gépen az accountodban, akkor mindenhova vagy beengeded mindegyiket, vagy egyiket sem. Azaz nem tudod kulcs szinten engedélyezni, hogy hova melyik gépen levő accountodról lehet belépni (persze lehet 22-es port szinten tűzfalazni is).

2. Ha az egyik accountodat kompromittálják, akkor nem tudod csak ahhoz az egyhez tartozó kulcsot törölni (és helyette újat generálni), hanem az egy szem kulcsot kell törölnöd, és utána mindegyik gépre az újat odavarázsolni.

Egyiket sem érzem nagy problémának, ha és amennyiben a gépek egyébként ekvivalensek biztonsági szempontból (pl. ugyanabban a belső hálózatban vannak).

Sziasztok!

Most akadtam erre a topikra, valami ilyesmit szeretnék talán, de nem biztos :)
Szeretnék tőletek egy kis segítséget, gyorstalpalót kérni erről a témáról. Teljesen jó lenne egy ajánlott - lehetőleg magyar nyelvű - link is.
Kerestem Google-al, gyakorlatilag kivétel nélkül úgy kezdődnek az efajta leírások, hogy kell ez meg az, tedd fel ide ezt, oda azt, csináld ezt (4-5 sornyi parancs), kész. Aztán ezen leírások végén egy-két kommentelő, aki kikorrigál egy-két parancsot, vagy egyszerűbbet kínál fel :) - szóval nekem valami -1 szintes leírás, bevezetés kellene ebben a témában.

Hallottam olyat, hogy biztonságosabb a jelszó nélküli, kulcs alapú SSH bejelentkezés. Nem tudom, hogy ez igaz-e, mert nem tudom, hogy hogyan működik a dolog - szívesen olvasnék erről.
Ami biztos, már több, mint húsz olyan linuxos szervert kell adminisztrálnom SSH felületen, ami szanaszét van az interneten. Egy jelszót nem akarok mindenhova használni, mert az tudjuk, hogy milyen. Most viszont kezdek szellemi tűrőképességem határára érni, mármint ami a szerverekhez tartozó jelszavak megjegyzését illeti. Tárolom őket jelszóval védett fájlban, de sok esetben nincs módom, vagy időm megnyitni, azonnal be kellene jelentkezni.
Azt gondolom, hogy nagyjából ezt a problémát tudná megoldani a jelszó nélküli belépés, de nem tudom, milyen más egyéb dolgot könnyít és mit, miket nehezít meg ez a dolog.

Nyilván cél az, hogy csak az illetékes tudjon belépni. Hogy van ez? Most "sima" PuTTY-ot használok, csatlakozáskor felhasználó nevet és jelszót kér, beírom, bent vagyok. Ezt ismerem eddig :) De ha nem kér jelszót és más ül a gépemhez - akár mert ellopták - akkor bárhova be tud jelentkezni? Van arra mód, hogy az egész PuTTY-ot (?) egyetlen jelszóval védjem le? - bár nem tudom, hogy ez mennyire biztonságos.
Van arra mód, hogy pl. az én gépemről otthonról jelszó nélkül jelentkezek be, de bárhonnan máshonnan továbbra is felh.névvel/jelszóval?

Na mindegy, nem kérdezek többet, mert ha tudnám hogyan megy ez az egész, biztosan a kérdések több, mint fele értelmét vesztené :) Remélem nem haragszotok meg, de nem tudtam máshol feltenni ezt a kérdést.

Előre is köszi:
Mono

Ez szerintem egy tök jó leírás kulcs alapú ssh auth-hoz:

http://www.howtoforge.com/set-up-ssh-with-public-key-authentication-debian-etch

Köszi, ezt is megtaláltam már, szerintem tök jól ráillik arra a fajta howto-ra, amit említettem fentebb :) Úgy kezdi, hogy apt-get install, aztán páran a végén a kommentekben javítgatnak ezt-azt :) - ne érts félre, jó lesz majd egy ilyen, de előtte szeretném azt látni, hogy mi ez az egész, hogy működik, miért működik úgy, mitől lesz biztonságos(abb), mint a felhasználó név/jelszó páros használata, stb.
Most valami ilyen leírásra vágynék :) Minél jobban bele akarom ebbe ásni magam, végülis az egyik legkomolyabb biztonsági kérdés is lehetne. Amíg nem látom át elvben, addig nem szívesen állítgatok, állok át erre, nem akarok váratlan meglepetéseket :)

Ne foglalkozz a kommentekkel, az úgy, ahogy van, működik.

Aztán, ha akarsz, még nézegethetsz sshd szerver hardeninges oldalakat is, de az már főleg sshd_config túrás. :)

De mindezek nélkül nekem még nem törtek fel egy linuxot sem. Kis józan paraszti ész kell, root logint tiltani, magyar user nevet, combosabb jelszót választani, fail2ban csomagot feltenni, tűzfalat felkonfigolni, és nincs gond alap 22-es porton sem.
Ha meg vki nagyon be akar menni (ilyen félreeső gépecskékre nem akarnak), akkor úgy is bemennek.

Persze, persze, ez okés, köszi.
Mind megvan, még a 22-esről is arrább tettem a portot, ez okés.
De tényleg, ilyen alap dolgokra keresnék leírást/választ, hogy mi van akkor, ha ellopják a gépem és valaki más kerül elé? Rákattint a PuTTY-ban az egyik szerverre és már bent is van?
Hogyan tudok törölni egy ilyen hozzáférést az egyik szerverről?
Továbbra is be tudok lépni felhasználónévvel és jelszóval is, vagy csak ezzel a móddal? Akár ugyanarról a "PuTTY-os" gépről be tudok lépni így is, úgy is? Ésatöbbi... :)

Ha megszerzik a kulcsod, akkor bárki be tud lépni, ez nyilvánvaló. Kulcs generálásnál megadhatsz jelszót is, bár ekkor ugyanott vagy, mint az elején, h megint jelszót kell tudni. :) De ha ugyanaz a kulcs (én mindenhol ugyanazt használom), akkor már csak 1 jelszót kell tudnod. Amúgy a /home partíciódat lehet titkosítani is. Ha elhagyod a géped, ez segíthet.
Hozzáférést úgy tudsz törölni, h az authorized_keys fájlból kitörlöd a kulcsod.

Ja, jó tanács: a kulcsod ne csak egyetlen helyen legyen meg. Nagyon ciki szituk fordulhatnak elő ha az megsemmisül. :)

Na kezdem kapizsgálni már ezt a dolgot - talán :)
Tehát amikor kulcsot generálok, lehetőségem van passphrase megadására, így ha a kulcsot használnám, akkor ezt a jelszót bekéri?
Arra is módom van, hogy minden szerverhez új kulcspárt generálok, de ugyanazt a passphrase jelszót adom meg, így ugyanúgy egy jelszót kell csak megjegyeznem (illetve kell megtudjanak :) ) - de a kulcsok mégis különbözőek. Jól gondolom, hogy ez valamivel nagyobb biztonságot ad, mintha csak egy kulcsom lenne mindenhova? Vagy ez csak illúzió, hisz' a jelszavuk ugyanaz?

Az általad mutatott leírásban azt csinálja, hogy a szerverre átteszi a publikus kulcsot, majd törli a kliens gépről.
Ahhoz, hogy töröljem a szerverről az adott kulcsot, az authorized_keys fájlból kell törölnöm. Itt viszont honnan tudom, hogy melyik az a publikus kulcs, ami az adott klienshez tartozik? Azaz mégsem jó, ha a kliensről törlöm, hanem inkább tegyem el valahova, hogy legyen mivel összevetni, ugye?

Bocs, ha hülyeségeket kérdezek, csak próbálom összerakni ennek a használatát, előnyeit, buktatóit, mindenét :)

Köszi mindent, agyalok még ezen, majd próbálgatni is fogom, aztán jövök még kérdezni :)

Jól gondolom, hogy ez valamivel nagyobb biztonságot ad, mintha csak egy kulcsom lenne mindenhova?

Nem ad nagyobb biztonságot. Mindkét verzióban a géped tartalma, és az egy szem jelszavad kell a betörőnek.

Amiben jobb lehetne, hogy így az egyik kulcsot külön oda tudnád adni valakinek, hogy szintén be tudjon lépni a szerverre, és ezzel nem kell automatikusan a többi szerverre is beengedned. De ez igazából lényegtelen, hiszen ennek a valakinek ilyen esetben inkább egy saját kulcsot kéne generálnia, és azt a kérdéses szerver engedélyezőfájljába szintén felvenni.

Szóval nem tudnék indokot találni erre a megoldásra.

majd törli a kliens gépről.

Nem néztem meg, hogy mit is írnak, de ez egy baromság, nem kell törölni a kliens gépről semmit se.

Itt viszont honnan tudom, hogy melyik az a publikus kulcs, ami az adott klienshez tartozik?

Ha openssh-t használsz, akkor annak a kulcsgenerálója beleírja a publikus kulcs végére egy komment mezőbe, hogy melyik gépen melyik user generálta a kulcsot. Ha így komplett másolod az egész sort, akkor tudni fogod, hogy melyik gépről származott.
Hogy a winfosos cuccok mit csinálnak, arról halvány lila gőzöm sincs, de persze a kulcs mögé te is írhatsz akármit...

"... és az egy szem jelszavad kell a betörőnek."

Ezenkívül ki az, melyik port, melyik gépről:

/etc/ssh/sshd_config:

...
AllowUsers user1 user2

# What ports, IPs and protocols we listen for
Port 23456
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
...

ha a ListenAddress változik, érdemes elsőnek a 127.0.0.1-et és ha fix a hálózati cim, akkor azt is megadni a próbához.

Na közben rájöttem, hogy az egyik kérdésem hülyeség, látom, hogy az authorized_keys végén ott van a hozzá tartozó név, ami viszont nem minden esetben alkalmas az egyértelmű beazonosításra a rendszer számára. Másként kérdezve: ide bármit írhatok, ami számomra azonosít, de a gép neve ebből még nem derül ki (további védelem miatt kérdem).
Azaz lehet pl. a www.index.hu szerver kulcsának végén egy "Konyhai számítógép" megnevezés, amiből én ugyan tudom, hogy az az index.hu szerver kulcsa, de az, aki belenéz ebbe az authorized_keys fájlba, nem tudja meg, hogy milyen más kulcsok vannak még itt, ugye?
Gyakorlatilag az ezzel a paranccsal megadott szöveges (comment) rész kerül a kulcs végére?

ssh-keygen -t rsa -C "A comment... usually an email is enough here..."

Következmények nélkül átírhatom ezt a szüveget az authorized_keys fájlban bármikor?

Köszi és bocs :)

Nevezz ki egy gepet jump szervernek. Ezen erosen korlatozd az ssh elereset, legyen grsec-el erositett szerver es a legkevesebb ssh-n kivuli service menjen rajta. A jelszavak szinten extra erosek legyenek es salted sha512-t hasznalj jelszo hasheleshez.

Itt legyen a kulcsod szinten jo eros jelszoval. A tobbi gepedre innen egyszeruen tudsz belepni ezzel a kulccsal es ssh-agent-el. A tobbi gepen eleg csak errol es valamilyen masikrol engedni a belepest vesz esetere.

Igen, ez valóban jól hangzik így, elgondolkodtató, köszi neked is!

Még egy kérdés. Itt csinál DSA és RSA kulcsot is. Miért? Mi a különbség, miért kell kettő, miért van ez? :)
http://www.okros.info/2010/04/28/ssh-kapcsolat-jelszo-nelkul/

Nem kell ketfele. Az RSA-nal a maximalis meret nincs korlatozva, a DSA-nal emlekeim szerint meg igen.

Ne hagyd magad a sok remek leiras altal felrevezetni, mert csak ennyi kell:

1) ssh-keygen -el generalsz egy kulcspart, ha a soksokbitest valasztottal elmesz kavezni
2) a PUBLIKUS reszt beteszed a .ssh/authorized_keys fileba a celszerveren a megfelelo jusered homejaba
3) boldogan hasznalod, illetve ahol kell letiltod a jelszavas belepest es az allowusers-be a belepesre erdemes juzereket felsorolod

OK, köszönöm, ez már kezd körvonalazódni számomra.
Az authorized_keys fájlban a sor végi humánusan olvasható szöveges részek átírhatóak bármikor?
Mi van akkor, ha nagyobb méretet adok meg a kulcs generálásakor(mondjuk 4096 bitest az 1024-es helyett)? A generálás tart csak sokáig, vagy utána emiatt erősebb lesz a felépült SSH kapcsolat, ami majd folyamatosan nagyobb processzorteljesítményt igényel és kisebb hálózati sebességet jelent, vagy nagyon keverek valamit? :)

A kapcsolat altal hasznalt titkositast a -c kapcsoloval tudod megadni es az ettol fuggetlen. A bitek szama a kulcs hosszusagat erosseget adja meg. Hosszu tavon szerintem a 4096 vagy 8192 bitest erdemes valasztani, mert ahogy a szamitasi kapacitas veszett iramban no egyre gyorsabban fejthetoek vissza.

azert egy google kereses egy DSA/RSA -ra mar bele kellett volna, hogy ferjen... mert most fogalom nelkul vagy egy kicsit.

ssh-keygen -b 4096 -t rsa
például.
Fájlrendszeren a jogosultságokat is hasznos csekkolni.
--
unix -- több, mint kód. filozófia.
Life is feudal

A jump szerver működő megoldás, de a jump szerveren kulcsot tárolni felesleges biztonsági kockázat. A kulcsot a lokális (desktopon futó) authentikációs agenten keresztül kell kiajánlani, aki optimális esetben egy smartcardról veszi azt.

Köszi az infókat, egyelőre szerintem képben vagyok :)

Van egy klassz könyvem, ha érdekel:
Himanshu Dwivedi: SSH a gyakorlatban (Kiskapu)
--
unix -- több, mint kód. filozófia.
Life is feudal

+1

Köszi az ajánlást, tegnap napközben megvettem :)

ehhez konyv?! azert nem atomfizika.

nem is bűn.
--
unix -- több, mint kód. filozófia.
Life is feudal

Bocsánat :X Nekem is megvan - nem rossz, de túl sokat foglalkozik a különféle verziókkal - ami már itt-ott erősen túlhaladott.

OFF:
Barátunk még nem tudja - én már több mint 40 éve gyűjtöm a különféle könyveket (szép irodalom, szakma, több nyelven). Mikor felújítottam, majd egy tonna könyvet kellett megmozgatnom! - és ez nem túlzás, kiszámoltam.

* Én egy indián vagyok. Minden indián hazudik.

a legnagyobb problema az informatikai konyvekkel az, hogy a bennuk levo tartalom elavul, igy a szakmai ertekuk rohamosan csokken; ettol fuggetlenul tartom, hogy az SSH nem egy annyira bonyolult dolog, hogy konyv kene hozza (vagy akar rola irni...)

sub

+1

-+-+-+
Dropbox tarhely
Cave Canem
+-+-+-