2FA per SSH su Linux con pam_radius: approvazione sul telefono per SSH e sudo

Lo stesso Notakey auth-proxy che già protegge la vostra VPN e la vostra connessione di amministrazione MikroTik può proteggere anche gli accessi a Linux. Lo stack PAM di Linux include un modulo RADIUS standard: puntatelo verso il proxy e SSH, sudo e su richiederanno tutti un’approvazione sul telefono oltre alla password.

sshd / sudo ──PAM──▶ pam_radius ──RADIUS──▶ Notakey auth-proxy ──▶ your RADIUS server
                                                    │
                                                    └──▶ push ──▶ user's phone

Questa guida è pensata per Debian/Ubuntu (libpam-radius-auth); sulle distribuzioni della famiglia RHEL il modulo è distribuito come pam_radius (EPEL) e i file PAM risiedono nella stessa struttura /etc/pam.d/.

Prerequisiti

Un auth-proxy funzionante davanti a un server RADIUS, configurato esattamente come ai passaggi 1-3 della guida VPN.
Lo stesso nome utente nel server RADIUS di destinazione, nel servizio Notakey (con un telefono registrato) e come account sulla macchina Linux. PAM si limita ad autenticare: l’utente ha comunque bisogno di un account locale (o di directory) con cui accedere.
La macchina Linux in grado di raggiungere il proxy sulla porta UDP 1812. Tra loro la password viaggia come PAP, quindi mantenete il tutto su una rete di gestione, oppure eseguite il proxy dockerizzato sull’host stesso.

Passaggio 0 – Predisponete prima la via di fuga d’emergenza

Prima di toccare PAM, assicuratevi che un accesso puramente locale funzioni: assegnate a root (o a un amministratore break-glass dedicato) una password locale robusta e verificatela dalla console. La configurazione che segue ricade sempre sulle password locali, quindi questo account è la vostra via d’ingresso se il proxy, il server RADIUS o la rete dovessero non funzionare. Fatelo per primo, non dopo che qualcosa si è rotto.

Passaggio 1 – Installate il modulo

sudo apt-get install libpam-radius-auth

Passaggio 2 – Puntatelo verso il proxy

Modificate /etc/pam_radius_auth.conf e aggiungete una riga: l’indirizzo del proxy, il segreto condiviso (che si abbina al vpn_secret_in del proxy) e il timeout in secondi:

# server[:port]    shared_secret            timeout (s)
10.0.1.20          secret_to_radius_server  60

Poi restringete i permessi del file, perché contiene il segreto:

sudo chmod 0600 /etc/pam_radius_auth.conf

Il timeout è la stessa trappola che ricorre ovunque in questa serie. Il valore predefinito del modulo è 3 secondi: sufficiente per una verifica di password, inutile per un’approvazione umana. Impostatelo almeno pari al vpn_message_ttl del proxy (30 s); 60 lascia un margine comodo.

Passaggio 3 – Attivatelo in PAM

Per ogni punto di ingresso da proteggere, aggiungete una riga subito sopra la riga @include common-auth. Per SSH:

sudo nano /etc/pam.d/sshd

auth sufficient pam_radius_auth.so
@include common-auth

sufficient significa: se RADIUS risponde con Access-Accept (password verificata a destinazione e push approvata), l’accesso riesce immediatamente. In caso contrario, PAM prosegue con la normale verifica della password locale sottostante.

Aggiungete la stessa riga a uno qualsiasi di questi, secondo necessità:

/etc/pam.d/login: accessi da console
/etc/pam.d/sudo: ogni sudo interpella il telefono (robusto, ma frequente: la cache delle credenziali di sudo lo rende tollerabile)
/etc/pam.d/su: cambio utente

Infine, modificate /etc/pam.d/common-auth e aggiungete try_first_pass alla riga pam_unix.so esistente:

auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass

(Le altre opzioni su quella riga variano a seconda della release: l’unica aggiunta è try_first_pass.) Senza di essa, un utente che ricade sull’autenticazione locale si vede chiedere la password una seconda volta; con essa, la password già digitata viene riutilizzata in modo silenzioso.

Passaggio 4 – Verificate che sshd usi davvero PAM

In /etc/ssh/sshd_config, l’autenticazione basata su PAM richiede:

UsePAM yes
KbdInteractiveAuthentication yes

(entrambi sono i valori predefiniti su Debian/Ubuntu). Un aspetto da conoscere: gli accessi SSH con chiave pubblica saltano del tutto la fase di autenticazione di PAM, quindi un accesso basato su chiave non attiverà alcuna push. Se volete chiave più push, impostate AuthenticationMethods publickey,keyboard-interactive, ma collaudate questa variante separatamente prima di distribuirla.

Passaggio 5 – Create utenti solo-push

Ecco il trucco che rende pulita la configurazione: create utenti senza password locale.

sudo useradd -m -G sudo john

Nessun passwd successivo: la password locale dell’account resta bloccata. Quell’utente ha ora un’unica via d’accesso: RADIUS attraverso il proxy, cioè password e approvazione sul telefono. Non c’è nulla di locale da attaccare con forza bruta. Il vostro amministratore break-glass del passaggio 0 resta l’unico account con una password puramente locale.

Collaudatelo, con attenzione

Tenete aperta la vostra sessione di lavoro e connettetevi via SSH da un secondo terminale con un nome utente RADIUS:

Il prompt della password si comporta come al solito; dopo averla inserita, la sessione attende: è il proxy che tiene aperto lo scambio.
La push arriva sul telefono. Approvate → shell. Rifiutate o ignorate → l’accesso fallisce allo scadere del timeout.
Confermate che l’account break-glass entri ancora con la sua password locale.

Chiudete la sessione originale solo dopo che entrambe le verifiche sono riuscite.

Risoluzione dei problemi

L’accesso fallisce all’istante, nessuna push: il timeout in /etc/pam_radius_auth.conf è ancora al valore predefinito di 3 secondi, oppure il segreto non corrisponde al vpn_secret_in del proxy.
Nessuna push, ma l’attesa avviene: nome utente non corrispondente tra RADIUS e il servizio Notakey, oppure il telefono non è registrato a questa applicazione.
La password viene richiesta due volte: manca try_first_pass sulla riga pam_unix in common-auth.
Gli accessi SSH con chiave non ricevono alcuna push — è previsto: l’autenticazione a chiave pubblica aggira la fase di autenticazione di PAM (vedi passaggio 4).

Dove si colloca

Un solo proxy, un solo server RADIUS — e ora la VPN, il piano di amministrazione del router e il vostro parco Linux richiedono tutti un’approvazione sul telefono. Tutto ciò che parla RADIUS o PAM può unirsi alla stessa configurazione.

Guide correlate

2FA VPN con RADIUS — la configurazione completa dell’auth-proxy — la configurazione del proxy su cui si basa questa guida
2FA per la connessione al router MikroTik — lo stesso schema per l’accesso WinBox/SSH del router stesso