A known_hosts fájl lehetővé teszi az ügyfél számára a szerver hitelesítését annak ellenőrzésére, hogy nem kapcsolódik-e a megszemélyesítőhöz. A authorized_keys fájl lehetővé teszi a szerver hitelesíti a felhasználót.

Kiszolgáló hitelesítése

Az SSH-kapcsolat létrehozásakor az egyik első dolog az, hogy a szerver elküldi nyilvános kulcsát az ügyfélnek, és bebizonyítja (köszönhetően a nyilvános kulcsú titkosításnak ) az ügyfélnek, hogy ismeri a társított magánkulcsot. Ez hitelesíti a szervert: ha a protokoll ezen része sikeres, az ügyfél tudja, hogy a szerver az, akinek állítja.

Az ügyfél ellenőrizheti, hogy a szerver ismert-e, és nem valami szélhámos szerver igazként próbál elájulni. Az SSH csak egy egyszerű mechanizmust biztosít a szerver legitimitásának ellenőrzésére: megjegyzi azokat a szervereket, amelyekhez már csatlakozott, az ügyfélgép ~/.ssh/known_hosts fájljában (van egy rendszer is) kiterjedt fájl /etc/ssh/known_hosts). A szerverhez való első csatlakozáskor valamilyen más eszközzel ellenőriznie kell, hogy a szerver által bemutatott nyilvános kulcs valóban a szerver nyilvános kulcsa csatlakozni szeretett volna. Ha rendelkezik annak a szervernek a nyilvános kulcsával, amelyhez csatlakozni készül, manuálisan hozzáadhatja a kliens ~/.ssh/known_hosts címéhez.

Egyébként a known_hosts bármilyen típusú SSH-implementáció által támogatott nyilvános kulcsot tartalmazhat, nem csak a DSA-t (az RSA-t és az ECDSA-t is).

A kiszolgálót meg kell tenni, mielőtt bármilyen bizalmas adatot elküldenénk neki. Különösen, ha a felhasználói hitelesítés jelszót tartalmaz, akkor a jelszót nem szabad elküldeni egy nem hitelesített szervernek.

Felhasználói hitelesítés

A szerver csak akkor engedélyezi a távoli felhasználó bejelentkezését, ha az a felhasználó igazolni tudja, hogy joguk van hozzáférni ahhoz a számlához. A kiszolgáló konfigurációjától és a felhasználó választásától függően a felhasználó a hitelesítő adatok különböző formáinak egyikét mutathatja be (az alábbi lista nem teljes).

• A felhasználó bemutathatja a a fiók, amelybe próbál bejelentkezni; a szerver ezután ellenőrzi, hogy a jelszó helyes-e.
• A felhasználó bemutathat egy nyilvános kulcsot, és bebizonyíthatja, hogy rendelkezik az adott nyilvános kulccsal társított magánkulccsal. Ez pontosan ugyanaz a módszer, amelyet a szerver hitelesítésére használnak, de most a felhasználó megpróbálja igazolni identitását, a szerver pedig azt. A bejelentkezési kísérlet akkor fogadható el, ha a felhasználó bebizonyítja, hogy ismeri a magánkulcsot, és a nyilvános kulcs szerepel a fiók jogosultsági listájában (~/.ssh/authorized_keys a szerveren).
• A módszer egy másik típusa a felhasználó hitelesítésének egy részének delegálása az ügyfélgépre. Ez olyan ellenőrzött környezetekben történik, mint például a vállalkozások, amikor sok gép ugyanazokkal a fiókokkal rendelkezik. A szerver ugyanazon mechanizmus segítségével hitelesíti az ügyfélgépet. fordítva használta, majd az ügyfélre támaszkodik a felhasználó hitelesítésében.

Megjegyzések

• köszönöm, hogy ez nagyon hasznos. helyes azt mondani, hogy az ismert_hosts fájl az ügyfélen van karban, míg az authoris_key fájl a szerveren van.
• @Ankit Igen, ez a helyzet.
• Mindkét fájlom van a szerveren és ssh hozzá, hogy tesztelje. De a 2 fájl tartalma különbözik. Tehát a kulcsok különböznek ezekben a fájlokban?
• @Timo A kulcsok teljesen unr felajzott. Az egyik a gép kulcsa, a másik a felhasználóé.
• @Gilles Tehát, ha egyszer egy szerver bejegyzése ‘ s nyilvános kulcs hozzáadódik a kliens ‘ kliens gépének ismert_gazdák fájljába, a következő két ssh munkamenet a két nem ‘ t között megkövetelik a szervertől, hogy igazolja, hogy megfelelő privát kulccsal rendelkezik?

Ezt a két fájlt a használja SSH , de teljesen más célokra, ami könnyen megmagyarázhatja zavartságát.

Engedélyezett kulcsok

Alapértelmezés szerint az SSH olyan felhasználói fiókokat és jelszavakat használ, amelyeket a gazdagép operációs rendszere kezel. (Nos, valójában a PAM kezeli , de ez a megkülönböztetés valószínűleg nem túl hasznos itt.) Ez azt jelenti, hogy amikor megpróbál csatlakozni az SSH-hoz a felhasználónévvel “bob” és néhány jelszó, amelyet az SSH szerver program megkérdez az operációs rendszerről ” Megkaptam ezt a “bob” nevű srácot, aki “megmondja, hogy jelszava” winka “. Engedhetem be? ” Ha a válasz igen, akkor az SSH lehetővé teszi a hitelesítést, és vidám úton halad.

A jelszavak mellett SSH ezenkívül lehetővé teszi az Ön azonosításához az úgynevezett nyilvános kulcsú titkosítás használatát. A konkrét titkosítási algoritmus változhat, de általában RSA vagy DSA , vagy újabban ECDSA . Mindenesetre, amikor a kulcsokat beállítja, használja a ssh-keygen program létrehozásával két fájlt hoz létre. Az egyik a magánkulcsa, a másik pedig a nyilvános kulcsa. A nevek meglehetősen önállóak -magyarázat. A nyilvános kulcs kialakításával a pitypang magjaihoz hasonlóan a szélben szétszórható anélkül, hogy veszélyeztetné Önt. A magánkulcsot mindig a legmagasabb bizalommal kell megőrizni.

Tehát azt teszi, hogy a nyilvánosságot elhelyezi írja be a authorized_keys fájlt. Ezután amikor megpróbálja csatlakozni az SSH-hoz a “bob” felhasználónévvel, és a magánkulcsod, megkérdezi az operációs rendszert ” Megvan ez a fickó neve “bob”, lehet itt? ” Ha a válasz igen, akkor az SSH megvizsgálja a magánkulcsodat, és ellenőrzi, hogy a authorized_keys fájl nyilvános kulcsa a párja-e. Ha mindkét válasz igen, akkor beengedik.

Ismert házigazdák

Hasonlóan ahhoz, ahogyan a authorized_keys fájlt használják a felhasználók hitelesítésére. a known_hosts fájlt használják a szerverek hitelesítésére. Amikor az SSH-t új kiszolgálón konfigurálják, mindig generál egy nyilvános és privát kulcsot a szerverhez, akárcsak a felhasználóhoz. Minden alkalommal, amikor SSH-kiszolgálóhoz csatlakozik, megmutatja annak nyilvános kulcsát, valamint annak igazolását, hogy rendelkezik a megfelelő magánkulccsal. Ha még nincs meg a nyilvános kulcsa, akkor a számítógép megkéri, és hozzáadja a known_hosts fájlhoz. Ha megvan a kulcs, és egyezik, akkor azonnal csatlakozzon. Ha a kulcsok nem egyeznek, akkor nagy csúnya figyelmeztetést kap. Itt válnak érdekessé a dolgok. A kulcshelyzetek eltérése általában 3 esetben fordul elő:

1. A kulcs megváltozott a szerveren. Ennek oka lehet a operációs rendszer újratelepítése, vagy egyes operációs rendszereken a kulcs újra létrejön az SSH frissítésekor.
2. Az összekapcsolt hosztnév vagy IP-cím. hogy korábban egy másik szerverhez tartozott. Ez lehet cím megváltoztatása, DHCP vagy valami hasonló.
3. Rosszindulatú man- középen támadás történik . Ez a legnagyobb dolog, amitől a kulcsellenőrzés megpróbál megvédeni.

Mindkét esetben known_hosts és authorized_keys, az SSH program nyilvános kulcsú titkosítást használ az ügyfél vagy a szerver azonosítására.

Megjegyzések

• ” Minden alkalommal, amikor SSH-kiszolgálóhoz csatlakozik, bemutatja a magánkulcsát, hogy igazolja identitását. ” Remélem, hogy nem! Feltételezem, hogy a nyilvános kulcsára gondoltad. Ha egy szerver bemutatta nekem, az ügyfélnek a magánkulcsát – az (A) nem működne nálam a hitelesítésben, és (B) azt jelzi, hogy a szerver ilyen rosszul konfiguráltam, hogy azonnal abba kell hagynom az üzletet. A magánkulcsokat csak a kijelölt felhasználók érhetik el a származási gépen. Ez ‘ bizonyos szempontból. 😉
• Ez a válasz jobban segített, mint az elfogadott (:
• Ha helyi szerverre (helyi IP-re), majd később ugyanarról a számítógépről érkezem, de most távolról csatlakozzon ugyanahhoz a szerverhez (nyilvános IP), ez kiváltja a nem egyező kulcsokat? Hogyan lehet ezt enyhíteni?

A nyilvános kulcsokat tartalmazó biztonságos fájlokról

Annak érdekében, hogy megértsük, hogyan különböznek az “ismert_gazdák” és az “engedélyezett_kulcsok”, íme néhány összefüggés, amely elmagyarázza, hogy ezek a fájlok hogyan illeszkednek az “ssh” -be. Ez egy túl egyszerűsítés ; az “ssh” -nek sokkal több képessége és bonyodalma van, mint amit itt említünk.

A társulások megbízható forrásokban vannak

Noha azt mondták, hogy a nyilvános kulcsú értékeket “biztonságosan lehet szétszórni, mint a szélben a magokat”, ne feledje, hogy ez gardner, nem a mag-hüvely, aki eldönti, hogy mely magok települnek a kertbe. Bár egy nyilvános kulcs nem titkos, heves védelemre van szükség a kulcs megbízható társulásának megőrzéséhez ahhoz a dologhoz, amelyet a kulcs hitelesít. Az a feladat, hogy ezt a társítást az “ismert_gazdák”, az “engedélyezett_kulcsok” és az “Igazoló hatóság” listákra bízzák.

Az “ssh” által használt megbízható források

Nyilvános kulcs Az “ssh” szempontjából fontos, hogy a kulcsot idő előtt regisztrálni kell, és a megfelelő biztonságos fájlban kell tárolni. (Ennek az általános igazságnak van egy fontos kivétele, amelyet később tárgyalunk.) A kiszolgálónak és az ügyfélnek mindegyiküknek megvan a sajátja, biztonságosan tárolva nyilvános kulcsok listája; a bejelentkezés csak akkor sikerül, ha mindkét oldal regisztrálva van a másik oldalon.

• Az “ismert_tulajdonosok” a kliensen laknak nt
• Az “Author_keys” a szerveren található.

Az ügyfél biztonságos fájlját “ismert_hosts” -nak, a szerver biztonságos fájlját pedig “authorised_keys” -nek hívják. . Ezek a fájlok annyiban hasonlítanak, hogy mindegyiknek soronként egy nyilvános kulccsal van szövege, de a formátumban és a használatban finom különbségek vannak.

A hitelesítéshez kulcspárokat használnak

Nyilvános – a saját kulcspár az “aszimmetrikus kriptográfia” végrehajtására szolgál. Az “ssh” program aszimmetrikus kriptográfiát használhat hitelesítéshez, ahol az entitásnak egy kihívásra kell válaszolnia, hogy igazolja identitását. A kihívás az egyik kulccsal történő kódolással jön létre, a másik kulccsal pedig a dekódolással válaszol. (Ne feledje, hogy az aszimmetrikus kriptográfiát csak a bejelentkezési szakaszban használják; az “ssh” (TSL / SSL) átvált egy másik titkosítási formára az adatfolyam kezeléséhez.)

Egy kulcspár a kiszolgálóhoz, egy másik klienshez

Az “ssh” fájlban mindkét fél (kliens és szerver) gyanús a másikkal szemben; ez előrelépés az “ssh” elődjéhez képest, amely a “telnet” volt. A “telnet” használatakor az ügyfélnek meg kellett adnia egy jelszót, de a kiszolgálót nem ellenőrizték. Az ellenőrzés hiánya lehetővé tette, hogy “ember a közepén” támadások történjenek, katasztrofális következményekkel járva a biztonságra. Ezzel szemben az “ssh” folyamatban az ügyfél nem ad le információt, amíg a szerver először nem válaszol egy kihívásra.

Az “ssh” hitelesítés lépései

A bejelentkezési adatok megosztása előtt az “ssh” kliens először kiküszöböli az ember-a-közép támadás lehetőségét azzal, hogy kihívja a szervert, hogy bebizonyítsa: “Tényleg az vagy, aki szerintem vagy?” A kihívás teljesítéséhez az ügyfélnek ismernie kell a célkiszolgálóhoz társított nyilvános kulcsot. Az ügyfélnek meg kell találnia a kiszolgáló nevét az “ismert_hosztok” fájlban; a társított nyilvános kulcs ugyanazon a soron található, a kiszolgáló neve után. A kiszolgálónév és a nyilvános kulcs közötti társítást sérthetetlen állapotban kell tartani, ezért az engedélyeket a az “ismert_gazdák” fájlnak 600-nak kell lennie – senki más nem írhat (és nem is olvashat).

Miután a szerver hitelesített, lehetőséget kap az ügyfél megtámadására. A hitelesítéshez a kulcsok találhatók az “autorizált_kulcsokban”. (Ha egyik kulcs sem működik, az “sshd” folyamat visszalép a jelszóstílus-hitelesítésre.)

A fájlformátumok

Tehát ” Az ssh “, mint minden bejelentkezési folyamatnál, léteznek” barátok “listák, és csak a listán lévők próbálkozhatnak egy kihívás átadásával. Az ügyfél számára az” ismert_tagok “fájl olyan barátok listája, akik szerverek (hosztok); ezek név szerint vannak felsorolva. A szerver esetében az egyenértékű ismerősök listája az “authorised_keys” fájl; de a fájlban nincsenek nevek, mivel a A c-billentyűk maguk is azonosítóként működnek. (A szervert nem az érdekli, hogy honnan érkezik a bejelentkezés, hanem csak arra, hogy hová megy. Az ügyfél megpróbál hozzáférni egy adott fiókhoz, a fiók nevét paraméterként határozták meg, amikor az “ssh” parancsot meghívták. Ne feledje, hogy a Az “Author_keys” fájl az adott fiókra vonatkozik, mivel a fájl az adott fiók saját könyvtárában található.)

Bár számos képesség kifejezhető egy konfigurációs bejegyzésben, az alapvető, leggyakoribb használat a következő paraméterekkel rendelkezik. Ne feledje, hogy a paramétereket szóközök választják el egymástól.

Az “ismert_gazdák” esetében:

{server-id} ssh-rsa {public-key-string} {comment} 

Az “engedélyezett kulcsok” esetében:

ssh-rsa {public-key-string} {comment} 

Ne feledje, hogy a ssh-rsa token azt jelzi, hogy a kódoláshoz használt algoritmus “rsa”. Egyéb érvényes algoritmusok tartalmazza a “dsa” és az “ecdsa” elemeket. Ezért egy másik token léphet az itt látható ssh-rsa helyére.

Engedje meg az “ssh” automatikus konfigurálását “ismert_gazdák” bejegyzés

Mindkét esetben, ha th A nyilvános kulcs nem található egy biztonságos fájlban, akkor az aszimmetrikus titkosítás nem történik meg. Mint korábban említettük, egy szabály alól van egy kivétel.A felhasználónak tudatosan dönthet úgy, hogy megkockáztatja a ember közötti támadás lehetőségét azzal, hogy bejelentkezik egy kiszolgálóra, amely nem szerepel a felhasználó “ismert_gazdái” fájljában. Az “ssh” program figyelmezteti a felhasználót, de ha a felhasználó az előrelépés mellett dönt, akkor az “ssh” kliens ezt csak egyszer engedélyezi. “Annak biztosítása érdekében, hogy csak egyszer történjen meg, az” ssh “folyamat automatikusan konfigurálja az” ismert_gazdák “fájlt a szükséges információkkal a szervertől a nyilvános kulcsot, majd ezt beírja az “ismert_gazdák” fájlba. Ez a kivétel teljesen felforgatja a biztonságot azáltal, hogy lehetővé teszi az ellenfél számára, hogy egy kiszolgálónévhez hozzárendelje a nyilvános kulcsot. Ez a biztonsági kockázat megengedett, mert annyira megnöveli a dolgot könnyebb ennyi ember számára. Természetesen a helyes és biztonságos módszer az lett volna, hogy a felhasználó manuálisan szúr be egy sort a kiszolgálónévvel és a nyilvános kulccsal az “ismert_gazdák” fájlba, mielőtt bármikor megpróbálna bejelentkezni a szerverre. (De alacsony kockázatú helyzetekben a többletmunka értelmetlen lehet.)

Az egy a többhöz kapcsolatok

Az ügyfél “ismert_gazdáinak” fájljában egy bejegyzésnek van egy kiszolgáló neve és egy nyilvános kulcs, amely a kiszolgáló gépre vonatkozik. A kiszolgálónak egyetlen privát kulcsa van, amelyet az összes kihívás megválaszolására használnak, és az ügyfél “ismert_gazdák” bejegyzésének rendelkeznie kell a megfelelő nyilvános kulccsal. Ezért minden kliensnek, aki valaha is hozzáfér egy adott szerverhez, azonos nyilvános kulcs lesz bejegyzés az “ismert_gazdák” fájljukba. Az 1: N összefüggés az, hogy a szerver nyilvános kulcsa sok kliens “ismert_gazdák” fájljában jelenhet meg.

Az “engedélyezett_kulcsok” fájlban egy bejegyzés azonosítja hogy egy barátságos ügyfél hozzáférhet a fiókhoz. A barát ugyanazt a nyilvános és privát kulcspárt használhatja több, különböző szerver eléréséhez. Ez lehetővé teszi, hogy egyetlen kulcspár hitelesítse az összes kiszolgálót. Minden megcélzott kiszolgálófiók azonos a nyilvános kulcs bejegyzése az “autor_kulcsok” fájljaikban. Az 1: N összefüggés az, hogy egy kliens nyilvános kulcsa megjelenhet az “engedélyezett kulcsok” fájlokban, több fiókhoz több szerveren.

Előfordul, hogy a több kliensgépről dolgozó felhasználók ugyanazt a kulcspárt replikálják; általában ez akkor történik, amikor a felhasználó asztali és laptopon dolgozik. Mivel az ügyfélgépek azonos kulcsokkal hitelesítenek, ugyanazok a bejegyzések fognak megegyezni a kiszolgáló “Author_keys” -jében.

Privát kulcsok helye

Kiszolgálói oldalon egy rendszerfolyamat , vagy a démon kezeli az összes bejövő “ssh” bejelentkezési kérelmet. A démon neve “sshd”. A privát kulcs helye az SSL telepítéstől függ, például az Apple a következőt írja: div div = = db20b8e41b “>

Egyáltalán nem igaz.

Az ismert_hosts fájl tartalmazza a gazdagép ujjlenyomatát. Ez nem a távoli gazdagép nyilvános vagy privát kulcsa.

A kulcsukból generálódik, de nyomatékosan NEM maga a kulcs.

Ha SFTP-t ad meg egy olyan címre, amely több (változó) gazdagépre (terhelés kiegyensúlyozott stb.) megoldódhat, hozzá kell adnia az összes lehetséges végpont ujjlenyomatát, különben kezdetben működni fog, majd meghiúsul, amikor a második (vagy azt követő) gazdagépre irányítja.

Megjegyzések

• erm nézd meg az ismert_gazdák fájlt, és hasonlítsd össze a gazdagép ujjlenyomatával, amikor csatlakozol …. Ezzel egy kicsit tisztáznod kell. Ezenkívül a példád pontosan megegyezik, függetlenül attól, hogy ujjlenyomatok vagy nyilvános kulcsok-e az ismert_gazdák fájlban.