{"id":42941,"date":"2020-02-17T14:41:56","date_gmt":"2020-02-17T11:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f"},"modified":"2020-02-17T14:41:56","modified_gmt":"2020-02-17T11:41:56","slug":"reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"Release di OpenSSH 8.2 con supporto per token di autenticazione a due fattori FIDO\/U2F","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dopo quattro mesi di sviluppo presentato<\/a><\/noindex> rilascio OpenSSH 8.2<\/a><\/noindex>, implementazione open source di client e server per il funzionamento sui protocolli SSH 2.0 e SFTP. <\/p>\n

Il miglioramento principale in this release di OpenSSH 8.2 \u00e8 la possibilit\u00e0 di utilizzare l'autenticazione a due fattori tramite dispositivi che supportano il protocollo U2F<\/a><\/noindex>, sviluppato dall'alleanza FIDO<\/a><\/noindex>. U2F consente la creazione di token hardware economici per confermare la presenza fisica dell'utente, che interagiscono tramite USB, Bluetooth o NFC. Questi dispositivi sono promossi come mezzo per l'autenticazione a due fattori su siti web, sono gi\u00e0 supportati dai principali browser e sono prodotti da diversi produttori, tra cui Yubico, Feitian, Thetis e Kensington.<\/p>\n

Per interagire con i dispositivi che confermano la presenza dell'utente, OpenSSH ha aggiunto nuovi tipi di chiavi \u00abecdsa-sk\u00bb e \u00abed25519-sk\u00bb, che utilizzano gli algoritmi di firma digitale ECDSA e Ed25519, insieme all'hash SHA-256. Le procedure di interazione con i token sono state spostate in una libreria intermedia, caricata analogamente alla libreria per il supporto di PKCS#11 e funge da interfaccia sopra la libreria. libfido2<\/a><\/noindex>, fornendo mezzi di comunicazione con i token tramite USB (supporta i protocolli FIDO U2F\/CTAP 1 e FIDO 2.0\/CTAP 2). La libreria intermedia libsk-libfido2 \u00e8 stata preparata dagli sviluppatori di OpenSSH. \u00e8 inclusa<\/a><\/noindex> nel pacchetto principale di libfido2, come anche il driver HID<\/a><\/noindex> per OpenBSD.<\/p>\n

Per l'autenticazione e la generazione della chiave, \u00e8 necessario specificare nelle impostazioni il parametro \u00abSecurityKeyProvider\u00bb o impostare la variabile d'ambiente SSH_SK_PROVIDER, indicando il percorso alla libreria esterna libsk-libfido2.so (export SSH_SK_PROVIDER=\/path\/to\/libsk-libfido2.so). \u00c8 possibile compilarlo con il supporto integrato della libreria intermedia (\u2014with-security-key-builtin), in tal caso \u00e8 necessario impostare il parametro \u00abSecurityKeyProvider=internal\u00bb.
\nSuccessivamente, \u00e8 necessario avviare \u00abssh-keygen -t ecdsa-sk\u00bb oppure, se le chiavi sono gi\u00e0 state create e configurate, connettersi al server utilizzando \u00abssh\u00bb. Durante l'esecuzione di ssh-keygen, la coppia di chiavi generata sar\u00e0 salvata in \u00ab~\/.ssh\/id_ecdsa_sk\u00bb e potr\u00e0 essere utilizzata come qualsiasi altra chiave. <\/p>\n

La chiave pubblica (id_ecdsa_sk.pub) deve essere copiata sul server nel file authorized_keys. Lato server viene verificata solo la firma digitale, mentre l'interazione con i token avviene sul lato client (non \u00e8 necessario installare libsk-libfido2 sul server, ma il server deve supportare il tipo di chiavi \u00abecdsa-sk\u00bb). La chiave privata generata (id_ecdsa_sk) \u00e8 essenzialmente un descrittore della chiave, che forma la chiave reale solo in combinazione con la sequenza segreta, memorizzata sul token U2F. Nel caso in cui la chiave id_ecdsa_sk cada nelle mani di un attaccante, per superare l'autenticazione sar\u00e0 anche necessario avere accesso al token hardware, senza il quale la chiave privata memorizzata nel file id_ecdsa_sk \u00e8 inutile. <\/p>\n

Inoltre, per impostazione predefinita, quando si eseguono operazioni con le chiavi (sia durante la generazione che l'autenticazione) \u00e8 necessaria una conferma locale della presenza fisica dell'utente, ad esempio viene richiesto di toccare il sensore del token, il che rende pi\u00f9 difficile effettuare attacchi remoti sui sistemi con un token connesso. Come ulteriore misura di protezione, durante l'avvio di ssh-keygen \u00e8 possibile anche impostare una password per accedere al file della chiave. <\/p>\n

Nella nuova versione di OpenSSH \u00e8 stato anche annunciato il prossimo passaggio a obsolescenza degli algoritmi che utilizzano hash SHA-1, a causa di l'aumento<\/a><\/noindex> efficacia degli attacchi di collisione con prefisso specificato (il costo per trovare una collisione \u00e8 stimato in circa 45.000 dollari). In una delle prossime versioni si prevede di disabilitare di default l'uso dell'algoritmo di firma digitale a chiave pubblica \u00abssh-rsa\u00bb, menzionato nel RFC originale per il protocollo SSH e rimane ampiamente utilizzato nella pratica (per verificare l'uso di ssh-rsa nei propri sistemi, \u00e8 possibile provare a connettersi tramite ssh con l'opzione \u00ab-oHostKeyAlgorithms=-ssh-rsa\u00bb).<\/p>\n

Per facilitare la transizione verso i nuovi algoritmi, in una delle prossime versioni di OpenSSH verr\u00e0 abilitata per impostazione predefinita l'impostazione UpdateHostKeys, che consentir\u00e0 la migrazione automatica dei client verso algoritmi pi\u00f9 sicuri. Tra gli algoritmi raccomandati per la migrazione sono stati menzionati rsa-sha2-256\/512 basati su RFC8332 RSA SHA-2 (supportato da OpenSSH 7.2 e utilizzato per impostazione predefinita), ssh-ed25519 (supportato da OpenSSH 6.5) e ecdsa-sha2-nistp256\/384\/521 basati su RFC5656 ECDSA (supportato da OpenSSH 5.7).<\/p>\n

Nella versione 8.2 di OpenSSH, la possibilit\u00e0 di connessione utilizzando \u00abssh-rsa\u00bb \u00e8 ancora presente, ma questo algoritmo \u00e8 stato rimosso dall'elenco CASignatureAlgorithms, che definisce gli algoritmi consentiti per la firma digitale dei nuovi certificati. Analogamente, \u00e8 stato rimosso dai metodi di scambio di chiavi supportati per impostazione predefinita l'algoritmo diffie-hellman-group14-sha1. Si osserva che l'uso di SHA-1 nei certificati comporta un rischio aggiuntivo, poich\u00e9 l'attaccante ha tempo illimitato per cercare una collisione per un certificato esistente, mentre il tempo di attacco sui chiavi host \u00e8 limitato dal timeout di connessione (LoginGraceTime). <\/p>\n

Quando si esegue ssh-keygen, ora per impostazione predefinita viene utilizzato l'algoritmo rsa-sha2-512, supportato a partire da OpenSSH 7.2, il che pu\u00f2 creare problemi di compatibilit\u00e0 quando si tenta di elaborare certificati firmati in OpenSSH 8.2 su sistemi con versioni di OpenSSH pi\u00f9 vecchie (per aggirare il problema nella formazione della firma, \u00e8 possibile specificare esplicitamente \u00abssh-keygen -t ssh-rsa\u00bb o utilizzare gli algoritmi ecdsa-sha2-nistp256\/384\/521, supportati da OpenSSH 5.7).<\/p>\n

Altre modifiche:<\/p>\n