Come impostare l’autenticazione a più fattori per SSH su CentOS 7

Introduzione

Un fattore di autenticazione è una singola informazione usata per provare di avere i diritti di eseguire un’azione, come entrare in un sistema. Un canale di autenticazione è il modo in cui un sistema di autenticazione fornisce un fattore all’utente o richiede all’utente di rispondere. Le password e i token di sicurezza sono esempi di fattori di autenticazione; i computer e i telefoni sono esempi di canali.

SSH usa le password per l’autenticazione per default, e la maggior parte delle istruzioni di hardening di SSH raccomandano invece di usare una chiave SSH. Tuttavia, questo è ancora solo un singolo fattore. Se un cattivo attore ha compromesso il tuo computer, allora può usare la tua chiave per compromettere anche i tuoi server.

In questo tutorial, imposteremo l’autenticazione a più fattori per combattere ciò. L’autenticazione a più fattori (MFA) richiede più di un fattore per l’autenticazione o l’accesso. Questo significa che un cattivo attore dovrebbe compromettere più cose, come il tuo computer e il tuo telefono, per entrare. I diversi tipi di fattori sono spesso riassunti come:

1. Qualcosa che conosci, come una password o una domanda di sicurezza
2. Qualcosa che hai, come un’app di autenticazione o un token di sicurezza
3. Qualcosa che sei, come la tua impronta digitale o voce

Un fattore comune è un’app OATH-TOTP, come Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) è un protocollo aperto che genera una password monouso, comunemente un numero di 6 cifre che viene riciclato ogni 30 secondi.

Questo articolo esaminerà come abilitare l’autenticazione SSH utilizzando un’app OATH-TOTP oltre a una chiave SSH. L’accesso al vostro server via SSH richiederà quindi due fattori su due canali, rendendolo così più sicuro di una password o di una chiave SSH da sola. Inoltre, esamineremo alcuni casi d’uso aggiuntivi per l’MFA e alcuni utili suggerimenti e trucchi.

Prequisiti

Per seguire questo tutorial, avrete bisogno di:

• Un server CentOS 7 con un utente sudo non-root e una chiave SSH, che potete impostare seguendo questo tutorial Initial Server Setup.
• Uno smartphone o tablet con un’applicazione OATH-TOTP installata, come Google Authenticator (iOS, Android).

Passo 1 – Installare PAM di Google

In questo passo, installeremo e configureremo PAM di Google.

PAM, che sta per Pluggable Authentication Module, è un’infrastruttura di autenticazione usata sui sistemi Linux per autenticare un utente. Poiché Google ha fatto un’applicazione OATH-TOTP, ha anche fatto un PAM che genera TOTP ed è pienamente compatibile con qualsiasi applicazione OATH-TOTP, come Google Authenticator o Authy.

Prima di tutto, dobbiamo aggiungere il repo EPEL (Extra Packages for Enterprise Linux).

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

Poi, installate il PAM. Ti potrebbe essere richiesto di accettare la chiave EPEL se questa è la prima volta che usi il repo. Una volta accettata non ti verrà più richiesto di accettare la chiave.

sudo yum install google-authenticator

Con il PAM installato, useremo un’app di aiuto che viene fornita con il PAM per generare una chiave TOTP per l’utente a cui vuoi aggiungere un secondo fattore. Questa chiave è generata su base utente per utente, non a livello di sistema. Questo significa che ogni utente che vuole usare un’app di autenticazione TOTP avrà bisogno di accedere ed eseguire l’app di aiuto per ottenere la propria chiave; non puoi semplicemente eseguirla una volta per abilitarla per tutti (ma ci sono alcuni suggerimenti alla fine di questo tutorial per impostare o richiedere l’MFA per molti utenti).

Esegui l’app di inizializzazione.

google-authenticator

Dopo aver eseguito il comando, ti verranno poste alcune domande. La prima chiede se i token di autenticazione devono essere basati sul tempo.

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

Questa PAM permette token basati sul tempo o sequenziali. Usare token basati sul tempo significa che il codice inizia ad un certo punto e poi incrementa il codice dopo ogni uso. Usare token basati sul tempo significa che il codice cambia in modo casuale dopo un certo tempo. Continueremo a usare quelli basati sul tempo perché è quello che le applicazioni come Google Authenticator prevedono, quindi rispondi y per sì.

Dopo aver risposto a questa domanda, scorrerà un sacco di output, compreso un grande codice QR. A questo punto, usa la tua app authenticator sul tuo telefono per scansionare il codice QR o digita manualmente la chiave segreta. Se il codice QR è troppo grande da scansionare, puoi usare l’URL sopra il codice QR per ottenere una versione più piccola. Una volta aggiunto, vedrai un codice a sei cifre che cambia ogni 30 secondi nella tua app.

Nota: Assicurati di registrare la chiave segreta, il codice di verifica e i codici di recupero in un posto sicuro, come un gestore di password. I codici di recupero sono l’unico modo per riottenere l’accesso se, per esempio, perdi l’accesso alla tua app TOTP.

Le domande rimanenti informano il PAM sul suo funzionamento. Le esamineremo una per una.

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

Questo scrive la chiave e le opzioni nel file .google_authenticator. Se dite no, il programma esce e non viene scritto nulla, il che significa che l’autenticatore non funzionerà.

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

Rispondendo sì qui, state prevenendo un attacco di replay facendo scadere ogni codice immediatamente dopo l’uso. Questo impedisce a un aggressore di catturare un codice appena usato e loggarsi con esso.

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

Rispondendo sì qui si possono avere fino a 8 codici validi in una finestra mobile di quattro minuti. Rispondendo no, lo si limita a 3 codici validi in una finestra mobile di 1:30 minuti. A meno che non troviate problemi con la finestra di 1:30 minuti, rispondere no è la scelta più sicura.

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

La limitazione della velocità significa che un attaccante remoto può tentare solo un certo numero di tentativi prima di essere bloccato. Se non avete precedentemente configurato il rate limiting direttamente in SSH, farlo ora è una grande tecnica di hardening.

Nota: Una volta che avete finito questa configurazione, se volete fare il backup della vostra chiave segreta, potete copiare il file ~/.google-authenticator in un luogo fidato. Da lì, puoi distribuirlo su altri sistemi o distribuirlo nuovamente dopo un backup.

Ora che il PAM di Google è installato e configurato, il prossimo passo è configurare SSH per usare la tua chiave TOTP. Avremo bisogno di dire a SSH del PAM e poi configurare SSH per usarlo.

Passo 2 – Configurare OpenSSH

Perché faremo dei cambiamenti SSH su SSH, è importante non chiudere mai la tua connessione SSH iniziale. Invece, apri una seconda sessione SSH per fare dei test. Questo per evitare di bloccarti fuori dal tuo server se ci fosse un errore nella tua configurazione SSH. Una volta che tutto funziona, allora puoi tranquillamente chiudere qualsiasi sessione.

Per iniziare modificheremo il file di configurazione sshd. Qui stiamo usando nano, che non è installato di default su CentOS. Puoi installarlo con sudo yum install nano, o usare il tuo editor di testo alternativo preferito.

sudo nano /etc/pam.d/sshd

Aggiungi la seguente linea alla fine del file.

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

La parola nullok alla fine dell’ultima linea dice al PAM che questo metodo di autenticazione è opzionale. Questo permette agli utenti che non hanno un token OATH-TOTP di accedere comunque usando la loro chiave SSH. Una volta che tutti gli utenti hanno un token OATH-TOTP, puoi rimuovere nullok da questa linea per rendere l’MFA obbligatoria.

Salva e chiudi il file.

In seguito, configureremo SSH per supportare questo tipo di autenticazione. Aprire il file di configurazione SSH per la modifica.

sudo nano /etc/ssh/sshd_config

Cercare le linee ChallengeResponseAuthentication. Commentate la linea no e decommentate la linea no.

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

Salva e chiudi il file, poi riavvia SSH per ricaricare i file di configurazione. Riavviare il servizio sshd non chiuderà le connessioni aperte, quindi non rischierai di chiuderti fuori con questo comando.

sudo systemctl restart sshd.service

Per testare che tutto funzioni finora, apri un altro terminale e prova a loggarti su SSH. Se hai precedentemente creato una chiave SSH e la stai usando, noterai che non hai dovuto digitare la password del tuo utente o il codice di verifica MFA. Questo perché una chiave SSH sovrascrive tutte le altre opzioni di autenticazione per impostazione predefinita. Altrimenti, avresti dovuto ottenere una richiesta di password e codice di verifica.

Se vuoi assicurarti che quello che hai fatto finora funzioni, nella tua sessione SSH aperta naviga fino a ~/.ssh/ e rinomina il file authorized_keys, temporaneamente, e apri una nuova sessione ed entra con la nostra password e codice di verifica.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Una volta verificato che il tuo token TOTP funziona rinomina il file ‘authorized_keys.bak’ a quello che era.

mv authorized_keys.bak authorized_keys

Prossimo, dobbiamo abilitare una chiave SSH come fattore e il codice di verifica come secondo e dire a SSH quali fattori usare e prevenire che la chiave SSH sovrascriva tutti gli altri tipi.

Step 3 – Rendere SSH consapevole di MFA

Riaprire il file di configurazione sshd.

sudo nano /etc/ssh/sshd_config

Aggiungere la seguente linea in fondo al file. Questo dice a SSH quali metodi di autenticazione sono richiesti. Questa linea dice a SSH che abbiamo bisogno di una chiave SSH e una password o un codice di verifica (o tutti e tre).

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

Salva e chiudi il file.

In seguito, apri nuovamente il file di configurazione PAM sshd.

sudo nano /etc/pam.d/sshd

Trova la linea auth substack password-auth verso l’inizio del file. Commentatela aggiungendo un carattere # come primo carattere sulla linea. Questo dice a PAM di non richiedere la password.

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

Salva e chiudi il file, poi riavvia SSH.

sudo systemctl restart sshd.service

Ora prova ad accedere nuovamente al server con una sessione diversa. A differenza dell’ultima volta, SSH dovrebbe chiedere il tuo codice di verifica. Dopo averlo inserito, sarai loggato. Anche se non vedi alcuna indicazione che la tua chiave SSH è stata usata, il tuo tentativo di login ha usato due fattori. Se vuoi verificare, puoi aggiungere -v (per verbose) dopo il comando SSH:

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:

Verso la fine dell’output, vedrai dove SSH usa la tua chiave SSH e poi chiede il codice di verifica. Ora puoi accedere tramite SSH con una chiave SSH e una password monouso. Se vuoi applicare tutti e tre i tipi di autenticazione, puoi seguire il prossimo passo.

Passo 4 – Aggiungere un terzo fattore (opzionale)

Nel passo 3, abbiamo elencato i tipi di autenticazione approvati nel file sshd_config:

1. publickey (chiave SSH)
2. password publickey (password)
3. keyboard-interactive (codice di verifica)

Anche se abbiamo elencato tre diversi fattori, con le opzioni che abbiamo scelto finora, permettono solo una chiave SSH e il codice di verifica. Se volete avere tutti e tre i fattori (chiave SSH, password e codice di verifica), un rapido cambiamento li abiliterà tutti e tre.

Aprite il file di configurazione PAM sshd.

sudo nano /etc/pam.d/sshd

Cercate la linea che avete commentato precedentemente, #auth substack password-auth, e decommentate la linea rimuovendo il carattere #. Salvate e chiudete il file. Ora, ancora una volta, riavviate SSH.

sudo systemctl restart sshd.service

Abilitando l’opzione auth substack password-auth, PAM ora richiederà una password oltre a controllare una chiave SSH e a chiedere un codice di verifica, che funzionava in precedenza. Ora possiamo usare qualcosa che conosciamo (password) e due diversi tipi di cose che abbiamo (chiave SSH e codice di verifica) su due canali diversi.

Finora, questo articolo ha descritto come abilitare l’MFA con una chiave SSH e una password monouso basata sul tempo. Se questo è tutto ciò di cui avete bisogno, potete finire qui. Tuttavia, questo non è l’unico modo per fare l’autenticazione a più fattori. Di seguito ci sono un paio di modi aggiuntivi di usare questo modulo PAM per l’autenticazione a più fattori e alcuni suggerimenti e trucchi per il recupero, l’uso automatico e altro.

Tip 1 – Recuperare l’accesso

Come per ogni sistema che si indurisce e protegge, si diventa responsabili della gestione della sicurezza. In questo caso, ciò significa non perdere la tua chiave SSH o la tua chiave segreta TOTP e assicurarti di avere accesso alla tua app TOTP. Tuttavia, a volte le cose accadono, e puoi perdere il controllo delle chiavi o delle app di cui hai bisogno per entrare.

Perdere una chiave SSH o una chiave segreta TOTP

Se perdi la tua chiave SSH o la chiave segreta TOTP, il recupero può essere suddiviso in un paio di passi. Il primo è rientrare senza conoscere il codice di verifica e il secondo è trovare la chiave segreta o rigenerarla per il normale login MFA.

Per entrare dopo aver perso la chiave segreta che genera il codice di verifica su un Droplet DigitalOcean, puoi semplicemente usare la console virtuale dalla tua dashboard per accedere usando il tuo nome utente e password.

Altrimenti, avrai bisogno di un utente amministrativo che abbia accesso sudo; assicurati di non abilitare MFA per questo utente, ma usa solo una chiave SSH. Se tu o un altro utente perde la sua chiave segreta e non può accedere, allora l’utente amministrativo può accedere e aiutare a recuperare o rigenerare la chiave per qualsiasi utente usando sudo.

Una volta effettuato l’accesso, ci sono due modi per aiutare ad ottenere il segreto TOTP:

1. Recuperare la chiave esistente
2. Generare una nuova chiave

Nella home directory di ogni utente, la chiave segreta e le impostazioni di Google Authenticator sono salvate in ~/.google-authenticator. La primissima riga di questo file è una chiave segreta. Un modo rapido per ottenere la chiave è quello di eseguire il seguente comando, che visualizza la prima riga del file google-authenticator (cioè la chiave segreta). Poi, prendete quella chiave segreta e digitatela manualmente in un’applicazione TOTP.

head -n 1 /home/sammy/.google_authenticator

Se c’è una ragione per non usare la chiave esistente (per esempio, non poter condividere facilmente la chiave segreta con l’utente impattato in modo sicuro o la chiave esistente è stata compromessa), potete rimuovere completamente il file ~/.google-authenticator. Questo permetterà all’utente di accedere di nuovo usando solo un singolo fattore, assumendo che non abbiate applicato l’MFA rimuovendo ‘nullok’ nel file ‘/etc/pam.d/sshd’. Possono quindi eseguire google-authenticator per generare una nuova chiave.

Perdere l’accesso all’app TOTP

Se hai bisogno di accedere al tuo server ma non hai accesso alla tua app TOTP per ottenere il tuo codice di verifica, puoi ancora accedere usando i codici di recupero che sono stati visualizzati quando hai creato la tua prima chiave segreta. Nota che questi codici di recupero sono utilizzabili una sola volta. Una volta che uno è usato per accedere, non può essere usato di nuovo come codice di verifica.

Tip 2 – Cambiare le impostazioni di autenticazione

Se vuoi cambiare le tue impostazioni MFA dopo la configurazione iniziale, invece di generare una nuova configurazione con le impostazioni aggiornate, puoi semplicemente modificare il file ~/.google-authenticator. Questo file è disposto nel seguente modo:

<secret key><options><recovery codes>

Le opzioni che sono impostate in questo file hanno una riga nella sezione opzioni; se hai risposto “no” a una particolare opzione durante la configurazione iniziale, la riga corrispondente è esclusa dal file.

Queste sono le modifiche che puoi fare a questo file:

• Per abilitare i codici sequenziali invece di quelli a tempo, cambia la linea " TOTP_AUTH in " HOTP_COUNTER 1.
• Per permettere usi multipli di un singolo codice, togli la linea " DISALLOW_REUSE.
• Per estendere la finestra di scadenza del codice a 4 minuti, aggiungi la linea " WINDOW_SIZE 17.
• Per disabilitare i login multipli falliti (rate limiting), rimuovete la linea " RATE_LIMIT 3 30.
• Per cambiare la soglia del rate limiting, trovate la linea " RATE_LIMIT 3 30 e modificate i numeri. Il 3 nell’originale indica il numero di tentativi in un periodo di tempo, e il 30 indica il periodo di tempo in secondi.
• Per disattivare l’uso dei codici di recupero, rimuovete i cinque codici a 8 cifre in fondo al file.

Tip 3 – Evitare l’MFA per alcuni account

Ci può essere una situazione in cui un singolo utente o alcuni account di servizio (cioè account usati da applicazioni, non da esseri umani) hanno bisogno di un accesso SSH senza MFA abilitato. Per esempio, alcune applicazioni che usano SSH, come alcuni client FTP, potrebbero non supportare l’MFA. Se un’applicazione non ha un modo per richiedere il codice di verifica, la richiesta potrebbe rimanere bloccata fino a quando la connessione SSH non va in time out.

Finché un paio di opzioni in /etc/pam.d/sshd sono impostate correttamente, è possibile controllare quali fattori sono usati su una base utente per utente.

Per permettere l’MFA per alcuni account e solo la chiave SSH per altri, assicurati che le seguenti impostazioni in /etc/pam.d/sshd siano attive.

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

Qui, auth substack password-auth è commentato perché le password devono essere disabilitate. L’MFA non può essere forzato se alcuni account devono avere l’MFA disabilitato, quindi lascia l’opzione nullok sulla linea finale.

Dopo aver impostato questa configurazione, esegui semplicemente google-authenticator come ogni utente che ha bisogno dell’MFA, e non eseguirlo per gli utenti dove saranno usate solo chiavi SSH.

Tip 4 – Automatizzare la configurazione con la gestione della configurazione

Molti amministratori di sistema usano strumenti di gestione della configurazione, come Puppet, Chef o Ansible, per gestire i loro sistemi. Se vuoi usare un sistema come questo per installare una chiave segreta quando viene creato l’account di un nuovo utente, c’è un metodo per farlo.

google-authenticator supporta interruttori da linea di comando per impostare tutte le opzioni in un singolo comando non interattivo. Per vedere tutte le opzioni, potete digitare google-authenticator --help. Qui sotto c’è il comando che imposterebbe tutto come descritto nel passo 1:

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

Questo risponde a tutte le domande a cui abbiamo risposto manualmente, le salva in un file, e poi emette la chiave segreta, il codice QR e i codici di recupero. (Se aggiungi il flag -q, allora non ci sarà alcun output.) Se usi questo comando in modo automatico, assicurati di catturare la chiave segreta e/o i codici di recupero e rendili disponibili all’utente.

Tip 5 – Forzare l’MFA per tutti gli utenti

Se vuoi forzare l’MFA per tutti gli utenti anche al primo login, o se preferisci non affidarti ai tuoi utenti per generare le proprie chiavi, c’è un modo semplice per gestire questo. Puoi semplicemente usare lo stesso file .google-authenticator per ogni utente, dato che non ci sono dati specifici dell’utente memorizzati nel file.

Per fare questo, dopo che il file di configurazione è stato inizialmente creato, un utente privilegiato deve copiare il file nella root di ogni directory home e cambiare i suoi permessi all’utente appropriato. Puoi anche copiare il file in /etc/skel/ in modo che venga automaticamente copiato nella home directory di un nuovo utente al momento della creazione.

Attenzione: Questo può essere un rischio per la sicurezza perché tutti stanno condividendo lo stesso secondo fattore. Questo significa che se viene trapelato, è come se ogni utente avesse un solo fattore. Tenetelo in considerazione se volete usare questo approccio.

Un altro metodo per forzare la creazione della chiave segreta di un utente è quello di usare uno script bash che:

1. Crea un token TOTP,
2. Sollecita gli utenti a scaricare l’applicazione Google Authenticator e a scansionare il codice QR che verrà visualizzato, e
3. Esegue l’applicazione google-authenticator per loro dopo aver controllato se il file .google-authenticator esiste già.

Per assicurarsi che lo script venga eseguito quando un utente accede, è possibile chiamarlo .bash_login e posizionarlo nella root della sua home directory.

Conclusione

Detto questo, avendo due fattori (una chiave SSH + un token MFA) su due canali (il tuo computer + il tuo telefono), hai reso molto difficile per un agente esterno di forzare la loro strada nella tua macchina via SSH e aumentato notevolmente la sicurezza della tua macchina.