Monitekijätodennuksen määrittäminen SSH:lle CentOS 7:ssä

Esittely

Todennustekijä on yksittäinen tieto, jota käytetään todisteena siitä, että sinulla on oikeudet suorittaa jokin toiminto, kuten kirjautua järjestelmään. Todennuskanava on tapa, jolla todennusjärjestelmä toimittaa tekijän käyttäjälle tai vaatii käyttäjää vastaamaan. Salasanat ja turvatunnisteet ovat esimerkkejä todennustekijöistä; tietokoneet ja puhelimet ovat esimerkkejä kanavista.

SSH käyttää oletusarvoisesti salasanoja todennukseen, ja useimmat SSH:n koventamisohjeet suosittelevat sen sijaan SSH-avaimen käyttöä. Tämä on kuitenkin edelleen vain yksi tekijä. Jos pahantekijä on vaarantanut tietokoneesi, hän voi käyttää avaintasi vaarantaakseen myös palvelimesi.

Tässä ohjeessa asetamme monitekijätodennuksen tämän torjumiseksi. Monitekijätodennus (Multi-factor authentication, MFA) vaatii useamman kuin yhden tekijän todennusta tai kirjautumista varten. Tämä tarkoittaa, että pahantekijän on vaarannettava useita asioita, kuten tietokoneesi ja puhelimesi, päästäkseen sisään. Erityyppiset tekijät tiivistetään usein seuraavasti:

1. Jotain, minkä tiedät, kuten salasana tai turvakysymys
2. Jotain, mikä sinulla on, kuten autentikointisovellus tai turvatunniste
3. Jotain, mikä olet, kuten sormenjälkesi tai äänesi

Yksi yleiseksi tekijäksi muodostuu OATH-TOTP-sovellus, kuten Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) on avoin protokolla, joka luo kertakäyttösalasanan, joka on yleensä kuusinumeroinen luku, joka kierrätetään 30 sekunnin välein.

Tässä artikkelissa käydään läpi, miten SSH-todennus otetaan käyttöön käyttämällä SSH-avaimen lisäksi OATH-TOTP-sovellusta. Kirjautuminen palvelimelle SSH:n kautta vaatii tällöin kaksi tekijää kahdessa kanavassa, mikä tekee siitä turvallisemman kuin pelkkä salasana tai SSH-avain. Lisäksi käymme läpi joitakin muita MFA:n käyttötapauksia sekä hyödyllisiä vinkkejä ja niksejä.

Vedellytykset

Tämän ohjeen seuraamiseen tarvitset:

• Ensimmäisen CentOS 7 -palvelimen, jossa on sudo-ei-root-käyttäjä ja SSH-avain, jonka voit määrittää noudattamalla tätä palvelimen alkuasennuksen ohjetta.
• Älypuhelimen tai tabletin, johon on asennettu OATH-TOTP-sovellus, kuten Google Authenticator (iOS, Android).

Vaihe 1 – Googlen PAM:n asentaminen

Tässä vaiheessa asennamme ja konfiguroimme Googlen PAM:n.

PAM, joka tulee sanoista Pluggable Authentication Module (Liitettävissä oleva todennusmoduuli), on todennusinfrastruktuuri, jota käytetään Linux-järjestelmissä käyttäjän todennukseen. Koska Google teki OATH-TOTP-sovelluksen, he tekivät myös PAM:n, joka tuottaa TOTP:t ja on täysin yhteensopiva minkä tahansa OATH-TOTP-sovelluksen, kuten Google Authenticatorin tai Authy:n, kanssa.

Ensin meidän on lisättävä EPEL (Extra Packages for Enterprise Linux) repo.

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

Seuraavaksi asennetaan PAM. Sinua saatetaan pyytää hyväksymään EPEL-avain, jos käytät repoa ensimmäistä kertaa. Kun olet hyväksynyt, sinua ei enää pyydetä hyväksymään avainta.

sudo yum install google-authenticator

Kun PAM on asennettu, käytämme PAMin mukana tulevaa apusovellusta luomaan TOTP-avaimen käyttäjälle, jolle haluat lisätä toisen tekijän. Tämä avain luodaan käyttäjäkohtaisesti, ei koko järjestelmän tasolla. Tämä tarkoittaa, että jokaisen käyttäjän, joka haluaa käyttää TOTP-auth-sovellusta, on kirjauduttava sisään ja ajettava apulaissovellus saadakseen oman avaimensa; et voi ajaa sitä vain kerran ottaaksesi sen käyttöön kaikille (mutta tämän ohjeen lopussa on vinkkejä MFA:n käyttöönottoon tai vaatimiseen monille käyttäjille).

Ajoita alustussovellus.

google-authenticator

Komennon suorittamisen jälkeen sinulta kysytään muutama kysymys. Ensimmäisessä kysytään, pitäisikö tunnistusmerkkien olla aikapohjaisia.

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

Tämä PAM sallii aikapohjaiset tai peräkkäiset tunnukset. Sekvenssipohjaisten tunnisteiden käyttäminen tarkoittaa sitä, että koodi alkaa tietystä pisteestä ja sitä kasvatetaan jokaisen käyttökerran jälkeen. Aikapohjaisten tunnisteiden käyttö tarkoittaa, että koodi muuttuu satunnaisesti tietyn ajan kuluttua. Pysymme aikapohjaisissa tunnisteissa, koska Google Authenticatorin kaltaiset sovellukset ennakoivat niitä, joten vastaa y myöntävästi.

Kysymykseen vastaamisen jälkeen vierii ohi paljon tulosteita, kuten suuri QR-koodi. Käytä tässä vaiheessa puhelimesi Authenticator-sovellusta QR-koodin skannaamiseen tai kirjoita salainen avain manuaalisesti. Jos QR-koodi on liian suuri skannattavaksi, voit käyttää QR-koodin yläpuolella olevaa URL-osoitetta saadaksesi pienemmän version. Kun se on lisätty, näet sovelluksessasi kuusinumeroisen koodin, joka vaihtuu 30 sekunnin välein.

Huomautus: Varmista, että tallennat salaisen avaimen, vahvistuskoodin ja palautuskoodit turvalliseen paikkaan, kuten salasanahallintaan. Palautuskoodit ovat ainoa tapa saada pääsy takaisin, jos esimerkiksi menetät pääsyn TOTP-sovellukseesi.

Loput kysymykset ilmoittavat PAM:lle, miten se toimii. Käymme ne läpi yksi kerrallaan.

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

Tämä kirjoittaa avaimen ja vaihtoehdot .google_authenticator-tiedostoon. Jos vastaat ei, ohjelma lopettaa eikä mitään kirjoiteta, mikä tarkoittaa, että todentaja ei toimi.

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

Vastaamalla tähän kyllä estät toistohyökkäyksen asettamalla jokaisen koodin vanhentumaan heti käytön jälkeen. Tämä estää hyökkääjää kaappaamasta juuri käyttämääsi koodia ja kirjautumasta sisään sillä.

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

Vastaamalla tähän kyllä sallitaan enintään kahdeksan kelvollista koodia liikkuvan neljän minuutin aikana. Vastaamalla ei rajoitat sen 3 kelvolliseen koodiin 1:30 minuutin liukuvassa ikkunassa. Ellei 1:30 minuutin ikkunaan liity ongelmia, vastaus ei on turvallisempi valinta.

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

Nopeuden rajoittaminen tarkoittaa, että etähyökkääjä voi yrittää vain tietyn määrän arvauksia ennen kuin hänet estetään. Jos et ole aiemmin määrittänyt nopeusrajoitusta suoraan SSH:ssa, sen tekeminen nyt on hyvä suojaustekniikka.

Huomautus: Kun olet saanut tämän asennuksen valmiiksi, jos haluat varmuuskopioida salaisen avaimesi, voit kopioida ~/.google-authenticator-tiedoston luotettavaan paikkaan. Sieltä voit ottaa sen käyttöön muissa järjestelmissä tai ottaa sen uudelleen käyttöön varmuuskopioinnin jälkeen.

Nyt kun Googlen PAM on asennettu ja konfiguroitu, seuraava vaihe on määrittää SSH käyttämään TOTP-avainta. Meidän on kerrottava SSH:lle PAM:stä ja sitten konfiguroitava SSH käyttämään sitä.

Vaihe 2 – OpenSSH:n konfigurointi

Koska teemme SSH-muutoksia SSH:n kautta, on tärkeää, ettet koskaan sulje alkuperäistä SSH-yhteyttä. Avaa sen sijaan toinen SSH-istunto testausta varten. Näin vältät lukitsemasta itseäsi ulos palvelimestasi, jos SSH-konfiguraatiossasi on tapahtunut virhe. Kun kaikki toimii, voit turvallisesti sulkea kaikki istunnot.

Aluksi muokkaamme sshd-konfiguraatiotiedostoa. Tässä käytämme nano, jota ei ole asennettu CentOS:iin oletusarvoisesti. Voit asentaa sen sudo yum install nano:llä tai käyttää suosikkivaihtoehtoasi tekstieditorilla.

sudo nano /etc/pam.d/sshd

Lisää tiedoston loppuun seuraava rivi.

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

Viimeisen rivin lopussa oleva nullok-sana kertoo PAM:lle, että tämä todennusmenetelmä on vapaaehtoinen. Näin käyttäjät, joilla ei ole OATH-TOTP-tunnusta, voivat silti kirjautua sisään SSH-avaimellaan. Kun kaikilla käyttäjillä on OATH-TOTP-tunniste, voit poistaa nullok tältä riviltä ja tehdä MFA:sta pakollisen.

Tallenna ja sulje tiedosto.

Seuraavaksi konfiguroimme SSH:n tukemaan tällaista todennusta. Avaa SSH:n konfigurointitiedosto muokkausta varten.

sudo nano /etc/ssh/sshd_config

Etsi ChallengeResponseAuthentication-rivit. Kommentoi rivi no pois ja poista rivi no.

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

Tallenna ja sulje tiedosto ja käynnistä SSH uudelleen konfiguraatiotiedostojen lataamiseksi uudelleen. sshd-palvelun uudelleenkäynnistäminen ei sulje avoimia yhteyksiä, joten et ole vaarassa lukita itseäsi ulos tällä komennolla.

sudo systemctl restart sshd.service

Testataksesi, että kaikki toimii toistaiseksi, avaa toinen pääte ja yritä kirjautua sisään SSH:n kautta. Jos olet aiemmin luonut SSH-avaimen ja käytät sitä, huomaat, ettei sinun tarvinnut kirjoittaa käyttäjän salasanaa tai MFA-varmistuskoodia. Tämä johtuu siitä, että SSH-avain ohittaa oletusarvoisesti kaikki muut todennusvaihtoehdot. Muuten sinun olisi pitänyt saada salasanaa ja vahvistuskoodia koskeva kehote.

Jos haluat varmistaa, että se, mitä olet tähän mennessä tehnyt, toimii, siirry avoimessa SSH-istunnossa osoitteeseen ~/.ssh/ ja nimeä authorized_keys-tiedosto väliaikaisesti uudelleen, avaa uusi istunto ja kirjaudu sisään salasanallamme ja vahvistuskoodillamme.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Kun olet varmistanut, että TOTP-tavaramerkkisi toimii, nimeä tiedosto ’authorized_keys.bak’-tiedostoa takaisin entiselleen.

mv authorized_keys.bak authorized_keys

Seuraavaksi meidän on otettava käyttöön SSH-avain yhtenä tekijänä ja varmistuskoodi toisena ja kerrottava SSH:lle, mitä tekijöitä käyttää, ja estettävä SSH-avainta ohittamasta kaikkia muita tyyppejä.

Vaihe 3 – SSH:n tekeminen tietoiseksi MFA:sta

Avaa konfigurointitiedosto sshd uudestaan.

sudo nano /etc/ssh/sshd_config

Lisääkää tiedostoon alareunaan seuraava rivi. Tämä kertoo SSH:lle, mitä todennusmenetelmiä vaaditaan. Tämä rivi kertoo SSH:lle, että tarvitsemme SSH-avaimen ja joko salasanan tai varmistuskoodin (tai kaikki kolme).

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

Tallenna ja sulje tiedosto.

Avaa seuraavaksi PAM sshd -konfigurointitiedosto uudestaan.

sudo nano /etc/pam.d/sshd

Etsitään rivi auth substack password-auth tiedoston yläreunasta. Kommentoi se pois lisäämällä #-merkki rivin ensimmäiseksi merkiksi. Tämä kertoo PAM:lle, ettei se kysy salasanaa.

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

Tallenna ja sulje tiedosto ja käynnistä SSH uudelleen.

sudo systemctl restart sshd.service

Yritä nyt kirjautua palvelimelle uudelleen eri istunnolla. Toisin kuin viime kerralla, SSH:n pitäisi kysyä vahvistuskoodia. Kun syötät sen, pääset kirjautumaan sisään. Vaikka et näe mitään merkkiä siitä, että SSH-avainta käytettiin, kirjautumisyrityksessäsi käytettiin kahta tekijää. Jos haluat tarkistaa, voit lisätä SSH-komennon perään -v (sanalliseksi):

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:

Tulosteen loppupuolella näet kohdan, jossa SSH käyttää SSH-avainta ja kysyy sitten varmistuskoodia. Voit nyt kirjautua sisään SSH:n kautta SSH-avaimella ja kertakäyttösalasanalla. Jos haluat ottaa käyttöön kaikki kolme todennustyyppiä, voit seurata seuraavaa vaihetta.

Vaihe 4 – Kolmannen tekijän lisääminen (valinnainen)

Vaiheessa 3 listasimme hyväksytyt todennustyypit sshd_config-tiedostossa:

1. publickey (SSH-avain)
2. password publickey (salasana)
3. keyboard-interactive (varmennuskoodi)

Vaikka listasimme kolme erilaista tekijää, toistaiseksi valitsemillamme vaihtoehdoilla ne sallivat vain SSH-avaimen ja varmennuskoodin. Jos haluat kaikki kolme tekijää (SSH-avain, salasana ja varmistuskoodi), yksi nopea muutos mahdollistaa kaikki kolme.

Avaa PAM sshd -määritystiedosto.

sudo nano /etc/pam.d/sshd

Etsi aiemmin kommentoimasi rivi #auth substack password-auth ja poista rivi poistamalla merkki #. Tallenna ja sulje tiedosto. Käynnistä SSH nyt vielä kerran uudelleen.

sudo systemctl restart sshd.service

Valitsemalla vaihtoehdon auth substack password-auth PAM kysyy nyt salasanaa SSH-avaimen tarkistamisen ja varmistuskoodin kysymisen lisäksi, mikä toimi aiemmin. Nyt voimme käyttää jotain, minkä tiedämme (salasana), ja kahta erityyppistä asiaa, jotka meillä on (SSH-avain ja varmistuskoodi), kahdessa eri kanavassa.

Tässä artikkelissa on tähän mennessä kerrottu, miten MFA otetaan käyttöön SSH-avaimella ja aikapohjaisella kertakäyttösalasanalla. Jos tämä on kaikki mitä tarvitset, voit lopettaa tähän. Tämä ei kuitenkaan ole ainoa tapa toteuttaa monitekijätodennus. Alla on pari muuta tapaa käyttää tätä PAM-moduulia monitekijätodennukseen sekä vinkkejä ja niksejä palautukseen, automaattiseen käyttöön ja muuhun.

Vinkki 1 – Pääsyn palauttaminen

Kuten minkä tahansa kovettamasi ja suojaamasi järjestelmän kohdalla, sinusta tulee myös vastuu tietoturvan hallinnasta. Tässä tapauksessa se tarkoittaa, ettet menetä SSH-avainta tai TOTP-salaista avainta ja varmistat, että sinulla on pääsy TOTP-sovellukseesi. Joskus kuitenkin tapahtuu asioita, ja voit menettää hallinnan avaimista tai sovelluksista, joita tarvitset sisäänpääsyyn.

SSH-avaimen tai TOTP-salaisen avaimen menettäminen

Jos kadotat SSH-avaimesi tai TOTP-salaisen avaimesi, toipuminen voidaan jakaa muutamaan vaiheeseen. Ensimmäinen on päästä takaisin sisään tietämättä varmennuskoodia ja toinen on löytää salainen avain tai luoda se uudelleen normaalia MFA-kirjautumista varten.

Päästääksesi sisään menetettyäsi salaisen avaimen, joka luo varmennuskoodin DigitalOcean Dropletissa, voit yksinkertaisesti käyttää virtuaalista konsolia kojelaudaltasi kirjautuaksesi sisään käyttäjätunnuksellasi ja salasanallasi.

Muussa tapauksessa tarvitset ylläpitäjäkäyttäjäkäyttäjän, jolla on sudo-oikeudet; varmista, ettet ota käyttöön MFA:ta tälle käyttäjällä, vaan käytät pelkkää SSH-avainta. Jos sinä tai joku muu käyttäjä kadottaa salaisen avaimensa eikä pääse kirjautumaan sisään, hallintakäyttäjä voi kirjautua sisään ja auttaa palauttamaan tai uudistamaan avaimen kenelle tahansa käyttäjälle käyttämällä sudo.

Kun olet kirjautunut sisään, on kaksi tapaa auttaa saamaan TOTP-salaisuus:

1. Varmistaa olemassa oleva avain
2. Luoda uusi avain

Kunkin käyttäjän kotihakemistossa salainen avain ja Google Authenticatorin asetukset on tallennettu kohtaan ~/.google-authenticator. Tämän tiedoston ensimmäinen rivi on salainen avain. Nopea tapa saada avain on suorittaa seuraava komento, joka näyttää google-authenticator-tiedoston ensimmäisen rivin (eli salaisen avaimen). Ota sitten tämä salainen avain ja kirjoita se manuaalisesti TOTP-sovellukseen.

head -n 1 /home/sammy/.google_authenticator

Jos on syytä olla käyttämättä olemassa olevaa avainta (esimerkiksi jos et pysty helposti jakamaan salaista avainta vaikutuksen kohteena olevalle käyttäjälle turvallisesti tai olemassa oleva avain on vaarantunut), voit poistaa ~/.google-authenticator-tiedoston kokonaan. Näin käyttäjä voi kirjautua uudelleen sisään käyttämällä vain yhtä tekijää, olettaen, että et ole ottanut MFA:ta käyttöön poistamalla ’nullok’ tiedostosta ’/etc/pam.d/sshd’. Tämän jälkeen hän voi suorittaa google-authenticator luodakseen uuden avaimen.

Käyttöoikeuden menettäminen TOTP-sovellukseen

Jos sinun on kirjauduttava palvelimellesi, mutta sinulla ei ole pääsyä TOTP-sovellukseesi, jotta voisit saada vahvistuskoodin, voit silti kirjautua sisään käyttämällä palautuskoodeja, jotka näytettiin, kun luot salaisen avaimesi ensimmäisen kerran. Huomaa, että nämä palautuskoodit ovat kertakäyttöisiä. Kun yhtä niistä on kerran käytetty kirjautumiseen, sitä ei voi käyttää varmennuskoodina enää uudelleen.

Vinkki 2 – Todennusasetusten muuttaminen

Jos haluat muuttaa MFA-asetuksiasi alkuperäisen konfiguroinnin jälkeen, sen sijaan, että luot uuden konfiguraation päivitetyillä asetuksilla, voit vain muokata ~/.google-authenticator-tiedostoa. Tämä tiedosto on järjestetty seuraavasti:

<secret key><options><recovery codes>

Tässä tiedostossa asetetuilla vaihtoehdoilla on rivi options-osiossa; jos vastasit ”ei” tiettyyn vaihtoehtoon alkuasetusten aikana, vastaava rivi jätetään pois tiedostosta.

Tässä tiedostossa voi tehdä seuraavia muutoksia:

• Voidaksesi ottaa käyttöön peräkkäiset koodit aikapohjaisten koodien sijaan vaihda rivi " TOTP_AUTH muotoon " HOTP_COUNTER 1.
• Voidaksesi sallia yksittäisen koodin useamman käyttökerran, poista rivi " DISALLOW_REUSE.
• Voidaksesi pidentää koodin voimassaolon päättymisajankohtaa neljään minuuttiin, lisää rivi " WINDOW_SIZE 17.
• Poista rivi " RATE_LIMIT 3 30 poistamalla rivi " RATE_LIMIT 3 30, jos haluat poistaa useita epäonnistuneita kirjautumisia (nopeusrajoitus).
• Muuttaa nopeusrajoituksen kynnysarvoa etsimällä rivi " RATE_LIMIT 3 30 ja säätämällä numeroita. Alkuperäisessä 3 ilmaisee yrityksien määrän tietyn ajanjakson aikana ja 30 ilmaisee ajanjakson sekunteina.
• Poista palautuskoodien käyttö käytöstä poistamalla tiedoston alareunassa olevat viisi 8-numeroista koodia.

Vinkki 3 – MFA:n välttäminen joidenkin tilien osalta

Voi olla tilanne, jossa yksittäinen käyttäjä tai muutama palvelutili (eli tilit, joita käyttävät sovellukset, eivät ihmiset) tarvitsee SSH-käytön ilman, että MFA on käytössä. Esimerkiksi jotkin SSH:ta käyttävät sovellukset, kuten jotkin FTP-ohjelmat, eivät välttämättä tue MFA:ta. Jos sovelluksella ei ole tapaa pyytää vahvistuskoodia, pyyntö voi jäädä jumiin, kunnes SSH-yhteys katkeaa.

Kunhan pari asetusta kohdassa /etc/pam.d/sshd asetetaan oikein, voit hallita, mitä tekijöitä käytetään käyttäjäkohtaisesti.

Voidaksesi sallia MFA:n joillekin tileille ja pelkän SSH-avaimen toisille, varmista, että seuraavat asetukset kohdassa /etc/pam.d/sshd ovat aktiivisia.

#%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

Tässä kohdassa auth substack password-auth on kommentoitu pois, koska salasanojen on oltava pois käytöstä. MFA:ta ei voi pakottaa, jos joillakin tileillä on tarkoitus olla MFA pois käytöstä, joten jätä nullok-vaihtoehto viimeiselle riville.

Tämän konfiguraation asettamisen jälkeen suorita yksinkertaisesti google-authenticator kaikille käyttäjille, jotka tarvitsevat MFA:ta, äläkä suorita sitä käyttäjille, joilla käytetään vain SSH-avaimia.

Vinkki 4 – Asetusten automatisoiminen konfiguraationhallinnalla

Monet järjestelmäylläpitäjät käyttävät konfiguraatioidenhallintatyökaluja kuten esimerkiksi Puppetia, Cheffiä tai Ansiblenä järjestelmiensä hallintaan. Jos haluat käyttää tällaista järjestelmää asentaaksesi salaisen avaimen, kun uuden käyttäjän tili luodaan, siihen on olemassa menetelmä.

google-authenticator tukee komentorivikytkimiä, joilla voit asettaa kaikki asetukset yhdellä, ei-interaktiivisella komennolla. Jos haluat nähdä kaikki vaihtoehdot, voit kirjoittaa google-authenticator --help. Alla on komento, joka asettaisi kaiken vaiheessa 1 esitetyllä tavalla:

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

Tämä vastaa kaikkiin kysymyksiin, joihin vastasimme manuaalisesti, tallentaa ne tiedostoon ja tulostaa sitten salaisen avaimen, QR-koodin ja palautuskoodit. (Jos lisäät lipun -q, tulostusta ei tule.) Jos käytät tätä komentoa automatisoidusti, varmista, että kaappaat salaisen avaimen ja/tai palautuskoodit ja annat ne käyttäjän saataville.

Vinkki 5 – MFA:n pakottaminen kaikille käyttäjille

Jos haluat pakottaa MFA:n pakolliseksi kaikille käyttäjille jo ensimmäisellä sisäänkirjautumisella tai jos et halua luottaa siihen, että käyttäjät luovat itse omat avaimensa, tämä on helppo tapa hoitaa. Voit yksinkertaisesti käyttää samaa .google-authenticator-tiedostoa jokaiselle käyttäjälle, koska tiedostoon ei tallenneta käyttäjäkohtaisia tietoja.

Tehdäksesi tämän konfigurointitiedoston alkuperäisen luomisen jälkeen etuoikeutetun käyttäjän on kopioitava tiedosto jokaisen kotihakemiston juureen ja muutettava sen käyttöoikeudet sopivaksi käyttäjälle. Voit myös kopioida tiedoston osoitteeseen /etc/skel/, jolloin se kopioidaan automaattisesti uuden käyttäjän kotihakemistoon luomisen yhteydessä.

Varoitus: Tämä voi olla tietoturvariski, koska kaikki jakavat saman toisen tekijän. Tämä tarkoittaa, että jos se vuotaa, se on kuin jokaisella käyttäjällä olisi vain yksi tekijä. Ota tämä huomioon, jos haluat käyttää tätä lähestymistapaa.

Toinen tapa pakottaa käyttäjän salaisen avaimen luominen on käyttää bash-skriptiä, joka:

1. Luo TOTP-tunnisteen,
2. Kehottaa käyttäjää lataamaan Google Authenticator -sovelluksen ja skannaamaan näytettävän QR-koodin ja
3. Ajattelee google-authenticator-sovelluksen käyttäjän puolesta sen jälkeen, kun hän on tarkistanut, että .google-authenticator-tiedosto on jo olemassa.

Voidaksesi varmistaa, että skripti suoritetaan, kun käyttäjä kirjautuu sisään, voit nimetä sen .bash_login ja sijoittaa sen käyttäjän kotihakemiston juureen.

Johtopäätös

Tämän sanottuasi, kun sinulla on kaksi tekijää (SSH-avain + MFA-token) kahdessa kanavassa (tietokoneesi + puhelimesi), olet tehnyt ulkopuolisen agentin erittäin vaikeaksi murtautua koneellesi SSH:n kautta ja lisännyt koneesi tietoturvaa huomattavasti.