Appunti su come configurare un client e un server per usare autenticazione basata su chiavi pubbliche e private usando però un token FIDO2. L'autenticazione avviene di fatto con lo stesso meccanismo della "classica" configurazione a chiave pubblica e privata, con la differenza che in questo caso la chiave privata viene generata dentro il token FIDO2 e non viene mai estratta dal medesimo. Per ulteriore misura di sicurezza il token è protetto da un PIN e per effettuare l'autenticazione occorre anche premere un pulsante sulla medesimo. In questo modo se lo perdiamo in teoria possiamo dormire sonni tranquilli, compatibilmente con la complessità del pin. L'effetto collaterale però è che se lo perdiamo siamo chiusi fuori da tutto, ergo è meglio avere anche un secondo metodo di accesso di emergenza (un altro token per esempio).

Se abbiamo un token nuovo probabilmente dovremo inizializzarlo inserendo un PIN. Come farlo dipende da marca e modello del token. Alcuni possono essere gestiti (in modo decisamente poco user friendly) con i programmi presenti in fido2-tools.

• Installiamo il pacchetto fido2-tools

apt install fido2-tools

• Vediamo quali token usb vede il sistema (funziona tutto anche da utente normale, non serve essere root). Nell'output vedremo il device associato al token, per esempio /dev/hidraw11. Il device ovviamente può cambiare a seconda di dove lo infili, che altri device usb ci sono, ecc. Se vogliamo renderlo fisso dobbiamo fare delle regole per udev, ma per inizializzare un token non è necessario.

fido2-token -L

Output di esempio: /dev/hidraw11: vendor=0x349e, product=0x0026 (TOKEN2 FIDO2 Security Key(0026))

• Possiamo voler vedere la configurazione del token, anche se non è necessario per inizializzarlo

fido2-token -I /dev/hidraw11

• Inizializziamo un token nuovo impostando il pin per la prima volta:

fido2-token -S /dev/hidraw11

• Cambiamo il pin a un token già inizializzato:

fido2-token -C /dev/hidraw11

• Elenchiamo le credenziali salvate sul token (funziona per le chiavi SSH, ma credo che esistano altri tipi di credenziali che vanno gestite in modo diverso)

fido2-token -L -r /dev/hidraw11

Thetis non fornisce un programma per la gestione del token sotto Linux, ma se avete Wine installato dovrebbe funzionare senza alcun problema il loro programma per windows. E` sufficiente inserire il token nella porta usb e lanciare il programma sotto wine, a me ha funzionato al primo colpo su Linux Mint con Wine versione 10.0. Quello che dobbiamo fare con un token nuovo è solamente impostare il PIN, poi il resto lo si fa da Linux. NOTA: probabilmente funzionano anche i tool nativi in Linux, non ho provato.

Token2 fornisce il programma per Windows che però sotto Wine non vede il token. Esiste un programma per Linux che però devi compilarti da solo, non ne avevo voglia quindi ho provato a usare i tool nativi fido2-tools in Linux Mint e ha funzionato. È stato sufficiente vedere il nome del device e inizializzare il pin per la prima volta (vedi i comandi sopra).

Per usare il token FIDO2 per autenticarci quando usiamo SSH, dobbiamo prima di tutto generare un paio di chiavi pubblica/privata usando il token stesso, in modo che la chiave privata venga generata dentro al token e tenuta dentro al token. La chiave privata non viene mai esportata dal token, quindi non può essere copiata da nessuno. Il processo non è molto diverso dalla generazione di una coppia di chiavi pubblica/privata "classiche" per ssh.

• Con il token inserito, dare questo comando:

ssh-keygen -t ed25519-sk -O resident -O application=ssh:credentialDescription -O verify-required -C "Comment"

# Per esempio: ssh-keygen -t ed25519-sk -O resident -O application=ssh:Per_cliente_Rossi -O verify-required -C "Chiave di Mario Bianchi"

• Il commento è facoltativo, e viene scritto nella chiave pubblica per permetterci di riconoscerla (ci possiamo mettere la nostra identità così poi quando qualcuno va a vedere il file authorized_keys sul server può sapere di chi è una chiave.
• La parte -O application=ssh:credentialDescription è anche essa facoltativa, ma viene utile se abbiamo più chiavi generate nello stesso token per diversi usi, per riconoscere a cosa servono.
• Nota: è importante che la stringa inizi con ssh:
• Ora inserire il PIN e premere il tasto sul token per confermare l'operazione
• Quando viene chiesta la passphrase, premere invio per lasciarla vuota. Non ci serve, abbiamo già il PIN.

Ora la generazione dovrebbe essere completa e avremo due files dentro .ssh nella nostra home, con nome ed25519-sk e ed25519-sk.pub. Notare che mentre il file pub contiene esattamente la chiave pubblica, che poi metteremo sui vari sistemi remoti a quali dobbiamo accedere, il file che normalmente conterrebbe la chiave privata contiene in realtà un riferimento all' ID della chiave che si trova dentro al nostro token FIDO2, ergo è impossibile usarlo per autenticarsi senza il token.

Ora di fatto per autenticarci dobbiamo avere con noi il token, ma ci serve anche avere i files ed25519-sk e ed25519-sk.pub. Questi files possono facilmente essere rigenerati dal token stesso, quindi se dovessimo perderli, o se volessimo usare un altro computer, potremmo senza problemi ricreare i files in questione.

• Infilare la chiavetta
• Dare il comando

ssh-keygen -K

• Inserire il PIN
• Ora avremo i files che ci servono, che andranno messi dentro a .ssh nella nostra home, ovviamente facendo eventualmente attenzione a non sovrascrivere files pre-esistenti che per caso hanno lo stesso nome.

C'è un bug in alcune versioni di Ubuntu e Mint per cui se vogliamo che funzioni il nostro sistema FIDO2 dobbiamo passare a ssh il parametro -o "IdentityAgent=none". Questo è scomodo perché in questo modo dobbiamo usare un comando specifico se vogliamo usare il token FIDO2 e un comando diverso (senza la stringa -o "IdentityAgent=none") se vogliamo usae una coppia di chiavi pubblica/privata "tradizionale"

ssh -o "IdentityAgent=none" user@host-remoto

• Inserire il PIN
• Premere il bottone sul token
• Fatto, dovremmo avere avuto accesso
• Nota: Purtroppo (ed è inevitabilmente parte del processo di sicurezza) dobbiamo inserire il PIN ogni volta che apriamo una nuova sessione SSH verso il remoto.

Dal punto di vista del server SSH si tratta di una normale autenticazione con chiave pubblica/privata, qundi occorre copiare il contenuto della chiave pubblica ed25519-sk.pub dentro al file .ssh/authorized_keys sul server, e questo è sufficiente a fare funzionare tutto quanto.

Se però vogliamo rendere il server compliant dobbiamo assicurarci che nessun altro metodo funzioni, in particolare che non funzionino le password, quindi possiamo configurarlo modificando sshd_config in questo modo:

PubkeyAuthOptions verify-required
PermitRootLogin prohibit-password

Se vogliamo che NESSUNO (e non solo root) possa usare le password, allora dobbiamo mettere anche queste righe:

PasswordAuthentication no
PermitEmptyPasswords no

Notare un paio di cose importanti:

• In locale (console) del nostro server le password funzionano ancora senza problemi. Se volessimo forzare l'uso dei token FIDO2 anche in locale sarebbe tutto un altro percorso da fare, non in SSH ma collegando il token via USB direttamente al nostro server e configurando tutto quanto in PAM.
• Se nel file .ssh/authorized_keys inseriamo una chiave pubblica "classica", cioè non associata a un token FIDO2, questa funzionerà benissimo comunque. In altri termini sul server non vi è distinzione fra una chiave che usa FIDO2 e una chiave che non lo usa.