Cosa si intende per 2FA

Attivare la 2FA è sempre una buona pratica per mitigare attacchi di tipo brute-force. Perché non farlo pure per ssh, soprattutto se lo si usa nel bastion host per accedere alla nostra lan? Da letteratura, la 2FA consiste nel fornire 2 fattori di autenticazione fra:

1. qualcosa che sai (ad es. una password o un pin)
2. qualcosa che hai (ad es. un otp)
3. qualcosa che sei (ad es. un rilievo biometrico)

Se i fattori sono più di due, si parla di Multi Factor Authentication (MFA).

Non entro nel merito della configurazione di un servizio ssh , che non è banale. La diamo per scontata, ci concentriamo sulla parte di autenticazione.

Metodi di autenticazione

La buona norma vorrebbe che un'autenticazione su un server openssh si limitasse all'autenticazione con chiave pubblica. Su alcune distro ad es. è l'unica disponibile di default. Ma non basta una buona autenticazione per garantire la sicurezza di un servizio come SSH. Occorrerebbe intervenire su ben altri aspetti perché altrimenti sarebbe come preoccuparsi della bontà della porta blindata per la nostra casa dalle pareti di cartone.

I parametri del file di configurazione che andrò a trattare riguardano le modalità di autenticazione di ssh. La versione che sto usando su debian bullseye è la 8.4p1. Queste sono:

• password
• publickey
• keyboard-interactive
• gssapi-with-mic
• hostbased
• none

Le prime 3 sono quelle che ci interessano sul serio.

Con ssh posso avere:

1. una 2FA (ad es. publickey + password)
2. una MFA (ad es. publickey (qualcosa che sei) + password (qualcosa che sai) + OTP (qualcosa che hai) , se ipotizziamo publickey, in quanto certificato digitale, assimilabile al rilievo biometrico).

Per realizzare i due scenari c'è bisogno di settare con attenzione ssh per non rischiare di lasciare voragini invece che mettere in sicurezza il servizio.

Suppongo che ssh sia già settato come si deve, ciò che andrò a toccare sarà:

• UsePAM Abilita o meno l'uso di PAM
• ChallengeResponseAuthentication (KbdInteractiveAuthentication dalla 8.8) Permette di applicare lo schema Challenge-Response per l'autenticazione
• PublicKeyAuthentication Abilita o meno l'autenticazione con chiave pubblica
• PasswordAutentication Abilita o meno l'autenticazione con password
• AuthenticationMethods È la lista (l'elenco precedente) dei metodi di autenticazione che vogliamo permettere. Se gli elementi sono separati da una virgola, vuol dire che sono tutti obbligatori (per avere un'autenticazione multipla per es.). Se sono separati da uno spazio, vuol dire che sono facoltativi. Es. publickey,password password publickey,password,keyboard-interactive. Vuol dire che mi posso autenticare fornendo chiave e password oppure password oppure chiave+password+otp È abbastanza chiaro che una configurazione del genere può essere molto pericolosa perché il suo livello di robustezza dipende dal suo anello più debole (la password in questo caso) che può vanificare tutti gli altri.

Ogni modifica del file di configurazione richiederà il restart del servizio ssh.

systemctl restart sshd.service

PAM

Com'è noto, e banalizzando molto, PAM è un sottosistema gnu/linux che fornisce un livello di astrazione a quelle applicazioni, come ssh, che richiedono autenticazione. In questo modo le applicazioni non hanno bisogno di implementarle esplicitamente e, volendo, possono estendere i propri schemi di autenticazione aumentandone la complessità in maniera relativamente semplice.

PAM, insieme ad una autenticazione di tipo challenge-response, ci permetterà di ottenere un'autenticazione multipla.

Scenario 1: Configurazione sicura (chiave pubblica)

In molti contesti si preferisce abilitare la sola autenticazione con chiave pubblica, proprio per evitare possibili falle. Niente PAM in questo caso ma solo configurazione ssh:

...
UsePAM=no
ChallengeResponseAuthentication=no
PublicKeyAuthentication=yes
PasswordAuthentication=no
AuthenticationMethods=publickey
...

PAM viene disabilitato perché scegliamo di non affidarci a librerie di autenticazione esterne. Inoltre, in casi estremi, si può pensare che un aggiornamento di PAM possa rompere la compatibilità con qualche libreria invalidando o indebolendo il processo di autenticazione.

Di conseguenza, niente autenticazione di tipo challenge-response, niente autenticazione con password.

Attiviamo solo la PublicKeyAuthentication rafforzando la scelta in AuthenticationMethods dove impostiamo come unico metodo valido publickey. Infine, riavviamo il servizio.

L'unico modo per accedere al server ssh è possedere una chiave (o un certificato) valida.

Scenario 2: 2FA (chiave pubblica + password)

Facciamo un passo in più è facciamo in modo che l'accesso al server sia consentito solo a chi possiede sia chiave che password.

...
UsePAM=no
ChallengeResponseAuthentication=no
PublicKeyAuthentication=yes
PasswordAuthentication=yes
AuthenticationMethods=publickey,password
...

Oltre che specificare il tipo di autenticazione (PublickeyAutentication e PasswordAuthentication), imponiamo che il metodo sia quello di esibire entrambe le credenziali.

Non impostando AutenticationMethods, varrebbe il default che prevede uno fra password, publickey o keyboard-interactive.

L'ultimo sarebbe comunque inutile in questo caso, visto che pam e challenge-response sono disabilitati. Ma non avremmo ottenuto ciò che ci eravamo prefissati.

Una configurazione analoga è la seguente:

...
UsePAM=yes
ChallengeResponseAuthentication=yes
PublicKeyAuthentication=yes
PasswordAuthentication=no
AuthenticationMethods=publickey,keyboard-interactive
...

Riavviamo ssh e la nuova autenticazione sarà disponibile come al solito.

È un esempio di come posso usare PAM per rimpiazzare la PasswordAuthentication nativa. Con una combinazione di PAM e autenticazione challenge-response, attraverso il metodo esplicito keyboard-interactive, l'applicazione autenticherà con un'unica sfida che è la richiesta di password.

Con PAM posso aggiungere altro, ad es. l'otp, come vedremo nel 3° scenario.

Scenario 3: MFA (chiave pubblica + password + otp)

Lasciamo inalterata la configurazione ssh dello scenario 2, quella che fa uso di pam. Bisogna innanzittutto installare il plugin per l'otp.

Sistemi debian-based:

apt install libpam-google-authenticator

Sistemi rpm-based:

dnf install google-authenticator

Per completezza, giusto perché lo uso, MacOS (via brew):

brew install google-authenticator-libpam

Dopo l'installazione, il generatore otp va inizializzato lanciando l'eseguibile che porrà una serie di domande:

• generare i token su base temporale: Y/N (consigliato Y)
• creare un file di configurazione nella home dell'utente: Y/N (consigliato Y)
• disabilitare la possibilità che un token possa essere usato più volte: Y/N (consigliato Y)
• (semplificando) aumentare la finestra temporale di generazione dei token (default 30s): Y/N (consigliato N, a meno che la connessione fra client e server non sia ESTREMAMENTE lenta)
• abilitare il rate-limit per scoraggiare attacchi di brute-force: Y/N (consigliato Y)

A seguire, verrà mostrato sia il qr-code (per il caricamento automatico della chiave su un authenticator come FreeOtp+) che la chiave privata (se si vuole procedere con la configurazione manuale dell'authenticator o dello script visto tempo fa), necessari per la fornitura del primo codice che inizializza il processo.

Infine configuriamo PAM per sshd. In /etc/pam.d/sshd dobbiamo imporre che il processo di autorizzazione includa obbligatoriamente l'otp. Lo faremo aggiungendo una riga contenente il riferimento alla libreria che lo implementa:

auth required pam_google_authenticator.so

Il solito riavvio di ssh (alcuni consigliano anche di fare il reboot della macchina per inizializzare correttamente il generatore di otp ma non ho trovato una giustificazione convincente del perché) completa il lavoro.

Per autenticarsi sul server ssh ora serviranno:

• chiave pubblica
• password
• otp

Scenario 3bis: 2FA (chiave pubblica + otp)

Se invece volessi avere una 2FA come nello scenario 2, ma con otp invece che con password, posso procedere così. Si lascia inalterata la configurazione ssh e si commenta una riga dalla configurazione di PAM:

Su /etc/pam.d/sshd commentare la seguente riga così:

...
#@include common-auth
...

In questo modo, si elimina la richiesta della password utente dalle “sfide” della challenge-response e rimane la sola richiesta otp.

Tips

Attenzione quando si gioca con i metodi di autenticazione ssh. Ci sono buone possibilità che vi autoescludiate dal vostro server. Basta avere keyboard-interactive (che implica un'autenticazione di tipo challenge-response) fra i metodi di autenticazione obbligatori e pam disattivato. Ecco un esempio:

...
usePAM no 
ChallengeResponseAuthentication yes
PasswordAuthentication no
PubkeyAuthentication no
AuthenticationMethods keyboard-interactive
...

Oppure, ancora più subdolo, lo scenario 3 con pam disabilitato, ossia: configurazione ssh

...
usePAM no 
ChallengeResponseAuthentication yes
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
...

In questi casi, l'autenticazione fallirà con questo errore: “Permission denied (keyboard-interactive)” perché non sarà disponibile nessuna interazione da tastiera (es. una password) e noi rimarremmo chiusi irrimediabilmente fuori dal nostro server.

#ssh #otp

Per buona parte del mio tempo sul pc apro una shell, per cui trovo comodo spostare il meno possibile le mani dalla tastiera. Usando spesso 2FA, ho pensato ad un modo per avere un OTP usando bash. Il tool che fa al caso mio è oathtool che, per i miei scopi, è sufficiente invocare in questo modo:

oathtool --totp -b <key>

dove <key> è una stringa base32 bella lunga.

Chiaramente non voglio doverla scrivere ogni volta, nè voglio lasciarla in chiaro. Occorre che:

1. la chiave sia cifrata e decifrata solamente quando occorre;
2. l'output non arrivi su stdout per non doverlo copiare a mia volta (e lasciarlo comunque visibile)

Al punto 1. si risponde con gpg o openssl.

Al punto 2. si risponde con xsel (Gnu/Linux) o pbcopy (MacOS) che trasferiscono l'output di un comando nella clipboard.

oathtool --totp -b <<< $(gpg -q --decrypt --pinentry-mode loopback <file_chiave_cifrato>) | xsel -bi

E veniamo quindi alla:

Versione 1

#!/bin/bash

# Path del file cifrato contentente la chiave # supponiamo sia di google
KEY_2FA_FILE="$1"

oathtool --totp -b <<< $(gpg -q --decrypt --pinentry-mode loopback "${KEY_2FA_FILE}") | xsel -bi

Non è nemmeno uno script. Potrebbe essere direttamente un alias.

VANTAGGI

• Estremamente compatto
• Si sfrutta nativamente l'autocomplete col TAB per i file da dare all'input
• L'univocità dei nomi è garantita dal file system

SVANTAGGI

• Crea un file per ogni codice e, alla lunga potrebbe generare confusione
• Necessità di creare una password di cifratura per ogni file (potenzialmente tutte diverse)

Versione 2

Mi occorre quindi un file nome-valore con separatore. Ad es. il simbolo “:”

account_1:JD88EIDIKJDKMDI3IEJDMDKJKDJKDKPA
account_2:JDNBLASPUQRIEKM89478JMFKOVJDOQKJ
account_3:OIJWGDVLOIQ94KDKSUD9KSLWOER9W3ODF
account_4:MVNMWIQPQYSKGPRIGNFG24KFG9E49RPWQ
    
    ...
    
account_n:IWPQSLNCGK49TOWODIR483IRIWOFOPIQO

Nello script, la variabile KEYS_2FA_FILE memorizza il full path del file cifrato dei codici, mentre l'account deve essere fornito in input. In caso contrario, viene restituita la lista degli account disponibili.

Se l'account è valido, il file viene decifrato e viene estratto il corrispondente codice che viene memorizzato direttamente nella clipboard.

#!/usr/bin/bash

# Path del file cifrato contentente i codici 2FA
KEYS_2FA_FILE="<path>/keys_2fa.gpg"

# Acquisisce il nome account
ACCOUNT=$1

# Decifra e carica in ram il contenuto del file cifrato
KEYS_2FA_FILE_DEC=$(gpg --decrypt  --pinentry-mode loopback  "${KEYS_2FA_FILE}" 2>/dev/null)

# Se non c'è nessun argomento, restituisce la lista degli account
if [[ -z "${ACCOUNT}" ]]; then
    while read LINE; do
        cut -d":" -f 1 <<< ${LINE}
    done <<< $(echo "${KEYS_2FA_FILE_DEC}")
    exit
else
    # Estrae l'elemento contenente l'id dato in input
    KEY=$(echo "${KEYS_2FA_FILE_DEC}" | grep ${ACCOUNT} | cut -d":" -f 2)

    # Se la chiave esiste, restituisce l'otp direttamente nella clipboard
    # altrimenti esce con errore
    if [[ -z "${KEY}" ]]; then
        echo "Account non esistente"
        exit 1
    else
        # Calcola l'otp e lo trasferisce nella clipboard con pbcopy
        oathtool --totp -b "${KEY}" | xsel -bi
        echo "Fatto."
    fi
fi

VANTAGGI

• Unico entry-point per la gestione degli account (un'unica password per la cifratura del file
• Più semplice da allocare

SVANTAGGI

• L'univocità degli account deve essere garantita dall'utente.
• Perdita della funzionalità di autocomplete in fase di inserimento dati

Provo ad esplorare anche una struttura differente, più espressiva se vogliamo. Invece di un file nome-valore, uso un json così strutturato:

Versione 3

{
  "accounts": [
    {
      "id": "account_1",
      "secret": "JD88EIDIKJDKMDI3IEJDMDKJKDJKDKPA"
    },
    {
      "id": "account_2",
      "secret": "JDNBLASPUQRIEKM89478JMFKOVJDOQKJ"
    },
    {
      "id": "account_3",
      "secret": "OIJWGDVLOIQ94KDKSUD9KSLWOER9W3ODF"
    },
    {
      "id": "account_4",
      "secret": "MVNMWIQPQYSKGPRIGNFG24KFG9E49RPWQ"
    },
    
    ...
    
    {
      "id": "account_n",
      "secret": "IWPQSLNCGK49TOWODIR483IRIWOFOPIQO"
    }
  ]
}

Un array, accounts, di oggetti nome-valore.

Lo script che fa il parsing e l'estrazione non è molto diverso dal precedente.

#!/usr/local/bin/bash

# Path del file cifrato contentente i codici 2FA
JSON_2FA_FILE=<path>/json_2fa.gpg

# Acquisisce il nome account
ACCOUNT=$1

# Carica in ram il contenuto del file json cifrato
JSON_2FA_FILE_DEC=$(gpg --decrypt  --pinentry-mode loopback  "${JSON_2FA_FILE}" 2>/dev/null)

# Se non c'è nessun argomento, restituisce la lista degli account
# - jq -c '.accounts[]' restituisce una lista contenenente tante linee per quanti sono gli elementi.
# - La lista viene data in pasto al ciclo while attraverso l'operatore <<< (here-string)
# - Da ogni linea viene estratto il valore del campo "id" sempre attraverso l'operatore <<<

if [[ -z "${ACCOUNT}" ]]; then
    while read LINE; do
        jq -r '.id' <<< ${LINE}
    done <<< $(echo "${JSON_2FA_FILE_DEC}" | jq -c '.accounts[]')
    exit
else
    # Estrae dall'array l'elemento contenente l'id dato in input
    KEY=$(jq -r --arg ID ${ACCOUNT} '.accounts[] | select(.id | contains($ID)).secret' <<< ${JSON_2FA_FILE_DEC})

    # Se la chiave esiste, restituisce l'otp direttamente nella clipboard
    # altrimenti esce con errore
    if [[ -z "${KEY}" ]]; then
        echo "Account non esistente"
        exit 1
    else
        # Calcola l'otp e lo trasferisce nella clipboard con xsel
        oathtool --totp -b "${KEY}" | xsel -bi
        echo "Fatto."
    fi
fi

#bash #otp #scripting #shell