Nemrég megváltoztattuk egy felhasználó jelszavát Linuxban, amikor hibát észleltünk: „Authentication Token Manipulation Error”.

A normál passwd parancsot használtuk a jelszó megváltoztatásához, és ez ezt a hibát adta, és a jelszó nem változott.

Sudo passwd my_user_name Felhasználó jelszavának megváltoztatása my_user_name felhasználó jelszavának módosítása tecmint (jelenlegi) UNIX jelszó: passwd: Hitelesítési token manipulációs hiba passwd: jelszó változatlan

Auth token manipulációs hiba javítása az Ubuntuban

„Authentication Token Manipulation Error” azt jelenti, hogy a jelszómódosítás valamilyen okból meghiúsult.

Ennek több oka is lehet. Egyszerű esetekben magában a kimenetben láthatja a probléma kiváltó okát. Ha például nem adott meg jelszót, akkor azt hibaüzenetként kell látnia:

Nincs megadva jelszó passwd: Hitelesítési jogkivonat manipulációs hiba passwd: jelszó változatlan

Hasonlóképpen, ha a jelszó újbóli megadása nem egyezik, akkor ez az információ is megjelenik:

Sajnáljuk, a jelszavak nem egyeznek: passwd: Hitelesítési token manipulációs hiba passwd: jelszó változatlan

Ez egyszerű, mert tudja, mi okozta a problémát, és ennek alapján megteheti a helyesbítő lépéseket. De lehet, hogy nem mindig lesz szerencséje, mert bizonyos esetekben nem fog látni semmit hasznos információ, csak hiba.

Nézzünk meg néhány ilyen esetet, és javítsuk ki a problémát.

1. módszer

Ha ismeri a Linux könyvtárszerkezetét, tudja, hogy az /etc/shadow könyvtár a jelszót titkosított formátumban tárolja a felhasználókkal és jelszavaikkal kapcsolatos egyéb információkkal együtt.

Ezért meg kell győződnie arról, hogy rendelkezik-e jogosultsággal a fájl olvasásához és írásához. Mivel rootként fogja megváltoztatni a jelszót, ennek a fájlnak a root számára olvasási és írási jogosultsággal kell rendelkeznie.

Ha nem, akkor be kell állítania a megfelelő engedélyt:

sudo chmod 640 /etc/shadow

2. módszer

Az 1. módszer a legtöbb esetben működik. De a mi esetünkben újra kellett csatolnunk a gyökérpartíciót olvasási és írási jogosultsággal. Megpróbáltuk visszaállítani az adminisztrátori jelszót az Ubuntuban.

Mount -rw -o remount /

Néhány ritka esetben előfordulhat, hogy a lemez annyira megtelik, hogy nem tudja módosítani az /etc/shadow fájlt. De ha ez a helyzet, akkor sok más problémába ütközik.

Neked bevált?

Megosztottuk azt, ami nekünk bevált, és csak remélni tudjuk, hogy neked is bevált. Megcsinálta? Melyik módszer vált be nálad? Említse meg a megjegyzésekben.

Linux- ez egy többfelhasználós környezet, és ahhoz, hogy a felhasználó elkezdjen dolgozni a rendszerben, át kell mennie a hitelesítési eljáráson. PAM (Csatlakoztatható hitelesítő modulok) egy olyan rendszer (mechanizmus), amely a hitelesítési eljárások végrehajtásáról gondoskodik. Advent előtt PAM, a hitelesítéshez valahogyan kapcsolódó programok fejlesztőinek a meglévő hitelesítési mechanizmusokhoz kellett igazítaniuk programjukat. Ennek megfelelően, ha a hitelesítési mechanizmusok megváltoztak, akkor módosítani kellett az azokat használó programokat. Ezért egy rendszert fejlesztettek ki PAM, amely egy „réteg” a programok és a hitelesítési mechanizmusok között. Vagyis most a hitelesítő programok (például a program Belépés) csak a rendszerrel működhet PAM. A program továbbítja PAM paraméterek (például bejelentkezési név és jelszó), és azt (a programot) már nem „érdekli”, hogy milyen hitelesítési módszer van megvalósítva a rendszerben - jelszó vagy intelligens kártya hitelesítés vagy más módszer. További munkák PAMés sikert vagy kudarcot ad vissza a programnak.

Nézzük a rendszert PAM több. A rendszer által végrehajtott fő funkciók, műveletek vagy feladatok PAM- négy csoportra osztva, amelyeknek konkrét neveik vannak:

csoport auth- ezek közvetlenül a hitelesítéshez kapcsolódó műveletek. Vagyis olyan cselekvések vagy funkciók, amelyek lehetővé teszik annak meghatározását, hogy te vagy. Ez lehet jelszavas hitelesítés, intelligens kártya hitelesítés, biometrikus hitelesítés (ujjlenyomat stb.) és mások.

csoport fiókot- Ezek a számlakezeléssel kapcsolatos műveletek. Például még ha hitelesített is a rendszerben, akkor az Ön fiókot A nap bizonyos szakaszaiban munkavégzési tilalmat rendelhet el. Vagy engedélyezze a bejelentkezést konzol módban, de tiltsa be a grafikus módban. Stb.

csoport ülés- ennek a csoportnak a tevékenységei biztosítják a felhasználó számára a munkához szükséges erőforrásokat. A legegyszerűbb példa a könyvtárak csatlakoztatásának engedélyezése.

csoport Jelszó- olyan műveletek, amelyek megváltoztatják a felhasználó hitelesítési adatait. Leggyakrabban ezek a felhasználói jelszavak kezelését célzó műveletek.

Mindezek a műveletek vagy eljárások (funkciók) külön modulokként valósulnak meg, amelyek a katalógusban találhatók /lib/security/. Vagyis azt mondhatjuk, hogy vannak csoportos modulok auth, csoport modulok fiókot stb. Ennek megfelelően a rendszer PAM moduláris, és ha biometrikus hitelesítést kell végrehajtania, akkor csak telepítenie kell egy modult, amely végrehajtja ezt az eljárást.

Alapvető konfigurációs fájl rendszerek PAM egy fájl /etc/pam.conf. Kivéve a fájlt /etc/pam.conf, beállítások PAM könyvtárfájlokban tárolva /etc/pam.d/. A könyvtár belsejében vannak szöveges fájlok amelyek egy műveletsort (egy bizonyos algoritmust) tartalmaznak az olyan programok számára, amelyek azt használják PAM. Például fájl /etc/pam.d/login tartalmazza a rendszer működési algoritmusát PAM a programhoz Belépés, és a fájl /etc/pam.d/passwd a programhoz passwd.

Először fontolja meg a fájlformátumot /etc/pam.conf. A fájl sorokból áll. A fájl állhat egy sorból, vagy állhat több sorból, amelyek egymást követő műveletek láncát alkotják. Minden sor egy ilyen lánc (algoritmus) egy szabályát vagy egy lépését írja le. A sor négy mezőből áll. Az első mező annak a programnak a neve, amelyhez ez a lépés tartozik. A második mező a művelet típusa ( auth, fiókot, ülés, Jelszó). A harmadik mező az a mező, amelyben a rendszer viselkedése be van állítva. PAM ennek a lépésnek a befejezése után az algoritmus ezen lépésében (a kérdéssel az alábbiakban részletesebben foglalkozunk). A negyedik mező a modulfájl neve. Ezenkívül a sor tartalmazhat néhány, a modulnak átadott paramétert.

A fájlok szerkezete a könyvtárban /etc/pam.d/, ugyanaz. Az egyetlen különbség az első mező – a név – hiánya. Mivel a program neve magából a fájl nevéből származik. Nézzünk egy példát egy ilyen fájlra. Nevezzük el testpam.

Nézzük az első sort. Terület auth azt mondja, hogy az első lépés a hitelesítés lesz. A harmadik mező az a modul, amely elvégzi a hitelesítést és visszaadja a végrehajtás eredményét. BAN BEN ezt a példát modult pam_rootok.so ellenőrzi, hogy a fiók root-e ( gyökér). Ha igen, akkor sikert (igaz) ad vissza, ha nem, akkor hibát vagy kudarcot (hamis) ad vissza. A második mező a reakció vagy az eredmény hatása a lánc egészére.

A reakció négyféle lehet: kívánt, szükséges, választható, elegendő. A vonal példáján auth elegendő pam_rootok.so Lássuk, mit jelentenek ezek az értékek.

Ha a második mező értéke szükséges, akkor ez azt jelenti, hogy ha a modul pam_rootok.so hibával végződött, majd a fájl további végrehajtása testpam megszakadt és a rendszer PAM hibát ad vissza az alkalmazásnak. Ha a modul pozitív eredményt adott, akkor a lánc végrehajtása folytatódik.

kívánt hasonló szükséges. Ha a modul pam_rootok.so akkor hibával végződött PAM szintén hibát ad vissza, de miután a többi modul elkészült, vagyis a lánc nem szakad meg. Ha a modul pozitív eredményt adott, akkor a lánc végrehajtása folytatódik.

elegendő- ha a modul pam_rootok.so visszatért a siker, majd a rendszer PAM sikert ad vissza az alkalmazásnak, és a lánc további végrehajtása megszakad. Ha nem sikerül, akkor a lánc folytatódik.

választható- ez a paraméter semmilyen módon nem befolyásolja a lánc menetét. Azokhoz a modulokhoz van megadva, amelyek nem hajtanak végre ellenőrzési műveleteket. Ha a fájl csak sorokat tartalmaz a paraméterrel választható, Azt PAM visszaadja az alkalmazás sikerét.

További részletek a rendszerről PAMés egy adott könyvtár célja a http://kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html címen található. Most végezzünk egy kis gyakorlati gyakorlatot, amely lehetővé teszi a rendszer működésének jobb megértését. PAMés hogyan kell konfigurációs fájlokat írni.

Menjen a könyvtárba /etc/pam.d/. Másolja a fájlt su a saját könyvtárába (hogy vissza tudja állítani), és törölje a fájlt su címtárból /etc/pam.d/. Próbálja most futtatni a parancsot su a terminálban, hogy szuperfelhasználói módba váltson. A jelszó megadása után a rendszer hitelesítési hibát ad, mivel nincs konfigurációs fájl a programhoz su.

Hozzon létre egy fájlt /etc/pam.d/sués írd bele a következő sort:

Modul pam_deny.so mindig hibát ad vissza. mi lesz az eredmény? Jelölje be. És ha lecseréled szükséges tovább kívánt?
Most írjuk be a következő szabályt a fájlba:

Modul pam_wheel.so sikert ad vissza, ha a felhasználói fiók egy csoporthoz tartozik kerék. Ha most megpróbálja futtatni a parancsot su, akkor azonnal hibával ér véget. Vagyis most a parancs su csak olyan felhasználók hajthatják végre, akik a csoport tagjai kerékés ismerje a fiók jelszavát gyökér. Ha létrehoz egy csoportot kerékés adja hozzá a fiókját, majd a parancsot su működni fog.

Íme egy másik példa:

Próbáljon meg válaszolni arra, hogy ki tudja sikeresen végrehajtani a parancsot suÉs mit kell ehhez tenni?
Ezzel befejeződik a gyakorlati gyakorlat (ne felejtse el visszatenni az eredeti su fájlt).

Szeretném ismét hangsúlyozni, hogy az /etc/pam.d/ könyvtárban csak a rendszert használó fájlokhoz lehet konfigurációs fájlokat létrehozni. PAM. Például, ha létrehoz egy fájlt /etc/pam.d/ls madzaggal hitelesítési szükséges pam_deny.so, majd a parancsot ls továbbra is végrehajtódik, mert nem használja a rendszert PAM. A parancs segítségével ellenőrizheti, hogy egy parancs használja-e a PAM rendszert ldd, amely paraméterként kerül átadásra teljes útvonal a parancsfájlba. Például:

Kulcsszó kompat csak azt „mondja”, hogy a rendszert hitelesítési rendszerként fogják használni PAM.

És tovább. Legyen óvatos, amikor kísérletezik PAM. Tudatlanságból vagy hanyagságból könnyen blokkolhatja rendszerét. Ezért mielőtt bármit módosítana, mindenképpen mentse el az eredeti konfigurációs fájlokat, hogy probléma esetén gyorsan visszaállíthassa azokat.

A kéttényezős hitelesítés (2FA) egy olyan hitelesítési módszer, amelynél több információra van szükség a fiókba vagy eszközbe történő bejelentkezéshez. A felhasználónév és jelszó kombinációja mellett a 2FA megköveteli a felhasználótól a belépést További információ, mint például alkalmi jelszó(OTP, például hatjegyű ellenőrző kód).

Általában a 2FA megköveteli a felhasználótól különböző típusú információk megadását:

• Valami, amit a felhasználó tud (például egy jelszó)
• Valami, amivel a felhasználó rendelkezik (például egy speciális alkalmazás - hitelesítő által generált megerősítő kód).

A 2FA a többtényezős hitelesítés (MFA) egy részhalmaza. Az MFA módszer amellett, hogy mit tud és rendelkezik a felhasználóval, megkövetel valamit, ami az. Ezek biometrikus adatok: ujjlenyomat vagy hangfelismerés stb.

A 2FA segít egy adott szolgáltatás vagy eszköz hitelesítési folyamatának biztonságossá tételében: a támadónak még akkor is szüksége lesz egy biztonsági kódra, ha a jelszót feltörték, és ehhez hozzá kell férni a felhasználó hitelesítő alkalmazást futtató eszközéhez. Emiatt számos online szolgáltatás lehetőséget kínál a 2FA engedélyezésére a felhasználói fiókok számára a fiókok hitelesítési szintű biztonságának növelése érdekében.

Ebből az oktatóanyagból megtudhatja, hogyan állíthatja be a 2FA-t a Google PAM modul használatával egy nem root felhasználó számára az Ubuntu 18.04 rendszeren. Mivel a 2FA-t nem root felhasználó számára állítja be, zárolás esetén továbbra is hozzáférhet a számítógéphez a root fiókjából. A kézikönyvben található utasítások elég általánosak ahhoz, hogy kiszolgálókra és asztali telepítésekre egyaránt alkalmazhatók legyenek, mind helyi, mind távoli.

Követelmények

• Ubuntu 18.04 szerver vagy asztali környezet. Az Ubuntu 18.04 kiszolgálót a következővel kell konfigurálni.
• A mobileszközre telepített hitelesítő (például Google Authenticator vagy Authy). Ezzel biztonsági QR-kódokat szkennelhet be.

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

A 2FA beállításához az Ubuntu 18.04 rendszeren telepítenie kell a Google PAM modult Linuxhoz. A Pluggable Authentication Module (PAM) a Linux által használt hitelesítési mechanizmus. A Google PAM modul lehetővé teszi a felhasználó számára a 2FA-val történő hitelesítést a generált használatával Google kódok OTP.

Először jelentkezzen be a szerver kezdeti beállítása során létrehozott sudo felhasználóként:

ssh [e-mail védett] _szerver_ip

Frissítse az Ubuntu Package Indexet a letöltéshez legújabb verzió hitelesítő:

sudo apt-get frissítés

A tárolók frissítése után telepítse a PAM modul legújabb verzióját:

sudo apt-get install libpam-google-authenticator

Ez egy nagyon kicsi csomag, függőségek nélkül, így néhány másodpercet vesz igénybe a telepítés. A következő részben beállítjuk a 2FA-t a sudo felhasználó számára.

2. lépés: A kéttényezős hitelesítés beállítása

Most, hogy telepítette a PAM modult, futtassa azt, hogy QR-kódot generáljon a bejelentkezett felhasználó számára. Ez generálja a kódot, de az Ubuntu környezetnek nincs szüksége 2FA-ra, amíg nem engedélyezi.

Futtassa a google-authenticator parancsot a PAM modul elindításához és konfigurálásához:

google-hitelesítő

A parancs feltesz néhány konfigurációs kérdést. Először megkérdezi, hogy szeretné-e a tokenek időkorlátozását. Az időzített hitelesítési tokenek egy bizonyos idő után lejárnak (a legtöbb rendszeren az alapértelmezett 30 másodperc). Az időzített tokenek biztonságosabbak, mint a nem időzített tokenek, és a legtöbb 2FA implementáció ezeket használja. Itt bármelyik lehetőséget választhat, de javasoljuk, hogy válassza az Igen lehetőséget, és használja az időkorlátos hitelesítési tokeneket:

Szeretné, hogy a hitelesítési tokenek időalapúak legyenek (i/n) y

Ha y-t válaszol erre a kérdésre, számos kimeneti sort fog látni a konzolon:

• QR-kód: Ezt a kódot kell beolvasni a hitelesítő alkalmazással. A beolvasás után az alkalmazás 30 másodpercenként új OTP-t generál.
• titkos kulcs: ez alternatív módon hitelesítési alkalmazás beállításai. Ha olyan alkalmazást használ, amely nem támogatja a QR-beolvasást, megadhat egy titkos kulcsot a hitelesítő beállításához.
• Ellenőrző kód: Ez az első hatjegyű kód, amelyet ez a QR-kód generál.
• Sürgősségi scratch kódok. ezek egyszeri tokenek (más néven tartalék kódok), lehetővé teszik a 2FA hitelesítés átadását, ha elveszíti a hitelesítő eszközt. Tartsa ezeket a kódokat biztonságos helyen, hogy elkerülje a fiók felfüggesztését.

Miután konfigurálta a hitelesítő alkalmazást, és biztonságos helyen elmentette a biztonsági kódokat, a program megkérdezi, hogy kívánja-e frissíteni a konfigurációs fájlt. Ha az n lehetőséget választja, újra le kell futtatnia a telepítőprogramot. Írja be az y-t a változtatások mentéséhez és a folytatáshoz:

Szeretné, hogy frissítsem a "~/.google_authenticator" fájlt (i/n) y

Ezután a program megkérdezi, hogy szeretné-e megakadályozni a hitelesítési kódok többszöri használatát. Alapértelmezés szerint minden kódot csak egyszer használhat fel, még akkor is, ha a létrehozása óta nem telt el 30 másodperc. Ez a legbiztonságosabb választás, mert megakadályozza, hogy egy támadó visszajátssza a támadásokat, akiknek valahogy sikerült megszerezniük az Ön használt ellenőrző kódját. Emiatt jobb, ha megtiltja a kódok többszöri használatát. Válasz y, hogy megakadályozza ugyanazon token többszöri használatát:

Meg akarja tiltani ugyanazon hitelesítés többszöri használatát?
jelképes? Ez körülbelül 30 másodpercenként egy bejelentkezésre korlátozza, de ez növekszik
esélye, hogy észrevegye vagy akár megakadályozza a középen tartó támadásokat (i/n) y

Ezután meg kell adnia, hogy el kívánja-e fogadni a hitelesítési tokeneket a normál lejárati dátumuk után. A kódok nagyon időérzékenyek, ezért előfordulhat, hogy nem működnek, ha az eszközei nincsenek szinkronizálva. Ez az opció megkerüli ezt a problémát azáltal, hogy meghosszabbítja az alapértelmezett ellenőrző kódok lejárati idejét, így a hitelesítési kódok mindenképpen elfogadásra kerülnek (még akkor is, ha eszközei átmenetileg nincsenek szinkronban). A legjobb, ha minden eszközén szinkronizálja az időt, mert az igen válasz némileg csökkenti a rendszer biztonságát. Válaszoljon n erre a kérdésre, hogy a token ne járjon le:

Alapértelmezés szerint a tokenek 30 másodpercig jók, és kompenzálják
lehetséges időeltolódás a kliens és a szerver között, extrát engedélyezünk
token az aktuális idő előtt és után. Ha problémákat tapasztal a szegényekkel
időszinkronizálás, növelheti az ablakot az alapértelmezettről
mérete 1:30 perctől körülbelül 4 percig. Akarja-e ezt (i/n) n

Az utolsó kérdés az, hogy szeretné-e korlátozni a bejelentkezési kísérletek számát. Ez megakadályozza, hogy a felhasználó 30 másodpercen belül háromnál több sikertelen bejelentkezési kísérletet tegyen, ami növeli a rendszer biztonságát. Engedélyezze ezt a korlátozást az y válaszával:

Ha a számítógép, amelyre bejelentkezik, nincs megvédve a brute force ellen
bejelentkezési kísérletek esetén engedélyezheti a sebességkorlátozást a hitelesítési modul számára.
Alapértelmezés szerint ez 30 másodpercenként legfeljebb 3 bejelentkezési kísérletre korlátozza a támadókat.
Engedélyezni szeretné a sebességkorlátozást (i/n) y

A PAM modul segítségével 2FA kódokat állított be és generált. Most engedélyeznie kell a 2FA-t a környezetében.

3. lépés: A 2FA aktiválása Ubuntuban

A Google PAM modul most 2FA kódokat generál a felhasználó számára, de az Ubuntu még nem tudja, hogy a kódokat kell használnia a hitelesítési folyamat során. Ezen a ponton frissítenie kell az Ubuntu konfigurációját, hogy az alapvető hitelesítésen kívül engedélyezze a 2FA tokenek támogatását.

Itt két mód van:

1. Minden alkalommal megkövetelheti a kéttényezős hitelesítést, amikor egy felhasználó bejelentkezik, és minden alkalommal, amikor egy felhasználó sudo-jogokat kér.
2. A bejelentkezés során csak 2FA-t kérhet, akkor csak a felhasználó jelszavát kell kérni a sudo jogok kéréséhez.

Az első lehetőség ideális egy általános környezetben, ahol kívánatos minden olyan műveletet biztosítani, amely sudo jogosultságot igényel. A második megközelítés praktikusabb helyi asztali környezetben, ahol Ön az egyetlen felhasználó a rendszeren.

jegyzet V: Ha engedélyezi a 2FA-t egy távoli gépen, amelyet SSH-n keresztül ér el, akkor a folytatás előtt el kell végeznie a kézikönyv második és harmadik lépését. A kézikönyv többi lépése az összes Ubuntu-telepítésre vonatkozik, de a távoli környezetekhez ez szükséges további beállítások hogy az SSH szolgáltatás tudjon a 2FA-ról.

Ha nem SSH-t használ a hozzáféréshez az Ubuntu telepítése, azonnal folytathatja a kézikönyv többi lépését.

2FA prompt bejelentkezéskor és sudo elevációkor

Ahhoz, hogy a rendszer 2FA-t használjon a bejelentkezéskor és a későbbi jogosultság-kiterjesztési kérelmek során, módosítania kell az /etc/pam.d/common-auth fájlt úgy, hogy a meglévő fájl végéhez egy sort ad.

A közös hitelesítési fájl a rendszer összes hitelesítési mechanizmusára vonatkozik, függetlenül a használt környezettől. Ez vonatkozik azokra a hitelesítési kérésekre is, amelyek a felhasználó bejelentkezése után fordulnak elő, például amikor egy terminálról új csomagot telepítenek a sudo-jogok kérésére.

Fájl megnyitása:

sudo nano /etc/pam.d/common-auth

Add hozzá a fájl végéhez:

...
# és itt van még több csomagonkénti modul (a "További" blokk)
munkamenet szükséges pam_unix.so

Ez a vonal lehetővé teszi, hogy az Ubuntu hitelesítési rendszere támogassa a 2FA-t, amikor bejelentkezik a Google PAM modullal. A nullok opció lehetővé teszi, hogy a meglévő felhasználók bejelentkezzenek akkor is, ha nem állítottak be 2FA hitelesítést a fiókjukhoz. Más szavakkal, azoknak a felhasználóknak, akik beállították a 2FA-t, meg kell adniuk egy hitelesítési kódot a következő bejelentkezéskor, míg azok a felhasználók, akik nem futtatták le a google-authenticator parancsot, alapértelmezett hitelesítő adataikkal jelentkezhetnek be, amíg be nem állítják. 2FA.

Mentse és zárja be a fájlt.

2FA felszólítás csak bejelentkezéskor

Ha azt szeretné, hogy a 2FA csak asztali környezetbe való bejelentkezéskor legyen kérve, akkor módosítania kell a használt asztali kezelő konfigurációs fájlját. A konfigurációs fájl neve általában megegyezik az asztali környezet nevével. Például a gdm konfigurációs fájlja (az Ubuntu 16.04 óta az alapértelmezett Ubuntu környezet) az /etc/pam.d/gdm.

Fej nélküli szerver esetén (ami virtuális szerver), ehelyett az /etc/pam.d/common-session fájlt kell szerkesztenie. Nyissa meg a megfelelő fájlt a környezettől függően:

sudo nano /etc/pam.d/common-session

Adja hozzá a kiemelt sorokat a fájl végéhez:

#
# /etc/pam.d/common-session – a munkamenethez kapcsolódó modulok, amelyek minden szolgáltatásban közösek
#
...
# # és itt van még több csomagonkénti modul (a "További" blokk)
munkamenet szükséges pam_unix.so
munkamenet opcionális pam_systemd.so
# pam-auth-update konfiguráció vége
hitelesítés szükséges pam_google_authenticator.so nullok

Az Ubuntu mostantól 2FA-t igényel, amikor a felhasználó parancssoron keresztül csatlakozik a rendszerhez (helyileg vagy távolról SSH-n keresztül), de ez nem vonatkozik a sudo-val futtatott parancsokra.

Az Ubuntut úgy konfiguráltad, hogy támogassa a 2FA-t. Itt az ideje, hogy tesztelje a konfigurációt, és győződjön meg arról, hogy amikor bejelentkezik az Ubuntu rendszerébe, a rendszer biztonsági kódot kér.

4. lépés: Kéttényezős hitelesítés tesztelése

Korábban a 2FA-t úgy állította be, hogy 30 másodpercenként generáljon kódokat. Most próbáljon meg bejelentkezni az Ubuntu környezetébe.

Először jelentkezzen ki, majd jelentkezzen be az Ubuntu környezetébe:

ssh [e-mail védett] _szerver_ip

Ha jelszó alapú hitelesítést használ, a rendszer kérni fogja a felhasználó jelszavát:

jegyzet: Ha tanúsítványhitelesítést használ a távoli kiszolgálón, a rendszer nem kér jelszót. A kulcs automatikusan átkerül és elfogadásra kerül. Csak egy megerősítő kódot kell megadnia.

Írja be a jelszót, amely után a rendszer kéri a 2FA kód megadását:

Ellenőrző kód:

Ezt követően bejelentkezik:

[e-mail védett] _server_ip: ~#

Ha a 2FA csak bejelentkezéskor volt engedélyezve, akkor többé nem kell 2FA ellenőrző kódokat megadnia, amíg a munkamenet véget nem ér, vagy manuálisan ki nem jelentkezik.

Ha engedélyezte a 2FA-t a közös hitelesítési fájlon keresztül, akkor minden sudo-jogosultságra vonatkozó kérésnél meg kell adnia azt is:

[e-mail védett] _server_ip: ~# sudo -s
sudo jelszó a 8host számára:
Ellenőrző kód:
[e-mail védett] _server_ip:

Ellenőrizte, hogy a 2FA konfiguráció megfelelően működik. Ha valami hiba történt, és a rendszer nem kért ellenőrző kódokat, lépjen vissza az útmutató harmadik részéhez, és győződjön meg róla, hogy szerkesztette helyes fájl Ubuntu hitelesítés.

5: A 2FA blokkolásának megakadályozása

Abban az esetben, ha mobileszköze elveszik vagy megsemmisül, fontos, hogy rendelkezzen biztonsági mentési módszerekkel a 2FA-képes fiókjához való hozzáférés visszaállításához. Amikor először állítja be a 2FA-t, több lehetőség közül választhat a hozzáférés visszaszerzésére a blokkolás után:

• megment biztonsági mentés titkos konfigurációs kódjait egy biztonságos helyen. Megteheti manuálisan is, de egyes hitelesítő alkalmazások, például az Authy kódmentési funkciókat biztosítanak.
• Mentse el a helyreállítási kódokat egy biztonságos helyen, a 2FA-kompatibilis környezeten kívül, amely szükség esetén elérhető.

Ha valamilyen okból nem fér hozzá a biztonsági mentési lehetőségekhez, megpróbálhatja más módon visszaállítani a hozzáférést a helyi környezethez vagy a 2FA-támogatással rendelkező távoli szerverhez.

6. lépés: A helyi környezethez való hozzáférés visszaállítása (opcionális)

Ha fizikailag hozzáfér a géphez, akkor a 2FA letiltásához helyreállítási módba indíthat. A helyreállítási mód egy céltípus (hasonló a futási szinthez) a Linuxban, amelyet adminisztrációs feladatok végrehajtására használnak. A helyreállítási módba való belépéshez módosítania kell néhány beállítást a GRUB-ban.

A GRUB eléréséhez először indítsa újra a számítógépet:

Amikor megjelenik a GRUB menü, győződjön meg arról, hogy az Ubuntu bejegyzés ki van jelölve. Ez az alapértelmezett 18.04-es telepítési név, de más lehet, ha manuálisan módosította a telepítés után.

Ezután nyomja meg a e billentyűt a billentyűzeten a GRUB konfiguráció szerkesztéséhez a rendszer indítása előtt.

Menjen a megjelenő fájl végére, és keresse meg a linux-szal kezdődő és $vt_handoff karakterrel végződő sort. Menjen ennek a sornak a végére, és adja hozzá a systemd.unit=rescue.target. Ügyeljen arra, hogy hagyjon szóközt a $vt_handoff és a systemd.unit=rescue.target között. Ez lehetővé teszi az Ubuntu gép számára, hogy helyreállítási módba induljon.

A módosítások elvégzése után mentse a fájlt a Ctrl + X billentyűkombinációval. A gép újraindul, és megjelenik a parancssor. Nyomja meg az Entert a helyreállítási módba lépéshez.

A parancssorban nyissa meg a konfigurációt Google fájl Authenticator, amely a letiltott felhasználó kezdőkönyvtárában található.

nano /home/8host/.google-authenticator

A fájl első sora a felhasználó privát kulcsa, amely a hitelesítő beállítására szolgál.

Most két lehetőséged van:

1. Lemásolhatja a privát kulcsot, és beállíthatja a hitelesítőt.
2. Ha tiszta lappal szeretne kezdeni, akkor a ~/.google-authenticator fájl teljes eltávolításával letilthatja a 2FA-t az adott felhasználó számára. Újbóli bejelentkezés után újra beállíthatja a 2FA-t, és új titkos kulcsot kaphat.

Mindenesetre visszaállíthatja a rendszert egy 2FA-blokkolás után helyi környezetben a GRUB rendszerbetöltő segítségével. Ezután elmagyarázzuk, hogyan lehet visszaállítani a hozzáférést egy blokkolt távoli környezethez.

7. lépés: A törölt környezethez való hozzáférés visszaállítása (opcionális)

Ha a sudoer fiók zárolva van egy távoli környezetben, ideiglenesen letilthatja vagy újra konfigurálhatja a 2FA-t a root felhasználó használatával.

Bejelentkezés root felhasználóként:

ssh [e-mail védett] _szerver_ip

Bejelentkezés után nyissa meg a fájlt Google beállítások Hitelesítő, amely a letiltott felhasználó kezdőkönyvtárában található:

sudo nano /home/8host/.google_authenticator

A fájl első sora a felhasználó privát kulcsa, amelyre a hitelesítő beállításához kell.

Most két út áll előtted:

1. Ha új vagy törölt eszközt szeretne beállítani, a titkos kulcs segítségével újrakonfigurálhatja a hitelesítő alkalmazást.
2. Ha tiszta lappal szeretne kezdeni, teljesen törölheti a /home/8host/.google_authenticator fájlt, hogy letiltja a 2FA-t az adott felhasználó számára. Miután bejelentkezett sudo felhasználóként, újra beállíthatja a 2FA-t, és új privát kulcsot kaphat.

Ezen opciók bármelyikével helyreállhat egy véletlen 2FA blokkból a root fiók használatával.

Következtetés

Ebben az oktatóanyagban beállítja a 2FA-t egy Ubuntu 18.04-es gépen. A kéttényezős hitelesítés további fiók- és rendszerbiztonsági réteget biztosít. A szabványos hitelesítő adatokon kívül meg kell adnia is kiegészítő kód bejelentkezés megerősítése. Ez lehetetlenné teszi a fiókjához való jogosulatlan hozzáférést, még akkor sem, ha egy támadónak sikerül megszereznie az Ön hitelesítő adatait.

1. Csatlakoztassa az USB tokent a számítógépéhez.
2. Az USB-token modellnevének meghatározásához nyissa meg Terminálés írja be a parancsot:

Ennek eredményeként az USB-token modell neve megjelenik a Terminál ablakban:

Győződjön meg arról, hogy a következőket használja: Aktiv Rutoken ECP

Bevezetés

A Pluggable Authentication Modules (PAM, Pluggable Authentication Modules) olyan megosztott könyvtárak halmaza, amelyek lehetővé teszik különböző alacsony szintű hitelesítési módszerek integrálását egyetlen magas szintű API-ba. Ez lehetővé teszi, hogy egységes mechanizmusokat biztosítson az alkalmazások kezeléséhez és beágyazásához a hitelesítési folyamatba.

A PAM beállításának általános eljárása a következő:

1. Létrehoz egy RSA kulcspárt a tokenen (ellenőrizve, hogy működik-e 2048 bites kulcsnál, problémák voltak az 1024 bittel)
   
2. Ha tanúsítványra van szükség, akkor az OpenSSL vagy más szoftver segítségével állítson elő egy tanúsítványt, és írja be a tokenbe
3. éget nyilvános kulcs vagy tanúsítványt a kívánt címtárba
   

A végén így néz ki:

Előzetes felkészítés

A demó Ubuntu 18.04-en fut. A leírt műveletsor az Ubuntu más verzióira és a Debian alapú rendszerekre is vonatkozik.

A PAM modul konfigurálásához telepítenie kell a következő csomagokat:

• dbcd
• OpenSC
• OpenSSL
• libpam-p11
• libengine-pkcs11-openssl

sudo apt-get install pcscd opensc openssl libpam-p11 libengine-pkcs11-openssl

A Rutoken S felhasználóknak telepíteniük kell az illesztőprogramot a webhelyünkről is.

Általános eljárás

beállítás pam_p11

Mielőtt elkezdené dolgozni a tokennel, konfigurálja a pam_p11 modult:

Fájl létrehozása /usr/share/pam-configs/p11 a következő tartalommal:

Név: Pam_p11 Alapértelmezés: yes Prioritás: 800 Auth-Type: Elsődleges hitelesítés: elegendő pam_p11_opensc.so /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

Ha nem az Ubuntu 18.04-et futtatja, akkor ellenőriznie kell az opensc-pkcs11.so helyét. Megtalálható pl

/usr/lib/opensc-pkcs11.so. Ha nem találja, használja a find parancsot

PAM konfiguráció frissítése:

sudo pam-auth-update

1. A megjelenő párbeszédpanelen győződjön meg arról, hogy a pam_p11 van kiválasztva. Ha szeretné letiltani a jelszavas hitelesítést, letilthatja a Unix hitelesítést.

   Kulcsok létrehozása tokenen

Készítsük elő a tokent.

$ pkcs15-init -E $ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk "" $ pkcs15-init --store-pin --label "Felhasználói PIN" --auth- id 02 --pin "12345678" --puk "" --so-pin "87654321" --finalize

A pin és so-pin paraméterekben megadhatja a kívánt felhasználói és rendszergazdai pin kódokat.

Létrehozunk egy 2048 bites RSA kulcspárt "45" azonosítóval (az azonosítót érdemes megjegyezni, a tanúsítvány készítésekor szükség lesz rá). A token hitelesítése a felhasználói entitás alatt történik.

$ pkcs15-init --generate-key rsa/2048 --auth-id 02 --id 45<вводим PIN пользователя>

Ellenőrizzük a generált kulcsot:

$ pkcs15-tool --list-keys Olvasó használata kártyával: Aktiv Rutoken ECP 00 00 Privát RSA Key Object Flags: , private, módosítható Használat: , sign Access Flags: , érzékeny, alwaysSensitive, neverExtract, local ModLength: 2048 Key ref. : 1 (0x1) Natív: igen Elérési út: 3f001000100060020001 Auth ID: 02 ID: 45

Tanúsítvány létrehozása és importálása tokenbe

2. Futtassa az openssl-t

   Betöltjük a pkcs11 támogatási modult:

   OpenSSL> motor dinamikus -elő SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/x86_64- linux-gnu/opensc-pkcs11.so (dinamikus) Dinamikus motorbetöltési támogatás : SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so : ID:pkcs11 : LIST_ADD:1 : LOAD : MODULE_PATH /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so Betöltve: (pkcs11) pkcs11 motor OpenSSL>

   Ha nem Ubuntu 18.04-et használ, akkor ellenőriznie kell a pkcs11.so helyét. Megtalálható például a /usr/lib/openssl/engines/ könyvtárban. Ha nem találja, használja a find parancsot

   Hozzon létre egy önaláírt tanúsítványt PEM formátumban:

   OpenSSL> req -engine pkcs11 -új -kulcs 0:45 -keyform engine -x509 -out cert.pem -text

   Ahol 0:45 a slot:id pár (amit az 5. lépésben adtunk meg). Az OpenSSL kérni fogja, hogy adja meg a PIN-kódot, és töltse ki a tanúsítvány adatait. Ha hibaüzenetet kap, ellenőrizze, hogy nincs-e más USB-token vagy intelligenskártya-olvasó csatlakoztatva a számítógéphez.

   A generált tanúsítvány ellenőrzése. Az aktuális könyvtárban létre kell hozni egy cert.pem nevű önaláírt tanúsítványfájlt.
   Megjegyzés: ha eltávolítja az -x509 kulcsot, amikor egy tanúsítványt hoz létre az OpenSSL-ben, akkor a kimeneten egy tanúsítvány kérést kapunk.

   jegyzet

   A felhasználó kiválasztásának szakaszában előfordulhat, hogy a csatlakoztatott tokennel kapcsolatos információk nem frissülnek dinamikusan. Ha csatlakoztatta a tokent, és nem látja a PIN-kód beviteli mezőjét, előfordulhat, hogy át kell helyeznie a fókuszt a „vendég munkamenetre”, majd vissza a felhasználóra.

2020 óta tilos a GOST R 34.10-2001 szerinti titkosítás használata, ami azt jelenti, hogy minden kormányzati szervvel együttműködő szervezet kénytelen sürgősen végrehajtani a következő szabványt - 2012. Ha az egyikben dolgozik, ne menjen el: ebben a cikkben arról fogunk beszélni, hogyan lehet megoldani a problémát a CentOS 7 szerver és a CryptoPro JCP csomag használatával.

Ha először hall minderről, akkor íme egy kis történelmi háttér.

1994-ben az FSB számos szabványt és intézkedést dolgozott ki a szervezetek és a folyamat többi résztvevője közötti dokumentumcsere védelmére. Az egyik ilyen biztonsági intézkedés volt a dokumentumok elektronikus digitális aláírása, valamint az egyik szabvány - a GOST R 34.10-94, amely leírja az elektronikus létrehozásának és ellenőrzésének algoritmusát. digitális aláírás. Az orosz állami szabvány 1994. május 23-i, 154. számú határozatával elfogadták és hatályba léptették, és 2001-ig dolgozott.

Felváltotta a jól ismert GOST R 34.10-2001 - egy továbbfejlesztett szabvány, amelyet az algoritmusok nagyobb stabilitásának biztosítására terveztek. De az idő nem áll meg, a titkosítási védelem algoritmusai és módszerei változnak, és tizenegy év elteltével a GOST R 34.10-2001 GOST R 34.10-2012-re változik.

Az új szabványban a paraméterekre vonatkozó követelmények első változata változatlan marad. Hossz titkos kulcs 256 bites nagyságrendű, és 256 vagy 512 bites hash-kóddal tervezett hash függvényt kell használni. Az új szabvány fő különbsége a további paraméterekkel és sémákkal rendelkező opciók, beleértve a GOST R 34.11-2012 Stribog szabvány szerinti kivonatolást.

INFO

Stribog az ősi szlávok istene, aki pártfogolja a szeleket, az időjárást és mindent, ami a légtérrel kapcsolatos. Talán és felhő technológiák Azonos. Tudjon meg többet erről a titkosításról a "" és a "" cikkekben.

2014 februárjában az FSB bejelentette az új nemzeti szabvány, a GOST R 34.10-2012 használatára való áttérés megkezdését. Elektronikus aláírásállamtitkot nem tartalmazó információkra. Megjelent a 149/7/1/3-58 2014. január 31-i keltezésű „Az új EDS-szabványok és a kivonatolási funkciók használatára való átállás rendjéről” című dokumentum, amely az alábbi követelményeket állapította meg.

1. 2013. december 31. után az Oroszországi Szövetségi Biztonsági Szolgálat 2011. december 27-i 796. sz. rendeletében jóváhagyott elektronikus aláírási eszközökre vonatkozó követelményeknek való megfelelés érdekében szüntesse meg az elektronikus aláírási eszközök tanúsítását, ha ezek az eszközök nem biztosítják a végrehajtást funkciók a GOST R 34.10-2012 szerint.
2. 2018. december 31. után tiltsa meg a GOST R 34.10-2001 használatát elektronikus aláírás létrehozására.

A Hírközlési Minisztérium még tervet is készített a szabványra való átállásról (PDF). A gyakorlatban azonban kiderült, hogy nem minden olyan egyszerű, és az átállást 2019. december 31-ig kellett elhalasztani. Az okok a következők.

1. Sok állami és önkormányzati hatóság nem áll készen az új GOST-2012 elektronikus aláírási szabványra való átállásra a szoftverszintű támogatás hiánya miatt.
2. Új tanúsítványok kiadásához olyan hardverre van szükség, amely támogatja új GOST, valamint a Head Certification Authority tanúsítványa, a GOST-2012 használatával generált. A tanúsító központok csak 2018 nyarán kapták meg. További időre van szükség a tanúsítványok minden felhasználó számára történő kiadásához.

Jelenleg két titkosítási szabvány létezik az EDS működésére, de a GOST-2001-et használóknak sürgősen tenniük kell valamit. A tél, ahogy mondani szokták, jön, ami azt jelenti, hogy tesztsorozat vár ránk a GOST-2012 támogatás bevezetésekor.

Elmondom, hogyan telepíthetsz egy FSB-tanúsítvánnyal rendelkező kriptográfiai információvédelmi eszközt (CryptoPro JCP) egy Java JDK-t futtató Linux-kiszolgálón. Egyébként, ha még mindig GOST-2001-et használ, van egy csodálatos a CryptoPro honlapján, azt tanácsolom, olvassa el, nem lesz felesleges.

A csere résztvevői közötti teljes dokumentumáramlás az SMEV (tárcaközi elektronikus interakció rendszere) elvén zajlik. Egy alkalmazás lehet tagja egy ilyen rendszernek, de lehet, hogy egyáltalán nem, az iratcsere elve ettől nem változik. A könnyebb érthetőség kedvéért rajzoltam egy kis diagramot.

Árak

Mint mindig, most is felmerül az engedélyezés kérdése. szoftveres megoldás. A CryptoPro JCP nem olcsó, és ha egy munkaállomás 1200 rubelbe kerül, akkor a szerverlicencek sokkal drágábbak - körülbelül 30 000 magonként (vagy két magonként) Intel processzor a Hyper Threading letiltásával).

Titkosító szolgáltató telepítése és konfigurálása

A példákban fogom használni Virtuális gép CentOS 7-tel, de nincs korlátozva a választék hardverÉs Linux disztribúció. Minden művelet és parancs ugyanaz lesz.

Először is hozzunk létre egy helyi felhasználót, amely alatt a dokumentum-aláírást használó szoftver futni fog.

$ sudo useradd -d /opt/user -p<Тут указываем пароль>-s /bin/bash felhasználó; sudo grep felhasználó /etc/passwd

Helyesen telepítse a Java JDK-t. Töltse le a szükséges disztribúciót.

$ wget --header "Cookie: oraclelicense=a" --content-disposition http://download.oracle.com/otn-pub/java/jdk/8u191-b12/2787e4a523244c269598db4e85c51e0-196-4taruxu .gz -O jdk-8u191-linux-x64.tar.gz

Csomagolja ki az archívumot, és ellenőrizze, hogy a Java mappa készen áll-e a másolásra.

$ tar zxvf jdk-8u191-linux-x64.tar.gz; ls-al;

Másolja a mappát az alkalmazásszoftverek részébe. Általában az /opt-ot használom.

$ sudo cp -rf jdk1.8.0_191 /opt/

Ellenőrizzük, hogy megfelelően másolták-e le. Ha szükséges, módosítsa a mappa tulajdonosát root-ra.

$ ls -al /opt/jdk1.8.0_191/ $ sudo chown -R root:root /opt/jdk1.8.0_191/; cd /opt/jdk1.8.0_191/; ls-al;

előírni Környezeti változók Java JDK-hoz alapértelmezés szerint minden felhasználó számára.

$ sudo vi /etc/profile.d/oracle.sh

A fájlba a következőket írjuk:

JAVA_HOME=/opt/jdk1.8.0_191 exportálás export JRE_HOME=/opt/jdk1.8.0_191/jre export PATH=$PATH:/opt/jdk1.8.0_191/bin:/opt/jdk1.8.0_191/jre/

Ha a kiszolgálón a Java JDK több verziója is található, akkor alternatívákat kell regisztrálni új verzió.

$ sudo alternatívák --install /usr/bin/java java /opt/jdk1.8.0_191/bin/java 2 $ sudo alternatívák --install /usr/bin/jar jar /opt/jdk1.8.0_191/bin/jar 2 $ sudo alternatívák --install /usr/bin/javac javac /opt/jdk1.8.0_191/bin/javac 2 $ sudo alternatívák --set jar /opt/jdk1.8.0_181/bin/jar $ sudo alternatívák --set jar /opt/jdk1.8.0_191/bin/jar $ sudo alternatívák --set javac /opt/jdk1.8.0_191/bin/javac $ sudo alternatívák --config java

A menüben válassza ki a 2. opciót (vagy azt, amelyik újabb használatához vezet Java verziók). Ne felejtse el kijavítani a JRE systemPrefs jogait.

$ sudo chmod 777 -R /opt/jdk1.8.0_191/jre/.systemPrefs

Ellenőrzés telepített verzió Jáva.

$ java-verzió
Java verzió "1.8.0_191"
Java(TM) SE futási környezet (build 1.8.0_191-b12)
Java HotSpot(TM) 64 bites szerver virtuális gép (25.191-b12 build, vegyes mód)

Másolja a mappát a CryptoPro JCP terjesztési készlettel az alkalmazásszoftverek részébe.

$ sudo cp -rf jcp-2.0.40035 /opt/

Ellenőrizzük, hogy minden megfelelően másolt-e.

$ ls -al /opt/jcp-2.0.40035/

Engedély megadása szkriptek futtatásához.

$ sudo chmod +x /opt/jcp-2.0.40035/*.sh

Ellenőrizzük a mappa tulajdonosát és jogait, rootnak kell lennie. Menjünk bele.

$ ls -al /opt/jcp-2.0.40035/; cd /opt/jcp-2.0.40035/;

A telepítés során felmerülő problémák elkerülése érdekében ellenőrizze a processzor magjainak számát és a licencet. A magok számát az nproc paranccsal tudod megtudni.

Térjünk át a JCP titkosítási szolgáltató telepítésére. A telepítés során számos kérdésre kell válaszolnia.

Továbbra is csak a tagok számára elérhető

1. lehetőség: Csatlakozzon a "webhely" közösséghez, hogy elolvassa az oldalon található összes anyagot

A meghatározott időszakban a közösséghez való tagság hozzáférést biztosít az ÖSSZES Hacker anyaghoz, növeli a személyes kumulatív kedvezményt, és lehetővé teszi, hogy professzionális Xakep Score értékelést gyűjtsön!