Sådan konfigureres flerfaktorautentifikation til SSH på CentOS 7

Indledning

En autentifikationsfaktor er en enkelt oplysning, der bruges til at bevise, at du har rettighederne til at udføre en handling, som f.eks. at logge ind i et system. En autentificeringskanal er den måde, hvorpå et autentificeringssystem leverer en faktor til brugeren eller kræver, at brugeren skal svare. Adgangskoder og sikkerhedstokens er eksempler på godkendelsesfaktorer; computere og telefoner er eksempler på kanaler.

SSH bruger som standard adgangskoder til godkendelse, og de fleste SSH-hærdningsinstruktioner anbefaler, at man i stedet bruger en SSH-nøgle. Dette er dog stadig kun en enkelt faktor. Hvis en ond aktør har kompromitteret din computer, så kan de bruge din nøgle til også at kompromittere dine servere.

I denne vejledning vil vi opsætte flerfaktor-godkendelse for at bekæmpe dette. Multifaktorautentifikation (MFA) kræver mere end én faktor for at kunne autentificere eller logge ind. Det betyder, at en ondsindet aktør skal kompromittere flere ting, f.eks. både din computer og din telefon, for at komme ind. De forskellige typer faktorer opsummeres ofte som:

1. En ting, du kender, f.eks. en adgangskode eller et sikkerhedsspørgsmål
2. En ting, du har, f.eks. en authenticator-app eller et sikkerhedstoken
3. En ting, du er, f.eks. dit fingeraftryk eller din stemme

En fælles faktor er en OATH-TOTP-app, f.eks. Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) er en åben protokol, der genererer en adgangskode til engangsbrug, almindeligvis et 6-cifret tal, der genbruges hvert 30. sekund.

Denne artikel vil gennemgå, hvordan du aktiverer SSH-godkendelse ved hjælp af en OATH-TOTP-app ud over en SSH-nøgle. Log ind på din server via SSH vil så kræve to faktorer på tværs af to kanaler og dermed gøre det mere sikkert end en adgangskode eller SSH-nøgle alene. Derudover gennemgår vi nogle yderligere brugssituationer for MFA og nogle nyttige tips og tricks.

Forudsætninger

For at følge denne vejledning skal du bruge:

• En CentOS 7-server med en sudo non-root-bruger og SSH-nøgle, som du kan konfigurere ved at følge denne vejledning om indledende serveropsætning.
• En smartphone eller tablet med en OATH-TOTP-app installeret, f.eks. Google Authenticator (iOS, Android).

Stræk 1 – Installation af Googles PAM

I dette trin installerer og konfigurerer vi Googles PAM.

PAM, som står for Pluggable Authentication Module, er en autentifikationsinfrastruktur, der bruges på Linux-systemer til at autentificere en bruger. Fordi Google lavede en OATH-TOTP-app, lavede de også en PAM, der genererer TOTP’er og er fuldt kompatibel med enhver OATH-TOTP-app, som Google Authenticator eller Authy.

Først skal vi tilføje EPEL-repo’en (Extra Packages for Enterprise Linux).

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

Næst skal vi installere PAM’en. Du kan blive bedt om at acceptere EPEL-nøglen, hvis det er første gang, du bruger repo’en. Når du har accepteret den, vil du ikke blive bedt om igen at acceptere nøglen.

sudo yum install google-authenticator

Med PAM installeret bruger vi en hjælpeapp, der følger med PAM, til at generere en TOTP-nøgle for den bruger, du vil tilføje en anden faktor til. Denne nøgle genereres for hver enkelt bruger og ikke for hele systemet. Det betyder, at alle brugere, der ønsker at bruge en TOTP-auth-app, skal logge ind og køre hjælpeappen for at få deres egen nøgle; du kan ikke bare køre den én gang for at aktivere den for alle (men der er nogle tips i slutningen af denne vejledning til at konfigurere eller kræve MFA for mange brugere).

Kør initialiseringsappen.

google-authenticator

Når du kører kommandoen, bliver du stillet et par spørgsmål. Det første spørger, om godkendelsestokens skal være tidsbaserede.

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

Denne PAM giver mulighed for tidsbaserede eller sekventielt baserede tokens. Ved at bruge sekventielt baserede tokens betyder det, at koden starter på et bestemt punkt, og at koden derefter øges efter hver brug. Ved brug af tidsbaserede tokens betyder det, at koden ændres tilfældigt efter et bestemt tidsforløb. Vi holder os til tidsbaserede, fordi det er det, som apps som Google Authenticator forventer, så svar y for ja.

Når du har svaret på dette spørgsmål, ruller en masse output forbi, herunder en stor QR-kode. På dette tidspunkt skal du bruge din authenticator-app på din telefon til at scanne QR-koden eller manuelt indtaste den hemmelige nøgle. Hvis QR-koden er for stor til at scanne, kan du bruge URL’en over QR-koden til at få en mindre version. Når den er tilføjet, vil du se en sekscifret kode, der ændres hvert 30. sekund i din app.

Bemærk: Sørg for at registrere den hemmelige nøgle, bekræftelseskoden og gendannelseskoderne på et sikkert sted, f.eks. i en adgangskodeadministrator. Genoprettelseskoderne er den eneste måde at genvinde adgangen på, hvis du f.eks. mister adgangen til din TOTP-app.

De resterende spørgsmål informerer PAM om, hvordan den skal fungere. Vi gennemgår dem et efter et.

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

Dette skriver nøglen og indstillingerne til .google_authenticator-filen. Hvis du svarer nej, afsluttes programmet, og der skrives ikke noget, hvilket betyder, at authenticatoren ikke virker.

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

Ved at svare ja her forhindrer du et replay-angreb ved at lade hver kode udløbe umiddelbart efter brug. Dette forhindrer en angriber i at fange en kode, du lige har brugt, og logge ind med den.

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

Svaret ja her tillader op til 8 gyldige koder i et bevægeligt vindue på fire minutter. Ved at svare nej begrænser du det til 3 gyldige koder i et rullende vindue på 1:30 minutter. Medmindre du finder problemer med vinduet på 1:30 minutter, er det mere sikre valg at svare nej.

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

Rate limitering betyder, at en fjernangriber kun kan forsøge at gætte et bestemt antal gæt, før han bliver blokeret. Hvis du ikke tidligere har konfigureret hastighedsbegrænsning direkte i SSH, er det en god hærdningsteknik at gøre det nu.

Note: Når du er færdig med denne opsætning, kan du kopiere ~/.google-authenticator-filen til et sted, du har tillid til, hvis du ønsker at sikkerhedskopiere din hemmelige nøgle. Derfra kan du installere den på yderligere systemer eller geninstallere den efter en sikkerhedskopi.

Nu, hvor Googles PAM er installeret og konfigureret, er det næste trin at konfigurere SSH til at bruge din TOTP-nøgle. Vi skal fortælle SSH om PAM og derefter konfigurere SSH til at bruge den.

Stræk 2 – Konfiguration af OpenSSH

Da vi foretager SSH-ændringer over SSH, er det vigtigt, at du aldrig lukker din oprindelige SSH-forbindelse. Åbn i stedet en anden SSH-session for at lave test. Dette er for at undgå at låse dig selv ude af din server, hvis der var en fejl i din SSH-konfiguration. Når alt fungerer, kan du roligt lukke alle sessioner.

For at begynde vil vi redigere sshd-konfigurationsfilen. Her bruger vi nano, som ikke er installeret på CentOS som standard. Du kan installere den med sudo yum install nano eller bruge din foretrukne alternative teksteditor.

sudo nano /etc/pam.d/sshd

Føj følgende linje til bunden af filen.

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

Det nullok ord i slutningen af den sidste linje fortæller PAM, at denne godkendelsesmetode er valgfri. Dette gør det muligt for brugere uden et OATH-TOTP-token stadig at logge ind ved hjælp af deres SSH-nøgle. Når alle brugere har et OATH-TOTP-token, kan du fjerne nullok fra denne linje for at gøre MFA obligatorisk.

Save og luk filen.

Næst skal vi konfigurere SSH til at understøtte denne form for godkendelse. Åbn SSH-konfigurationsfilen til redigering.

sudo nano /etc/ssh/sshd_config

Læs efter ChallengeResponseAuthentication-linjer. Kommenter no-linjen ud, og udkommenter no-linjen.

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

Spar og luk filen, og genstart derefter SSH for at genindlæse konfigurationsfilerne. Genstart af sshd-tjenesten lukker ikke åbne forbindelser, så du risikerer ikke at låse dig selv ude med denne kommando.

sudo systemctl restart sshd.service

For at teste, at alt fungerer indtil videre, skal du åbne en anden terminal og prøve at logge ind over SSH. Hvis du tidligere har oprettet en SSH-nøgle og bruger den, vil du bemærke, at du ikke behøvede at indtaste din brugeradgangskode eller MFA-verifikationskoden. Det skyldes, at en SSH-nøgle som standard tilsidesætter alle andre godkendelsesmuligheder. Ellers skulle du have fået en prompt med en adgangskode og en bekræftelseskode.

Hvis du vil sikre dig, at det, du har gjort indtil nu, virker, skal du i din åbne SSH-session navigere til ~/.ssh/ og omdøbe filen authorized_keys midlertidigt, og åbne en ny session og logge ind med vores adgangskode og bekræftelseskode.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Når du har bekræftet, at dit TOTP-token virker, skal du omdøbe filen ‘authorized_keys.bak’-filen tilbage til det, den var.

mv authorized_keys.bak authorized_keys

Næst skal vi aktivere en SSH-nøgle som en faktor og verifikationskoden som en anden og fortælle SSH, hvilke faktorer der skal bruges, og forhindre SSH-nøglen i at tilsidesætte alle andre typer.

Stræk 3 – Gør SSH opmærksom på MFA

Åbn konfigurationsfilen sshd igen.

sudo nano /etc/ssh/sshd_config

Føj følgende linje nederst i filen. Dette fortæller SSH, hvilke godkendelsesmetoder der kræves. Denne linje fortæller SSH, at vi har brug for en SSH-nøgle og enten en adgangskode eller en bekræftelseskode (eller alle tre).

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

Spar og luk filen.

Åbn derefter PAM sshd-konfigurationsfilen igen.

sudo nano /etc/pam.d/sshd

Find linjen auth substack password-auth mod toppen af filen. Kommenter den ud ved at tilføje et #-tegn som det første tegn på linjen. Dette fortæller PAM, at det ikke skal bede om en adgangskode.

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

Spar og luk filen, og genstart derefter SSH.

sudo systemctl restart sshd.service

Prøv nu at logge ind på serveren igen med en anden session. I modsætning til sidste gang bør SSH bede om din bekræftelseskode. Når du indtaster den, vil du blive logget ind. Selv om du ikke kan se nogen indikation af, at din SSH-nøgle blev brugt, har dit loginforsøg brugt to faktorer. Hvis du vil verificere, kan du tilføje -v (for verbose) efter SSH-kommandoen:

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:

Til sidst i outputtet vil du se, hvor SSH bruger din SSH-nøgle og derefter spørger efter bekræftelseskoden. Du kan nu logge ind over SSH med en SSH-nøgle og en engangskode. Hvis du ønsker at håndhæve alle tre godkendelsestyper, kan du følge det næste trin.

Strin 4 – Tilføjelse af en tredje faktor (valgfrit)

I trin 3 opregnede vi de godkendte typer af autentificering i sshd_config-filen:

1. publickey (SSH-nøgle)
2. password publickey (adgangskode)
3. keyboard-interactive (bekræftelseskode)

Selv om vi opregnede tre forskellige faktorer, tillader de med de muligheder, vi har valgt indtil videre, kun en SSH-nøgle og bekræftelseskoden. Hvis du gerne vil have alle tre faktorer (SSH-nøgle, adgangskode og bekræftelseskode), vil en hurtig ændring aktivere alle tre.

Åbn konfigurationsfilen PAM sshd.

sudo nano /etc/pam.d/sshd

Lokaliser den linje, du kommenterede tidligere, #auth substack password-auth, og fjern kommentaren ved at fjerne #-tegnet. Gem og luk filen. Genstart nu endnu en gang SSH.

sudo systemctl restart sshd.service

Gennem at aktivere indstillingen auth substack password-auth vil PAM nu bede om en adgangskode ud over at kontrollere for en SSH-nøgle og bede om en bekræftelseskode, som vi havde fungerende tidligere. Nu kan vi bruge noget, vi kender (adgangskode), og to forskellige typer af ting, vi har (SSH-nøgle og bekræftelseskode), over to forskellige kanaler.

Så vidt har denne artikel skitseret, hvordan man aktiverer MFA med en SSH-nøgle og en tidsbaseret engangskode. Hvis det er alt, hvad du har brug for, kan du slutte her. Dette er dog ikke den eneste måde at lave multifaktorgodkendelse på. Nedenfor er der et par yderligere måder at bruge dette PAM-modul til multi-faktor-autentifikation og nogle tips og tricks til genoprettelse, automatiseret brug m.m.

Tip 1 – Gendannelse af adgang

Som med ethvert system, som du hærder og sikrer, bliver du ansvarlig for at administrere denne sikkerhed. I dette tilfælde betyder det, at du ikke må miste din SSH-nøgle eller din hemmelige TOTP-nøgle, og at du skal sikre dig, at du har adgang til din TOTP-app. Nogle gange sker der dog ting, og du kan miste kontrollen over de nøgler eller apps, du skal bruge for at komme ind.

Taber du en SSH-nøgle eller en hemmelig TOTP-nøgle

Hvis du mister din SSH-nøgle eller din hemmelige TOTP-nøgle, kan genoprettelsen opdeles i et par trin. Det første er at komme ind igen uden at kende bekræftelseskoden, og det andet er at finde den hemmelige nøgle eller regenerere den til normal MFA-login.

For at komme ind efter at have mistet den hemmelige nøgle, der genererer bekræftelseskoden på en DigitalOcean-droplet, kan du blot bruge den virtuelle konsol fra dit instrumentbræt til at logge ind med dit brugernavn og din adgangskode.

I modsat fald skal du bruge en administrativ bruger, der har sudoadgang; sørg for ikke at aktivere MFA for denne bruger, men kun bruge en SSH-nøgle. Hvis du eller en anden bruger mister deres hemmelige nøgle og ikke kan logge ind, kan den administrative bruger logge ind og hjælpe med at gendanne eller regenerere nøglen for enhver bruger ved hjælp af sudo.

Når du er logget ind, er der to måder at hjælpe med at få den hemmelige TOTP-nøgle på:

1. Gendag den eksisterende nøgle
2. Generer en ny nøgle

I hver brugers hjemmemappe gemmes den hemmelige nøgle og Google Authenticator-indstillingerne i ~/.google-authenticator. Den allerførste linje i denne fil er en hemmelig nøgle. En hurtig måde at få fat i nøglen på er at udføre følgende kommando, som viser den første linje i filen google-authenticator (dvs. den hemmelige nøgle). Tag derefter den hemmelige nøgle og skriv den manuelt ind i en TOTP-app.

head -n 1 /home/sammy/.google_authenticator

Hvis der er en grund til ikke at bruge den eksisterende nøgle (f.eks. fordi du ikke nemt kan dele den hemmelige nøgle sikkert med den berørte bruger, eller fordi den eksisterende nøgle er blevet kompromitteret), kan du fjerne ~/.google-authenticator-filen helt og holdent. Dette vil gøre det muligt for brugeren at logge ind igen ved hjælp af kun en enkelt faktor, forudsat at du ikke har håndhævet MFA ved at fjerne “nullok” i filen “/etc/pam.d/sshd”. De kan derefter køre google-authenticator for at generere en ny nøgle.

Lever du adgang til TOTP-appen

Hvis du har brug for at logge ind på din server, men ikke har adgang til din TOTP-app for at få din bekræftelseskode, kan du stadig logge ind ved hjælp af de genoprettelseskoder, der blev vist, da du først oprettede din hemmelige nøgle. Bemærk, at disse gendannelseskoder er til engangsbrug. Når først en er brugt til at logge ind, kan den ikke bruges som bekræftelseskode igen.

Tip 2 – Ændring af godkendelsesindstillinger

Hvis du ønsker at ændre dine MFA-indstillinger efter den oprindelige konfiguration, kan du i stedet for at generere en ny konfiguration med de opdaterede indstillinger blot redigere ~/.google-authenticator-filen i stedet for at generere en ny konfiguration med de opdaterede indstillinger. Denne fil er opbygget på følgende måde:

<secret key><options><recovery codes>

Optioner, der er indstillet i denne fil, har en linje i afsnittet indstillinger; hvis du svarede “nej” til en bestemt indstilling under den første opsætning, er den tilsvarende linje udelukket fra filen.

Her er de ændringer, du kan foretage i denne fil:

• For at aktivere sekventielle koder i stedet for tidsbaserede koder skal du ændre linjen " TOTP_AUTH til " HOTP_COUNTER 1.
• For at tillade flere anvendelser af en enkelt kode skal du fjerne linjen " DISALLOW_REUSE.
• For at udvide kodeudløbsvinduet til 4 minutter skal du tilføje linjen " WINDOW_SIZE 17.
• For at deaktivere flere fejlslagne logins (hastighedsbegrænsning) skal du fjerne linjen " RATE_LIMIT 3 30.
• For at ændre tærsklen for hastighedsbegrænsning skal du finde linjen " RATE_LIMIT 3 30 og justere tallene. 3 i originalen angiver antallet af forsøg over en periode, og 30 angiver tidsrummet i sekunder.
• For at deaktivere brugen af genoprettelseskoder skal du fjerne de fem 8-cifrede koder nederst i filen.

Tip 3 – Undgå MFA for nogle konti

Der kan være en situation, hvor en enkelt bruger eller nogle få tjenestekonti (dvs. konti, der bruges af programmer og ikke af mennesker) har brug for SSH-adgang uden at MFA er aktiveret. Nogle programmer, der bruger SSH, som f.eks. nogle FTP-klienter, understøtter måske ikke MFA. Hvis et program ikke har en måde at anmode om verifikationskoden på, kan anmodningen blive hængende, indtil SSH-forbindelsen går i stå.

Så længe et par indstillinger i /etc/pam.d/sshd er indstillet korrekt, kan du styre, hvilke faktorer der bruges på brugerbasis.

For at tillade MFA for nogle konti og kun SSH-nøgle for andre skal du sørge for, at følgende indstillinger i /etc/pam.d/sshd er aktive.

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

Her er auth substack password-auth udkommenteret, fordi adgangskoder skal deaktiveres. MFA kan ikke tvinges, hvis det er meningen, at nogle konti skal have MFA deaktiveret, så lad nullok-indstillingen stå på den sidste linje.

Når du har indstillet denne konfiguration, skal du blot køre google-authenticator som alle brugere, der har brug for MFA, og ikke køre den for brugere, hvor der kun skal bruges SSH-nøgler.

Tip 4 – Automatiseret opsætning med konfigurationshåndtering

Mange systemadministratorer bruger konfigurationshåndteringsværktøjer som Puppet, Chef eller Ansible til at administrere deres systemer. Hvis du vil bruge et system som dette til at installere opsætte en hemmelig nøgle, når en ny brugerkonto oprettes, er der en metode til at gøre det.

google-authenticator understøtter kommandolinjeskifter til at indstille alle indstillingerne i en enkelt, ikke-interaktiv kommando. Hvis du vil se alle indstillingerne, kan du skrive google-authenticator --help. Nedenfor er kommandoen, der ville indstille alt som skitseret i trin 1:

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

Dette besvarer alle de spørgsmål, vi besvarede manuelt, gemmer dem i en fil og udsender derefter den hemmelige nøgle, QR-koden og genoprettelseskoderne. (Hvis du tilføjer flaget -q, vil der ikke være noget output.) Hvis du bruger denne kommando på en automatiseret måde, skal du sørge for at registrere den hemmelige nøgle og/eller genoprettelseskoderne og gøre dem tilgængelige for brugeren.

Tip 5 – Tvinge MFA for alle brugere

Hvis du ønsker at tvinge MFA for alle brugere, selv ved det første login, eller hvis du foretrækker ikke at stole på, at dine brugere genererer deres egne nøgler, er der en nem måde at håndtere dette på. Du kan simpelthen bruge den samme .google-authenticator fil til hver bruger, da der ikke er gemt brugerspecifikke data i filen.

For at gøre dette, skal en privilegeret bruger, efter at konfigurationsfilen er oprettet første gang, kopiere filen til roden af hver hjemmemappe og ændre dens tilladelser til den relevante bruger. Du kan også kopiere filen til /etc/skel/, så den automatisk kopieres over i en ny brugers hjemmemappe, når den oprettes.

Varsling: Dette kan være en sikkerhedsrisiko, fordi alle deler den samme anden faktor. Det betyder, at hvis den lækkes, er det som om alle brugere kun havde én faktor. Tag dette i betragtning, hvis du vil bruge denne fremgangsmåde.

En anden metode til at fremtvinge oprettelsen af en brugers hemmelige nøgle er at bruge et bash-script, der:

1. Opret et TOTP-token,
2. opfordrer dem til at downloade Google Authenticator-appen og scanne den QR-kode, der vises, og
3. afvikler google-authenticator-applikationen for dem efter at have kontrolleret, om .google-authenticator-filen allerede findes.

For at sikre, at scriptet kører, når en bruger logger ind, kan du navngive det .bash_login og placere det i roden af deres hjemmemappe.

Slutning

Det sagt, ved at have to faktorer (en SSH-nøgle + MFA-token) på tværs af to kanaler (din computer + din telefon), har du gjort det meget svært for en ekstern agent at brute force sig ind på din maskine via SSH og øget sikkerheden på din maskine betydeligt.