Többtényezős hitelesítés beállítása SSH-hoz a CentOS 7 rendszeren

Bevezetés

A hitelesítési tényező egy olyan információ, amely egy művelet elvégzéséhez, például egy rendszerbe való bejelentkezéshez szükséges jogosultság bizonyítására szolgál. A hitelesítési csatorna az a mód, ahogyan a hitelesítési rendszer a faktort átadja a felhasználónak, vagy ahogyan a felhasználónak válaszolnia kell. A jelszavak és a biztonsági zsetonok példák a hitelesítési tényezőkre; a számítógépek és a telefonok példák a csatornákra.

Az SSH alapértelmezés szerint jelszavakat használ hitelesítésre, és a legtöbb SSH-keményítési utasítás ehelyett SSH-kulcs használatát javasolja. Ez azonban még mindig csak egyetlen tényező. Ha egy rossz szereplő feltörte a számítógépét, akkor a kulcsát arra is használhatja, hogy a szervereit is feltörje.

Ezzel az útmutatóval a többfaktoros hitelesítést állítjuk be ennek leküzdésére. A többfaktoros hitelesítés (MFA) egynél több tényezőt igényel a hitelesítéshez, illetve a bejelentkezéshez. Ez azt jelenti, hogy egy rosszfiúnak több dolgot kell kompromittálnia, például a számítógépét és a telefonját is, hogy bejuthasson. A különböző típusú tényezőket gyakran a következőképpen foglalják össze:

1. Az, amit tudsz, például jelszó vagy biztonsági kérdés
2. A, amivel rendelkezel, például hitelesítő alkalmazás vagy biztonsági token
3. A, ami vagy, például ujjlenyomat vagy hang

Egy közös tényező az OATH-TOTP alkalmazás, például a Google Authenticator. Az OATH-TOTP (Open Authentication Time-Based One-Time Password) egy nyílt protokoll, amely egy egyszer használatos jelszót generál, általában egy 6 számjegyű számot, amely 30 másodpercenként újrahasznosításra kerül.

Ez a cikk azt mutatja be, hogyan lehet az SSH hitelesítést egy SSH kulcs mellett egy OATH-TOTP alkalmazással is engedélyezni. A szerverre SSH-n keresztül történő bejelentkezéshez ezután két tényezőre lesz szükség két csatornán keresztül, ezáltal biztonságosabbá téve azt, mint a jelszó vagy az SSH-kulcs önmagában. Ezen kívül áttekintjük az MFA néhány további felhasználási esetét, valamint néhány hasznos tippet és trükköt.

Előfeltételek

A bemutató követéséhez szükséged lesz:

• Egy CentOS 7 szerverre egy sudo nem root felhasználóval és SSH kulccsal, amelyet a Kezdeti szerver beállítása bemutatót követve állíthatsz be.
• Egy okostelefon vagy táblagép, amelyen telepítve van egy OATH-TOTP alkalmazás, például a Google Authenticator (iOS, Android).

1. lépés – A Google PAM telepítése

Ebben a lépésben telepítjük és konfiguráljuk a Google PAM-ot.

A PAM, ami a Pluggable Authentication Module rövidítése, egy Linux rendszereken használt hitelesítési infrastruktúra a felhasználó hitelesítésére. Mivel a Google készített egy OATH-TOTP alkalmazást, készítettek egy PAM-ot is, amely TOTP-okat generál, és teljesen kompatibilis bármely OATH-TOTP alkalmazással, mint például a Google Authenticator vagy az Authy.

Először is hozzá kell adnunk az EPEL (Extra Packages for Enterprise Linux) repót.

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

A következő lépés a PAM telepítése. Lehet, hogy az EPEL kulcs elfogadására szólítanak fel, ha ez az első alkalom, hogy használjuk a repót. Ha egyszer elfogadta, nem fogjuk újra kérni a kulcs elfogadását.

sudo yum install google-authenticator

A PAM telepítése után a PAM-hoz mellékelt segédalkalmazást fogjuk használni a TOTP kulcs generálására annak a felhasználónak, akinek második faktort szeretnénk adni. Ez a kulcs felhasználóról felhasználóra generálódik, nem a rendszer egészére. Ez azt jelenti, hogy minden felhasználónak, aki TOTP auth alkalmazást akar használni, be kell jelentkeznie és futtatnia kell a segédalkalmazást, hogy megkapja a saját kulcsát; nem lehet csak egyszer futtatni, hogy mindenki számára engedélyezze (de a bemutató végén van néhány tipp, hogy sok felhasználó számára beállítsa vagy megkövetelje az MFA-t).

Futtassa az inicializáló alkalmazást.

google-authenticator

A parancs futtatása után néhány kérdést kap. Az első azt kérdezi, hogy a hitelesítési tokenek időalapúak legyenek-e.

Output
Do you want authentication tokens to be time-based (y/n) y

Ez a PAM lehetővé teszi az időalapú vagy a szekvenciális alapú tokenek használatát. A szekvenciális alapú tokenek használata azt jelenti, hogy a kód egy bizonyos ponton kezdődik, majd minden használat után növekszik a kód. Az időalapú tokenek használata azt jelenti, hogy a kód egy bizonyos idő elteltével véletlenszerűen változik. Maradunk az időalapúnál, mert az olyan alkalmazások, mint a Google Authenticator, ezt várják el, ezért a y igennel válaszoljon.

A kérdés megválaszolása után egy csomó kimenet gördül el, köztük egy nagy QR-kód. Ezen a ponton használja a telefonján lévő Authenticator alkalmazást a QR-kód beolvasására, vagy írja be manuálisan a titkos kulcsot. Ha a QR-kód túl nagy a beolvasáshoz, a QR-kód feletti URL-cím segítségével egy kisebb változatot kaphat. Miután hozzáadta, egy hatjegyű kódot fog látni, amely 30 másodpercenként változik az alkalmazásban.

Figyelem: Győződjön meg róla, hogy a titkos kulcsot, az ellenőrző kódot és a helyreállítási kódokat biztonságos helyen, például egy jelszókezelőben rögzíti. A helyreállítási kódok az egyetlen módja a hozzáférés visszaszerzésének, ha például elveszíti a hozzáférést a TOTP alkalmazáshoz.

A fennmaradó kérdések tájékoztatják a PAM működését. Egyenként végigmegyünk rajtuk.

Output
Do you want me to update your "/home/sammy/.google_authenticator" file (y/n) y

Ez a kulcsot és az opciókat a .google_authenticator fájlba írja. Ha nemet mondunk, a program kilép, és semmi sem íródik, ami azt jelenti, hogy a hitelesítő nem fog működni.

Output
Do you want to disallow multiple uses of the same authenticationtoken? This restricts you to one login about every 30s, but it increasesyour chances to notice or even prevent man-in-the-middle attacks (y/n) y

Azzal, hogy itt igennel válaszolunk, megakadályozzuk a visszajátszási támadást azzal, hogy minden kód a használat után azonnal lejár. Ez megakadályozza, hogy egy támadó elkapja az éppen használt kódot, és azzal jelentkezzen be.

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n

Az igen válasz itt legfeljebb 8 érvényes kódot engedélyez egy mozgó négyperces ablakban. Ha nemmel válaszol, akkor egy 1:30 perces mozgó ablakban 3 érvényes kódra korlátozza. Hacsak nem talál problémákat az 1:30 perces ablakkal, a nemleges válasz a biztonságosabb választás.

Output
If the computer that you are logging into isn't hardened against brute-forcelogin attempts, you can enable rate-limiting for the authentication module.By default, this limits attackers to no more than 3 login attempts every 30s.Do you want to enable rate-limiting (y/n) y

A sebességkorlátozás azt jelenti, hogy egy távoli támadó csak bizonyos számú kitalálást kísérelhet meg, mielőtt blokkolnák. Ha korábban nem konfigurálta a sebességkorlátozást közvetlenül az SSH-ban, akkor ezt most megteheti, ami nagyszerű védekezési technika.

Megjegyzés: Miután befejezte ezt a beállítást, ha biztonsági másolatot szeretne készíteni a titkos kulcsáról, akkor másolja a ~/.google-authenticator fájlt egy megbízható helyre. Onnan további rendszerekre telepítheti, vagy a biztonsági mentés után újra telepítheti.

Most, hogy a Google PAM telepítve és konfigurálva van, a következő lépés az SSH konfigurálása a TOTP kulcs használatára. Szólnunk kell az SSH-nak a PAM-ról, majd konfigurálnunk kell az SSH-t a használatára.

2. lépés – Az OpenSSH konfigurálása

Mivel SSH-n keresztül fogjuk elvégezni az SSH módosításokat, fontos, hogy soha ne zárjuk le a kezdeti SSH kapcsolatot. Ehelyett nyissunk egy második SSH munkamenetet a teszteléshez. Ezzel elkerülhetjük, hogy kizárjuk magunkat a kiszolgálóból, ha hibát követtünk el az SSH-konfigurációban. Ha minden működik, akkor nyugodtan bezárhatja az összes munkamenetet.

Kezdésként szerkesszük a sshd konfigurációs fájlt. Itt a nano-t használjuk, ami alapértelmezés szerint nincs telepítve a CentOS-on. Telepíthetjük a sudo yum install nano segítségével, vagy használhatjuk a kedvenc alternatív szövegszerkesztőnket.

sudo nano /etc/pam.d/sshd

Adjuk hozzá a következő sort a fájl aljához.

. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Az utolsó sor végén lévő nullok szó azt mondja a PAM-nak, hogy ez a hitelesítési módszer opcionális. Ez lehetővé teszi, hogy az OATH-TOTP token nélküli felhasználók továbbra is bejelentkezhessenek az SSH kulcsukkal. Amint minden felhasználó rendelkezik OATH-TOTP tokennel, eltávolíthatja a nullok-t ebből a sorból, hogy az MFA kötelezővé váljon.

Mentés és a fájl bezárása.

A következőkben az SSH-t úgy konfiguráljuk, hogy támogassa ezt a fajta hitelesítést. Nyissuk meg az SSH konfigurációs fájlt szerkesztéshez.

sudo nano /etc/ssh/sshd_config

Keresd meg a ChallengeResponseAuthentication sorokat. Kommenteljük ki a no sort, és vegyük ki a no sort.

. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

Mentsük el és zárjuk be a fájlt, majd indítsuk újra az SSH-t a konfigurációs fájlok újratöltéséhez. A sshd szolgáltatás újraindítása nem zárja le a nyitott kapcsolatokat, így nem kockáztatja, hogy ezzel a paranccsal kizárja magát.

sudo systemctl restart sshd.service

Hogy tesztelje, hogy minden működik-e eddig, nyisson egy másik terminált, és próbáljon meg bejelentkezni az SSH-n keresztül. Ha korábban létrehozott egy SSH-kulcsot, és azt használja, észre fogja venni, hogy nem kellett beírnia a felhasználó jelszavát vagy az MFA-ellenőrző kódot. Ez azért van így, mert az SSH-kulcs alapértelmezés szerint felülírja az összes többi hitelesítési lehetőséget. Ellenkező esetben jelszót és ellenőrző kódot kellett volna kérnie.

Ha meg akar győződni arról, hogy az eddigiek működnek, a megnyitott SSH munkamenetben navigáljon a ~/.ssh/ helyre, és nevezze át ideiglenesen az authorized_keys fájlt, majd nyisson új munkamenetet, és jelentkezzen be a jelszavunkkal és az ellenőrző kóddal.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Ha meggyőződött arról, hogy a TOTP token működik, nevezze át az ‘authorized_keys.bak’ fájlt vissza a régi állapotába.

mv authorized_keys.bak authorized_keys

A következő lépésben engedélyeznünk kell az SSH-kulcsot, mint egyik tényezőt, és az ellenőrző kódot, mint másodikat, és meg kell mondanunk az SSH-nak, hogy mely tényezőket használja, és meg kell akadályoznunk, hogy az SSH-kulcs felülírja az összes többi típust.

3. lépés – Az SSH tudatosítása az MFA-ról

Nyissuk meg újra a sshd konfigurációs fájlt.

sudo nano /etc/ssh/sshd_config

Adjuk hozzá a következő sort a fájl alján. Ez megmondja az SSH-nak, hogy mely hitelesítési módszerekre van szükség. Ez a sor közli az SSH-val, hogy szükségünk van egy SSH-kulcsra és egy jelszóra vagy egy ellenőrző kódra (vagy mindháromra).

. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

Mentsük el és zárjuk be a fájlt.

Ezután nyissuk meg újra a PAM sshd konfigurációs fájlt.

sudo nano /etc/pam.d/sshd

Keresd meg a auth substack password-auth sort a fájl tetején. Kommenteljük ki úgy, hogy a sor első karaktereként egy # karaktert adunk hozzá. Ez azt mondja a PAM-nak, hogy ne kérjen jelszót.

. . .#auth substack password-auth. . .

Mentsd el és zárd be a fájlt, majd indítsd újra az SSH-t.

sudo systemctl restart sshd.service

Most próbálj meg újra bejelentkezni a szerverre egy másik munkamenettel. A legutóbbi alkalomtól eltérően az SSH-nak kérnie kell az ellenőrző kódot. Ennek megadása után be lesz jelentkezve. Annak ellenére, hogy nem látja semmilyen jelét annak, hogy az SSH-kulcsát használta, a bejelentkezési kísérlete két tényezőt használt. Ha ellenőrizni szeretné, akkor az SSH parancs után -v-t (a verbose-hoz) adhat hozzá:

Example SSH output\
. . .debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /Users/sammy/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 279Authenticated with partial success.debug1: Authentications that can continue: keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification code:

A kimenet vége felé látni fogja, hogy az SSH használta az SSH kulcsát, majd kéri az ellenőrző kódot. Most már bejelentkezhet SSH-n keresztül az SSH-kulccsal és az egyszer használatos jelszóval. Ha mindhárom hitelesítési típust érvényesíteni szeretné, akkor a következő lépést követheti.

4. lépés – Harmadik tényező hozzáadása (opcionális)

A 3. lépésben a sshd_config fájlban felsoroltuk a jóváhagyott hitelesítési típusokat:

1. publickey (SSH kulcs)
2. password publickey (jelszó)
3. keyboard-interactive (ellenőrző kód)

Bár három különböző tényezőt soroltunk fel, az eddig választott lehetőségekkel csak az SSH kulcsot és az ellenőrző kódot engedélyezik. Ha mindhárom tényezőt (SSH-kulcs, jelszó és ellenőrző kód) szeretnénk, egy gyors módosítással mindhármat engedélyezhetjük.

Nyissuk meg a PAM sshd konfigurációs fájlt.

sudo nano /etc/pam.d/sshd

Keresd meg az előzőleg kikommentált #auth substack password-auth sort, és a # karakter eltávolításával bontsd ki a megjegyzést. Mentsük el és zárjuk be a fájlt. Most ismét indítsa újra az SSH-t.

sudo systemctl restart sshd.service

A auth substack password-auth opció engedélyezésével a PAM most már jelszót fog kérni az SSH-kulcs ellenőrzése és az ellenőrző kód kérése mellett, ami korábban működött. Most már két különböző csatornán keresztül használhatunk valamit, amit ismerünk (jelszó), és két különböző típusú dolgot, amivel rendelkezünk (SSH-kulcs és ellenőrző kód).

Ez idáig ez a cikk azt mutatta be, hogyan engedélyezzük az MFA-t SSH-kulccsal és időalapú egyszeri jelszóval. Ha csak ennyire van szüksége, itt befejezheti. Azonban nem ez az egyetlen módja a többfaktoros hitelesítésnek. Az alábbiakban bemutatunk néhány további módot a PAM modul használatára a többfaktoros hitelesítéshez, valamint néhány tippet és trükköt a helyreállításhoz, az automatizált használathoz és egyebekhez.

1. tipp – A hozzáférés helyreállítása

Amint minden olyan rendszer esetében, amelyet keményít és biztosít, a biztonság kezeléséért ön lesz felelős. Ebben az esetben ez azt jelenti, hogy nem veszítheti el az SSH-kulcsát vagy a TOTP titkos kulcsát, és gondoskodnia kell arról, hogy hozzáférjen a TOTP alkalmazásához. Néha azonban történnek dolgok, és elveszítheti a kulcsok vagy a bejutáshoz szükséges alkalmazások feletti ellenőrzést.

SSH kulcs vagy TOTP titkos kulcs elvesztése

Ha elveszíti SSH kulcsát vagy TOTP titkos kulcsát, a helyreállítás több lépésre bontható. Az első az ellenőrző kód ismerete nélkül történő visszalépés, a második pedig a titkos kulcs megtalálása vagy regenerálása a normál MFA bejelentkezéshez.

A DigitalOcean Droplet-en az ellenőrző kódot generáló titkos kulcs elvesztése után történő bejelentkezéshez egyszerűen használhatja a virtuális konzolt a műszerfalról a felhasználónév és jelszó használatával.

Máskülönben egy sudo hozzáféréssel rendelkező rendszergazdai felhasználóra lesz szüksége; ügyeljen arra, hogy ne engedélyezze az MFA-t ennek a felhasználónak, hanem csak egy SSH kulcsot használjon. Ha Ön vagy egy másik felhasználó elveszíti a titkos kulcsát, és nem tud bejelentkezni, akkor az adminisztrációs felhasználó bejelentkezhet, és segíthet a kulcs helyreállításában vagy regenerálásában bármelyik felhasználónak a sudo használatával.

A bejelentkezés után kétféleképpen lehet segíteni a TOTP-titok megszerzésében:

1. A meglévő kulcs visszaszerzése
2. Új kulcs generálása

Minden felhasználó otthoni könyvtárában a titkos kulcs és a Google Authenticator beállításai a ~/.google-authenticator alatt vannak elmentve. Ennek a fájlnak a legelső sora a titkos kulcs. A kulcs megszerzésének gyors módja a következő parancs végrehajtása, amely megjeleníti a google-authenticator fájl első sorát (azaz a titkos kulcsot). Ezután fogd ezt a titkos kulcsot, és kézzel írd be egy TOTP alkalmazásba.

head -n 1 /home/sammy/.google_authenticator

Ha okkal nem használhatod a meglévő kulcsot (például nem tudod könnyen és biztonságosan megosztani a titkos kulcsot az érintett felhasználóval, vagy a meglévő kulcs kompromittálódott), akkor a ~/.google-authenticator fájlt teljesen eltávolíthatod. Ez lehetővé teszi a felhasználó számára, hogy újra bejelentkezzen egyetlen faktor használatával, feltéve, hogy nem kényszerítette ki az MFA-t a ‘nullok’ eltávolításával az ‘/etc/pam.d/sshd’ fájlban. Ezután a google-authenticator futtatásával új kulcsot generálhat.

A TOTP alkalmazáshoz való hozzáférés elvesztése

Ha be kell jelentkeznie a kiszolgálójára, de nincs hozzáférése a TOTP alkalmazáshoz, hogy megkapja az ellenőrző kódot, akkor továbbra is bejelentkezhet a helyreállítási kódokkal, amelyek a titkos kulcs létrehozásakor jelentek meg. Vegye figyelembe, hogy ezek a helyreállítási kódok egyszer használatosak. Miután az egyiket bejelentkezéshez használták, nem használható újra hitelesítési kódként.

tipp 2 – Hitelesítési beállítások módosítása

Ha a kezdeti konfiguráció után módosítani szeretné az MFA-beállításokat, ahelyett, hogy új konfigurációt generálna a frissített beállításokkal, egyszerűen szerkesztheti a ~/.google-authenticator fájlt. Ez a fájl a következő módon van elrendezve:

<secret key><options><recovery codes>

Az ebben a fájlban beállított opcióknak van egy sora az opciók részben; ha a kezdeti beállítás során egy adott opcióra “nem”-mel válaszolt, a megfelelő sor kikerül a fájlból.

Az alábbi módosításokat végezheti el ebben a fájlban:

• Az időalapú kódok helyett a szekvenciális kódok engedélyezéséhez módosítsa a " TOTP_AUTH sort " HOTP_COUNTER 1-re.
• Az egyetlen kód többszöri használatának engedélyezéséhez távolítsa el a " DISALLOW_REUSE sort.
• A kód lejárati ablakának 4 percre történő meghosszabbításához adja hozzá a " WINDOW_SIZE 17 sort.
• A többszöri sikertelen bejelentkezés (sebességkorlátozás) letiltásához távolítsa el a " RATE_LIMIT 3 30 sort.
• A sebességkorlátozás küszöbértékének módosításához keresse meg a " RATE_LIMIT 3 30 sort, és állítsa be a számokat. Az 3 az eredetiben a próbálkozások számát jelzi egy bizonyos idő alatt, a 30 pedig az időtartamot jelzi másodpercben.
• A helyreállítási kódok használatának letiltásához távolítsa el a fájl alján található öt 8 számjegyű kódot.

Tipp 3 – Az MFA elkerülése egyes fiókok esetében

Előfordulhat olyan helyzet, amikor egyetlen felhasználónak vagy néhány szolgáltatásfióknak (azaz alkalmazások által használt fiókoknak, nem embereknek) SSH-hozzáférésre van szüksége az MFA engedélyezése nélkül. Például egyes SSH-t használó alkalmazások, például egyes FTP-kliensek nem támogatják az MFA-t. Ha egy alkalmazásnak nincs módja az ellenőrző kód bekérésére, a kérés megakadhat, amíg az SSH-kapcsolat le nem jár.

Ha a /etc/pam.d/sshd-ben néhány beállítás helyesen van beállítva, akkor felhasználói alapon szabályozhatja, hogy mely tényezőket használja a rendszer.

Hogy egyes fiókok esetében engedélyezze az MFA-t, míg mások esetében csak az SSH-kulcsot, győződjön meg róla, hogy a /etc/pam.d/sshd-ben a következő beállítások aktívak.

#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Itt a auth substack password-auth ki van kommentálva, mert a jelszavakat le kell tiltani. Az MFA-t nem lehet kikényszeríteni, ha egyes fiókok esetében az MFA-t le kell tiltani, ezért hagyja a nullok opciót az utolsó sorban.

A konfiguráció beállítása után egyszerűen futtassa a google-authenticator minden olyan felhasználónak, akinek szüksége van MFA-ra, és ne futtassa olyan felhasználók esetében, ahol csak SSH kulcsokat fognak használni.

Tipp 4 – A beállítás automatizálása konfigurációkezeléssel

Sok rendszergazda használ konfigurációkezelő eszközöket, például Puppet, Chef vagy Ansible, a rendszerei kezeléséhez. Ha egy ilyen rendszerrel szeretné telepíteni a titkos kulcs beállítását egy új felhasználói fiók létrehozásakor, akkor erre is van módszer.

google-authenticator támogatja a parancssori kapcsolókat, amelyekkel egyetlen, nem interaktív parancsban állíthatja be az összes opciót. Az összes opció megtekintéséhez beírhatja a google-authenticator --help parancsot. Az alábbi parancs mindent az 1. lépésben leírtak szerint állítana be:

google-authenticator -t -d -f -r 3 -R 30 -W

Ez az összes kérdésre válaszol, amit kézzel megválaszoltunk, elmenti egy fájlba, majd kiadja a titkos kulcsot, a QR-kódot és a helyreállítási kódokat. (Ha hozzáadja a -q jelzőt, akkor nem lesz kimenet.) Ha ezt a parancsot automatizált módon használja, győződjön meg róla, hogy a titkos kulcsot és/vagy a helyreállítási kódokat rögzíti és elérhetővé teszi a felhasználó számára.

5. tipp – MFA kényszerítése minden felhasználó számára

Ha minden felhasználó számára ki akarja kényszeríteni az MFA-t még az első bejelentkezéskor is, vagy ha nem szeretne arra hagyatkozni, hogy a felhasználók generálják a saját kulcsaikat, akkor ennek egyszerű módja van. Egyszerűen használhatja ugyanazt a .google-authenticator fájlt minden felhasználó számára, mivel a fájlban nincsenek felhasználó-specifikus adatok tárolva.

Ehhez a konfigurációs fájl kezdeti létrehozása után egy privilegizált felhasználónak minden home könyvtár gyökerébe kell másolnia a fájlt, és a jogosultságait a megfelelő felhasználóra kell módosítania. A fájlt a /etc/skel/ könyvtárba is átmásolhatja, így létrehozásakor automatikusan átmásolódik az új felhasználó home könyvtárába.

Figyelmeztetés: Ez biztonsági kockázatot jelenthet, mivel mindenki ugyanazt a második tényezőt használja. Ez azt jelenti, hogy ha kiszivárog, az olyan, mintha minden felhasználónak csak egy faktora lenne. Vegye ezt figyelembe, ha ezt a megközelítést szeretné használni.

Egy másik módszer a felhasználó titkos kulcsának létrehozásának kikényszerítésére egy bash szkript használata, amely:

1. Elkészít egy TOTP tokent,
2. felszólítja, hogy töltse le a Google Authenticator alkalmazást és olvassa be a megjelenő QR-kódot, és
3. Futtatja a google-authenticator alkalmazást a felhasználó számára, miután ellenőrizte, hogy a .google-authenticator fájl létezik-e már.

Hogy a szkript biztosan lefusson, amikor a felhasználó bejelentkezik, nevezd el .bash_login-nek, és helyezd el az otthoni könyvtáruk gyökerében.

Következtetés

Ezzel a két tényezővel (SSH kulcs + MFA token) két csatornán keresztül (a számítógéped + a telefonod) nagyon megnehezítetted, hogy egy külső ügynök SSH-n keresztül brutális erőszakkal bejusson a gépedre, és jelentősen megnövelted a géped biztonságát.