Az SSH-kulcs jelmondata a fájlt védi, nem az útvonalat

Egy régi laptop biztonsági mentési lemeze még mindig tartalmaz egy privát SSH-kulcsot, és valaki azt kérdezi, védi-e a VPN. Nem védi, és soha nem is védte. A VPN két hálózat közötti útvonalat véd; a jelmondat a fájlt védi; az ügynök egy futó munkamenetet véd. Három különböző mechanizmus, három különböző hiba mód, és egy ellopott másolat csak az első kettővel törődik.

A jelmondat a fájlhoz tartozik

Az SSH-kulcs jelmondata nyugalmi állapotban titkosítja a privát kulcs anyagát. Ez nem a kiszolgálónak küldött fiókjelszó, és nem a VPN-hez való csatlakozáshoz használt hitelesítő adat. Az összekeverésük olyan változtatásokhoz vezet, amelyek nem kezelik a kitettséget.

Az OpenSSH ssh-keygen kézikönyve a jelmondatok kezelését tárgyalja, beleértve a -p kapcsolót, amely új jelmondatot állít be egy már létező kulcson.

Létező kulcs esetén a parancs formája egyszerű, és újraírja a fájlt:

ssh-keygen -p -f ~/.ssh/id_ed25519

Használja a kulcs tulajdonosának jóváhagyott karbantartási és helyreállítási folyamatát, mert ez írás, nem vizsgálat. Ne tegye közzé a privát fájlt, és ne tegyen valódi jelmondatot megosztott parancssorba. A jelmondat módosítása nem titkosítja újra a korábban készült másolatot. Jegyezze fel a régi másolat helyét a jegyben, hogy a tulajdonos eldönthesse, megsemmisíti-e.

A másolat túlél a laptopot és az alagutat

Miután egy kulcsfájl lemásolódott, a laptop élő VPN-kapcsolata már semmit sem mond róla. Az számít, mennyire jól védett maga a fájl, és mely kiszolgálók bíznak még a hozzá tartozó nyilvános kulcsban.

Az aktuális fájl jelmondatának módosítása nem érinti a másolatot, és nem távolítja el ugyanazt a nyilvános kulcsot egy kiszolgáló authorized_keys fájljából. A visszavonás és az újratitkosítás külön műveletek.

Tehát kezelje a kiszivárgott privát kulcsot identitáseseményként, nem hálózati eseményként. Távolítsa el vagy cserélje le az elfogadott kulcsot azokon a kiszolgálókon és azon a regisztrációs folyamaton keresztül, amelyek birtokolják. A VPN leállítása egy útvonalat korlátoz egy pillanatban; ez nem visszavonás.

A feloldás az ügynökbe helyezi a titkot

Az ügynök visszafejtett identitásokat tárol a későbbi hitelesítéshez, így a felhasználónak nem kell minden kapcsolatnál újra begépelnie a jelmondatot. Ez kényelmi funkció, saját biztonsági határral.

Az ssh-agent a -t kapcsolójával korlátozhatja, mennyi ideig marad betöltve egy identitás, és egy identitásra vonatkozó beállítás felülbírálhatja ezt a korlátot. A szabályzatot a ténylegesen futtatott ügynökre válassza, ahelyett hogy feltételezné, a VPN leválasztása minden betöltött kulcsot elfelejt.

A kulcs feloldása után kompromittált folyamat más probléma, mint egy ellopott titkosított fájl. Az ügynök továbbítása egy másik gazdagépre átruházza a hitelesítési képességet a kulcsfájl másolása nélkül, ezért csak jóváhagyott igény esetén engedélyezze.

Sorolja fel, mit tart éppen az ügynök a változtatás előtt és után:

ssh-add -l

A felügyelet nélküli feladatoknak saját terv kell

Egy ütemezett feladat nem tud válaszolni egy kérésre. Jóváhagyott gépi hitelesítő adatokra van szüksége, és a feloldási titoknak a kulccsal azonos könyvtárban tartása, ugyanazon fiók számára olvashatóan, nem hoz létre második határt.

Működjön együtt a szolgáltatás tulajdonosával a támogatott titokkiszolgálásban vagy a hardveralapú működésben, és fedje le a megújítást, a hibát és a helyreállítást. Az, hogy ember legyen a billentyűzetnél, megváltoztatja a hiba képét egy olyan gazdagéphez képest, amely felügyelet nélkül indul.

Tartsa meg a kiszolgáló gazdagép-identitás ellenőrzését és fiókkorlátait is. A VPN-útvonal privát utat ad; nem bizonyítja, hogy minden elérhető SSH-figyelő az a gazdagép, amelyet szánt. Rögzítse a figyelőt és a gazdagépkulcs ujjlenyomatát ugyanabban a leltárban, mint magát a kulcsot.

A határokat külön ellenőrizze

Tesztelje minden határt a saját kérdésével. Megnyílik a fájl a jelmondat nélkül? Megtartja-e az ügynök az identitást a leválasztás után? Elfogadja-e a kiszolgáló még a nyilvános kulcsot?

Két parancs válaszol az elsőre és a harmadikra:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

Rögzítse a fájl védelmét, az engedélyezett kulcshasználatot és a kiszolgáló oldali eltávolítást három külön tételként. Az alagút, a jelmondat és az ügynök egyaránt a kapcsolat más-más részét őrzi, és csak az egyikük szól a hálózatról.