{"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":"Rilascio 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> il rilascio OpenSSH 8.2<\/a><\/noindex>, implementazione open-source di un client e server per operare con i protocolli SSH 2.0 e SFTP. <\/p>\n

Un'importante innovazione nella versione di OpenSSH 8.2 \u00e8 stata 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 di creare token hardware a basso costo per confermare la presenza fisica dell'utente, interagendo con essi attraverso USB, Bluetooth o NFC. Questi dispositivi sono promossi come un mezzo per l'autenticazione a due fattori sui siti, sono gi\u00e0 supportati dai principali browser e sono prodotti da vari produttori, tra cui Yubico, Feitian, Thetis e Kensington.<\/p>\n

Per interagire con i dispositivi che confermano la presenza dell'utente, OpenSSH ha introdotto 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 estratte in una libreria intermedia, la quale viene caricata in modo simile alla libreria di supporto PKCS#11 e funge da interfaccia per la libreria. libfido2<\/a><\/noindex>, che fornisce strumenti per comunicare con i token tramite USB (supporta i protocolli FIDO U2F\/CTAP 1 e FIDO 2.0\/CTAP 2). La libreria intermedia libsk-libfido2, preparata dagli sviluppatori di OpenSSH attivata<\/a><\/noindex> \u00e8 parte integrante di libfido2, cos\u00ec come 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 compilare OpenSSH 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 eseguire \u00abssh-keygen -t ecdsa-sk\u00bb oppure, se le chiavi sono gi\u00e0 state create e configurate, collegarsi al server utilizzando \u00abssh\u00bb. All'avvio, ssh-keygen salver\u00e0 la coppia di chiavi generate in \u00ab~\/.ssh\/id_ecdsa_sk\u00bb e pu\u00f2 essere utilizzata come le altre chiavi. <\/p>\n

La chiave pubblica (id_ecdsa_sk.pub) deve essere copiato sul server nel file authorized_keys. Sul lato server viene verificata solo la firma digitale e 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 genera la chiave reale solo in combinazione con la sequenza segreta, conservata sul token U2F. Se la chiave id_ecdsa_sk viene compromessa dall'attaccante, per superare l'autenticazione \u00e8 necessario anche accedere al token hardware, senza il quale la chiave privata salvata nel file id_ecdsa_sk \u00e8 inutile. <\/p>\n

Inoltre, per impostazione predefinita, durante l'esecuzione di qualsiasi operazione con le chiavi (sia nella generazione che nell'autenticazione) \u00e8 richiesta una conferma fisica della presenza dell'utente, ad esempio toccando il sensore sul token, il che rende pi\u00f9 difficili gli attacchi remoti ai sistemi con un token connesso. Come ulteriore livello di protezione, all'avvio di ssh-keygen pu\u00f2 anche essere richiesto di impostare una password per accedere al file della chiave. <\/p>\n

Nella nuova versione di OpenSSH \u00e8 stata annunciata anche la prossima deprecazione degli algoritmi che utilizzano hash SHA-1, in relazione a un aumento<\/a><\/noindex> efficacia degli attacchi di collisione con un prefisso fornito (il costo per trovare una collisione \u00e8 stimato intorno ai 45.000 dollari). In una delle prossime versioni, si prevede di disattivare per impostazione predefinita la possibilit\u00e0 di utilizzare l'algoritmo di firma digitale con chiave pubblica \u00abssh-rsa\u00bb, che \u00e8 menzionato nel RFC originale per il protocollo SSH e rimane ampiamente utilizzato nella pratica (per verificare l'uso di ssh-rsa nei propri sistemi, si pu\u00f2 provare a connettersi tramite ssh con l'opzione \u00ab-oHostKeyAlgorithms=-ssh-rsa\u00bb).<\/p>\n

Per facilitare la transizione verso i nuovi algoritmi in OpenSSH, in uno dei prossimi aggiornamenti sar\u00e0 abilitata per impostazione predefinita l'impostazione UpdateHostKeys, che consentir\u00e0 di trasferire automaticamente i client a algoritmi pi\u00f9 sicuri. Tra gli algoritmi raccomandati per la migrazione ci sono rsa-sha2-256\/512 basati su RFC8332 RSA SHA-2 (supportati da OpenSSH 7.2 e utilizzati come impostazione predefinita), ssh-ed25519 (supportato da OpenSSH 6.5) e ecdsa-sha2-nistp256\/384\/521 basati su RFC5656 ECDSA (supportati da OpenSSH 5.7).<\/p>\n

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

Quando si esegue ssh-keygen, ora viene utilizzato di default 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 gestire certificati firmati in OpenSSH 8.2 su sistemi con versioni pi\u00f9 vecchie di OpenSSH (per aggirare il problema durante la 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