Så här konfigurerar du flerfaktorsautentisering för SSH på CentOS 7

Introduktion

En autentiseringsfaktor är en enskild information som används för att bevisa att du har rätt att utföra en åtgärd, som att logga in i ett system. En autentiseringskanal är det sätt på vilket ett autentiseringssystem levererar en faktor till användaren eller kräver att användaren svarar. Lösenord och säkerhetstoken är exempel på autentiseringsfaktorer; datorer och telefoner är exempel på kanaler.

SSH använder lösenord för autentisering som standard, och de flesta SSH-härdningsinstruktioner rekommenderar att man istället använder en SSH-nyckel. Detta är dock fortfarande bara en enda faktor. Om en dålig aktör har komprometterat din dator kan de använda din nyckel för att kompromettera dina servrar också.

I den här handledningen ska vi konfigurera flerfaktorsautentisering för att motverka detta. Flerfaktorsautentisering (MFA) kräver mer än en faktor för att autentisera eller logga in. Detta innebär att en dålig aktör måste äventyra flera saker, till exempel både din dator och din telefon, för att komma in. De olika typerna av faktorer sammanfattas ofta som:

1. Något du vet, som ett lösenord eller en säkerhetsfråga
2. Något du har, som en autentiseringsapp eller en säkerhetstoken
3. Något du är, som ditt fingeravtryck eller din röst

En vanlig faktor är en OATH-TOTP-app, som Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) är ett öppet protokoll som genererar ett engångslösenord, vanligen ett sexsiffrigt nummer som återanvänds var 30:e sekund.

Denna artikel kommer att gå igenom hur du aktiverar SSH-autentisering med hjälp av en OATH-TOTP-app utöver en SSH-nyckel. När du loggar in på din server via SSH krävs då två faktorer i två kanaler, vilket gör det säkrare än enbart ett lösenord eller en SSH-nyckel. Dessutom går vi igenom några ytterligare användningsområden för MFA och några användbara tips och tricks.

Förutsättningar

För att följa den här handledningen behöver du:

• En CentOS 7-server med en sudo icke-root-användare och SSH-nyckel, som du kan konfigurera genom att följa den här handledningen för inledande serverinstallation.
• En smartphone eller surfplatta med en OATH-TOTP-app installerad, till exempel Google Authenticator (iOS, Android).

Steg 1 – Installera Googles PAM

I det här steget installerar och konfigurerar vi Googles PAM.

PAM, som står för Pluggable Authentication Module, är en autentiseringsinfrastruktur som används på Linuxsystem för att autentisera en användare. Eftersom Google gjorde en OATH-TOTP-app har de också gjort en PAM som genererar TOTP:er och är helt kompatibel med alla OATH-TOTP-appar, som Google Authenticator eller Authy.

Först måste vi lägga till EPEL-repoen (Extra Packages for Enterprise Linux).

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

Nästan installerar vi PAM. Du kan bli ombedd att acceptera EPEL-nyckeln om det är första gången du använder repo:n. När du väl har accepterat kommer du inte att uppmanas igen att acceptera nyckeln.

sudo yum install google-authenticator

Med PAM installerad kommer vi att använda en hjälpprogram som följer med PAM för att generera en TOTP-nyckel för den användare som du vill lägga till en andra faktor för. Den här nyckeln genereras för varje enskild användare, inte för hela systemet. Det betyder att varje användare som vill använda en TOTP-auth-app måste logga in och köra hjälpprogrammet för att få sin egen nyckel; du kan inte bara köra det en gång för att aktivera det för alla (men det finns några tips i slutet av den här handledningen för att konfigurera eller kräva MFA för många användare).

Kör initialiseringsappen.

google-authenticator

När du kör kommandot kommer du att få några frågor. Den första frågar om autentiseringstoken ska vara tidsbaserade.

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

Denna PAM tillåter tidsbaserade eller sekventiellt baserade tokens. Om man använder sekvensbaserade tokens innebär det att koden börjar vid en viss punkt och att koden sedan ökas efter varje användning. Användning av tidsbaserade tokens innebär att koden ändras slumpmässigt efter en viss tid. Vi håller oss till tidsbaserade eftersom det är vad appar som Google Authenticator räknar med, så svara y för ja.

När du har svarat på den här frågan kommer en hel del utdata att rulla förbi, bland annat en stor QR-kod. Vid det här laget kan du använda din Authenticator-app på telefonen för att skanna QR-koden eller manuellt skriva in den hemliga nyckeln. Om QR-koden är för stor för att skanna kan du använda webbadressen ovanför QR-koden för att få en mindre version. När den har lagts till ser du en sexsiffrig kod som ändras var 30:e sekund i din app.

Notera: Se till att du registrerar den hemliga nyckeln, verifieringskoden och återställningskoderna på ett säkert ställe, till exempel i en lösenordshanterare. Återställningskoderna är det enda sättet att återfå tillgång om du till exempel förlorar tillgången till din TOTP-app.

De återstående frågorna informerar PAM om hur den ska fungera. Vi går igenom dem en efter en.

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

Detta skriver nyckeln och alternativen till filen .google_authenticator. Om du svarar nej avslutas programmet och inget skrivs, vilket innebär att autentiseraren inte fungerar.

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

Om du svarar ja här förhindrar du en replay-attack genom att varje kod upphör att gälla omedelbart efter användning. Detta förhindrar en angripare från att fånga en kod du just använt och logga in 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

Svarar du ja här tillåts upp till 8 giltiga koder i ett rörligt fönster på fyra minuter. Genom att svara nej begränsar du det till 3 giltiga koder i ett rullande fönster på 1:30 minuter. Om du inte har problem med fönstret på 1:30 minuter är det säkrare att svara 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

Skattbegränsning innebär att en fjärrangripare bara kan försöka göra ett visst antal gissningar innan han eller hon blockeras. Om du inte tidigare har konfigurerat hastighetsbegränsning direkt i SSH är det en bra härdningsteknik att göra det nu.

Notera: När du är klar med den här inställningen kan du kopiera ~/.google-authenticator-filen till en betrodd plats om du vill säkerhetskopiera din hemliga nyckel. Därifrån kan du distribuera den på ytterligare system eller distribuera om den efter en säkerhetskopiering.

När Googles PAM är installerad och konfigurerad är nästa steg att konfigurera SSH för att använda din TOTP-nyckel. Vi måste berätta för SSH om PAM och sedan konfigurera SSH för att använda den.

Steg 2 – Konfigurera OpenSSH

Då vi kommer att göra SSH-ändringar via SSH är det viktigt att aldrig stänga den första SSH-anslutningen. Öppna istället en andra SSH-session för att göra tester. Detta för att undvika att du låser dig ute från din server om det skulle vara ett misstag i din SSH-konfiguration. När allt fungerar kan du tryggt stänga alla sessioner.

För att börja redigerar vi konfigurationsfilen sshd. Här använder vi nano, som inte är installerad på CentOS som standard. Du kan installera den med sudo yum install nano eller använda din alternativa textredigerare.

sudo nano /etc/pam.d/sshd

Lägg till följande rad längst ner i filen.

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

Värdet nullok i slutet av den sista raden talar om för PAM att den här autentiseringsmetoden är frivillig. Detta gör det möjligt för användare utan OATH-TOTP-token att ändå logga in med sin SSH-nyckel. När alla användare har en OATH-TOTP-token kan du ta bort nullok från den här raden för att göra MFA obligatorisk.

Spara och stäng filen.

Nästan ska vi konfigurera SSH så att den här typen av autentisering stöds. Öppna SSH-konfigurationsfilen för redigering.

sudo nano /etc/ssh/sshd_config

Leta efter ChallengeResponseAuthentication-linjer. Kommentera ut no-linjen och avkommentera no-linjen.

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

Spara och stäng filen och starta sedan om SSH för att ladda om konfigurationsfilerna. Om du startar om sshd-tjänsten stänger inte öppna anslutningar, så du riskerar inte att låsa dig själv med det här kommandot.

sudo systemctl restart sshd.service

För att testa att allting fungerar så här långt öppnar du en annan terminal och försöker logga in via SSH. Om du tidigare har skapat en SSH-nyckel och använder den kommer du att märka att du inte behövde skriva in användarens lösenord eller MFA-verifieringskoden. Detta beror på att en SSH-nyckel åsidosätter alla andra autentiseringsalternativ som standard. Annars skulle du ha fått ett lösenord och en verifieringskod.

Om du vill försäkra dig om att det du har gjort hittills fungerar, kan du i din öppna SSH-session navigera till ~/.ssh/ och byta namn på filen authorized_keys, tillfälligt, öppna en ny session och logga in med vårt lösenord och vår verifieringskod.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

När du väl har verifierat att din TOTP-token fungerar, byter du namn på filen ”authorized_keys.bak”-filen tillbaka till vad den var.

mv authorized_keys.bak authorized_keys

Nästan måste vi aktivera en SSH-nyckel som en faktor och verifieringskoden som en andra och tala om för SSH vilka faktorer som ska användas och förhindra att SSH-nyckeln åsidosätter alla andra typer.

Steg 3 – Att göra SSH medveten om MFA

Öppna konfigurationsfilen sshd på nytt.

sudo nano /etc/ssh/sshd_config

Lägg till följande rad längst ner i filen. Detta talar om för SSH vilka autentiseringsmetoder som krävs. Den här raden talar om för SSH att vi behöver en SSH-nyckel och antingen ett lösenord eller en verifieringskod (eller alla tre).

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

Spara och stäng filen.

Öppna sedan konfigurationsfilen för PAM sshd igen.

sudo nano /etc/pam.d/sshd

Leta upp raden auth substack password-auth längst upp i filen. Kommentera ut den genom att lägga till ett #-tecken som första tecken på raden. Detta säger åt PAM att inte fråga efter ett lösenord.

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

Spara och stäng filen och starta sedan om SSH.

sudo systemctl restart sshd.service

Försök nu att logga in på servern igen med en annan session. Till skillnad från förra gången bör SSH be om din verifieringskod. När du anger den kommer du att vara inloggad. Även om du inte ser någon indikation på att din SSH-nyckel användes använde ditt inloggningsförsök två faktorer. Om du vill kontrollera kan du lägga till -v (för verbose) efter SSH-kommandot:

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:

Till slutet av utmatningen ser du där SSH använder din SSH-nyckel och sedan frågar efter verifieringskoden. Du kan nu logga in via SSH med en SSH-nyckel och ett engångslösenord. Om du vill tvinga fram alla tre autentiseringstyperna kan du följa nästa steg.

Steg 4 – Lägg till en tredje faktor (valfritt)

I steg 3 listade vi de godkända autentiseringstyperna i sshd_config-filen:

1. publickey (SSH-nyckel)
2. password publickey (lösenord)
3. keyboard-interactive (verifieringskod)

Och även om vi listade tre olika faktorer, med de alternativ som vi har valt hittills, tillåter de bara en SSH-nyckel och verifieringskoden. Om du vill ha alla tre faktorerna (SSH-nyckel, lösenord och verifieringskod) kan du med en snabb ändring aktivera alla tre.

Öppna PAM sshd-konfigurationsfilen.

sudo nano /etc/pam.d/sshd

Lokalisera raden som du kommenterade tidigare, #auth substack password-auth, och ta bort kommentaren från raden genom att ta bort #-tecknet. Spara och stäng filen. Starta nu återigen om SSH.

sudo systemctl restart sshd.service

Då PAM aktiverar alternativet auth substack password-auth kommer PAM nu att be om ett lösenord utöver att kontrollera om det finns en SSH-nyckel och be om en verifieringskod, vilket vi hade fungerat tidigare. Nu kan vi använda något vi vet (lösenord) och två olika typer av saker vi har (SSH-nyckel och verifieringskod) över två olika kanaler.

Den här artikeln har hittills beskrivit hur man aktiverar MFA med en SSH-nyckel och ett tidsbaserat engångslösenord. Om detta är allt du behöver kan du sluta här. Detta är dock inte det enda sättet att göra flerfaktorsautentisering. Nedan finns ytterligare ett par sätt att använda den här PAM-modulen för flerfaktorsautentisering och några tips och tricks för återställning, automatiserad användning med mera.

Tip 1 – Återställning av åtkomst

Som med alla system som du härdar och säkrar blir du ansvarig för att hantera den säkerheten. I det här fallet innebär det att du inte får förlora din SSH-nyckel eller din hemliga TOTP-nyckel och att du måste se till att du har tillgång till din TOTP-app. Ibland händer dock saker och ting och du kan förlora kontrollen över de nycklar eller appar som du behöver för att komma in.

Förlorar du en SSH-nyckel eller en hemlig TOTP-nyckel

Om du förlorar din SSH-nyckel eller din hemliga TOTP-nyckel kan återhämtningen delas upp i ett par steg. Det första är att komma in igen utan att känna till verifieringskoden och det andra är att hitta den hemliga nyckeln eller återskapa den för normal MFA-inloggning.

För att komma in efter att ha förlorat den hemliga nyckeln som genererar verifieringskoden på en DigitalOcean-droplet kan du helt enkelt använda den virtuella konsolen från instrumentbrädan för att logga in med ditt användarnamn och lösenord.

I annat fall behöver du en administrativ användare med sudo-åtkomst; se till att du inte aktiverar MFA för den här användaren, utan använd bara en SSH-nyckel. Om du eller en annan användare förlorar sin hemliga nyckel och inte kan logga in kan den administrativa användaren logga in och hjälpa till att återställa eller regenerera nyckeln för alla användare som använder sudo.

När du väl är inloggad finns det två sätt att hjälpa till att få fram TOTP-hemligheten:

1. Återskapa den befintliga nyckeln
2. Generera en ny nyckel

I varje användares hemkatalog sparas den hemliga nyckeln och inställningarna för Google Authenticator i ~/.google-authenticator. Den allra första raden i den här filen är en hemlig nyckel. Ett snabbt sätt att få fram nyckeln är att utföra följande kommando, som visar den första raden i filen google-authenticator (dvs. den hemliga nyckeln). Ta sedan den hemliga nyckeln och skriv in den manuellt i en TOTP-app.

head -n 1 /home/sammy/.google_authenticator

Om det finns en anledning att inte använda den befintliga nyckeln (t.ex. om du inte enkelt kan dela den hemliga nyckeln med den påverkade användaren på ett säkert sätt eller om den befintliga nyckeln har äventyrats) kan du ta bort ~/.google-authenticator-filen helt och hållet. Detta kommer att göra det möjligt för användaren att logga in igen med hjälp av endast en enda faktor, förutsatt att du inte har tvingat fram MFA genom att ta bort ”nullok” i filen ”/etc/pam.d/sshd”. De kan sedan köra google-authenticator för att generera en ny nyckel.

Lös tillgång till TOTP-appen

Om du behöver logga in på din server men inte har tillgång till din TOTP-app för att få din verifieringskod kan du fortfarande logga in med hjälp av återställningskoderna som visades när du först skapade din hemliga nyckel. Observera att dessa återställningskoder är engångskoder. När en sådan används för att logga in kan den inte användas som verifieringskod igen.

Tip 2 – Ändra autentiseringsinställningar

Om du vill ändra dina MFA-inställningar efter den första konfigurationen kan du istället för att generera en ny konfiguration med de uppdaterade inställningarna bara redigera ~/.google-authenticator-filen. Den här filen är upplagd på följande sätt:

<secret key><options><recovery codes>

Optioner som ställs in i den här filen har en rad i avsnittet alternativ; om du svarade ”nej” till ett visst alternativ under den första konfigurationen utesluts motsvarande rad från filen.

Här är de ändringar du kan göra i den här filen:

• För att möjliggöra sekventiella koder i stället för tidsbaserade koder ändrar du raden " TOTP_AUTH till " HOTP_COUNTER 1.
• För att möjliggöra flera användningar av en enda kod tar du bort raden " DISALLOW_REUSE.
• För att utöka kodens förfallningsfönster till 4 minuter lägger du till raden " WINDOW_SIZE 17.
• För att inaktivera flera misslyckade inloggningar (hastighetsbegränsning) tar du bort raden " RATE_LIMIT 3 30.
• För att ändra tröskelvärdet för hastighetsbegränsning hittar du raden " RATE_LIMIT 3 30 och justerar siffrorna. 3 i originalet anger antalet försök under en tidsperiod och 30 anger tidsperioden i sekunder.
• För att inaktivera användningen av återställningskoder tar du bort de fem 8-siffriga koderna längst ner i filen.

Tip 3 – Undvik MFA för vissa konton

Det kan finnas en situation där en enskild användare eller några tjänstekonton (dvs. konton som används av program, inte människor) behöver SSH-åtkomst utan att MFA är aktiverat. Vissa program som använder SSH, t.ex. vissa FTP-klienter, har kanske inte stöd för MFA. Om ett program inte har ett sätt att begära verifieringskoden kan begäran fastna tills SSH-anslutningen tar slut.

Så länge ett par alternativ i /etc/pam.d/sshd är korrekt inställda kan du styra vilka faktorer som används för varje enskild användare.

För att tillåta MFA för vissa konton och endast SSH-nyckel för andra, se till att följande inställningar i /etc/pam.d/sshd är aktiva.

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

Här kommenteras auth substack password-auth ut eftersom lösenord måste inaktiveras. MFA kan inte tvingas fram om det är meningen att vissa konton ska ha MFA inaktiverat, så lämna alternativet nullok på sista raden.

När du har ställt in den här konfigurationen kör du helt enkelt google-authenticator som alla användare som behöver MFA, och kör det inte för användare där endast SSH-nycklar kommer att användas.

Tip 4 – Automatisering av konfigurationen med konfigurationshantering

Många systemadministratörer använder konfigurationshanteringsverktyg som Puppet, Chef eller Ansible för att hantera sina system. Om du vill använda ett sådant system för att installera en hemlig nyckel när ett nytt användarkonto skapas finns det en metod för att göra det.

google-authenticator har stöd för kommandoradsväxlar för att ställa in alla alternativ i ett enda, icke-interaktivt kommando. För att se alla alternativ kan du skriva google-authenticator --help. Nedan är kommandot som skulle ställa in allt enligt steg 1:

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

Detta svarar på alla frågor som vi besvarade manuellt, sparar dem i en fil och ger sedan ut den hemliga nyckeln, QR-koden och återställningskoderna. (Om du lägger till flaggan -q blir det ingen utdata.) Om du använder det här kommandot på ett automatiserat sätt, se till att fånga den hemliga nyckeln och/eller återställningskoderna och göra dem tillgängliga för användaren.

Tip 5 – Forcera MFA för alla användare

Om du vill tvinga fram MFA för alla användare även vid den första inloggningen, eller om du föredrar att inte förlita dig på att användarna ska generera sina egna nycklar, finns det ett enkelt sätt att hantera detta. Du kan helt enkelt använda samma .google-authenticator-fil för varje användare, eftersom det inte finns några användarspecifika data lagrade i filen.

För att göra detta, efter att konfigurationsfilen skapats initialt, måste en privilegierad användare kopiera filen till roten av varje hemkatalog och ändra dess behörigheter till lämplig användare. Du kan också kopiera filen till /etc/skel/ så att den automatiskt kopieras över till en ny användares hemkatalog när den skapas.

Varning: Detta kan vara en säkerhetsrisk eftersom alla delar samma andra faktor. Detta innebär att om den läcker ut är det som om varje användare bara hade en faktor. Ta detta i beaktande om du vill använda detta tillvägagångssätt.

En annan metod för att tvinga fram skapandet av en användares hemliga nyckel är att använda ett bash-skript som:

1. skapar en TOTP-token,
2. uppmanar dem att ladda ner appen Google Authenticator och skanna QR-koden som kommer att visas, och
3. kör google-authenticator-applikationen åt dem efter att ha kontrollerat om .google-authenticator-filen redan finns.

För att se till att skriptet körs när en användare loggar in kan du namnge det .bash_login och placera det i roten av deras hemkatalog.

Slutsats

Detta sagt, genom att ha två faktorer (en SSH-nyckel + MFA-token) i två kanaler (din dator + din telefon), har du gjort det mycket svårt för en utomstående agent att med hjälp av brutal kraft ta sig in i din dator via SSH och ökat säkerheten på din dator avsevärt.