Dopo quattro mesi di sviluppo rilascio , implementazione open source di client e server per il funzionamento sui protocolli SSH 2.0 e SFTP.
Il miglioramento principale in this release di OpenSSH 8.2 è la possibilità di utilizzare l'autenticazione a due fattori tramite dispositivi che supportano il protocollo , sviluppato dall'alleanza . 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à supportati dai principali browser e sono prodotti da diversi produttori, tra cui Yubico, Feitian, Thetis e Kensington.
Per interagire con i dispositivi che confermano la presenza dell'utente, OpenSSH ha aggiunto nuovi tipi di chiavi «ecdsa-sk» e «ed25519-sk», che utilizzano 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, che viene caricata analogamente alla libreria per supportare PKCS#11 ed è un'interfaccia sopra la libreria , 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 è stata preparata dagli sviluppatori di OpenSSH. nel pacchetto principale di libfido2, come anche per OpenBSD.
Per l'autenticazione e la generazione della chiave, è necessario specificare nelle impostazioni il parametro «SecurityKeyProvider» oppure 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). È possibile compilare openssh con il supporto integrato per la libreria intermedia (—with-security-key-builtin), in questo caso è necessario impostare il parametro «SecurityKeyProvider=internal».
Successivamente, bisogna eseguire «ssh-keygen -t ecdsa-sk» oppure, se le chiavi sono già state create e configurate, connettersi al server utilizzando «ssh». Durante l'esecuzione di ssh-keygen, la coppia di chiavi creata verrà salvata in «~/.ssh/id_ecdsa_sk» e può essere utilizzata come altre chiavi.
La chiave pubblica (id_ecdsa_sk.pub) deve essere copiata sul server nel file authorized_keys. Sul lato del server viene verificata solo la firma digitale, mentre l'interazione con i token avviene sul lato client (non è necessario installare libsk-libfido2 sul server, ma il server deve supportare la tipologia di chiavi «ecdsa-sk»). La chiave privata generata (id_ecdsa_sk) è sostanzialmente un descrittore della chiave, che forma la chiave reale solo in combinazione con una sequenza segreta memorizzata sul token U2F. Nel caso in cui la chiave id_ecdsa_sk cada nelle mani di un attaccante, per completare l'autenticazione sarà necessario anche accedere al token hardware, senza il quale la chiave privata memorizzata nel file id_ecdsa_sk risulta inutile.
Inoltre, per impostazione predefinita, quando si eseguono operazioni con le chiavi (sia durante la generazione che l'autenticazione) è necessaria una conferma locale della presenza fisica dell'utente, ad esempio viene richiesto di toccare il sensore del token, il che rende più difficile effettuare attacchi remoti sui sistemi con un token connesso. Come ulteriore misura di protezione, durante l'avvio di ssh-keygen è possibile anche impostare una password per accedere al file della chiave.
Nella nuova versione di OpenSSH è stato anche annunciato il prossimo passaggio a obsolescenza degli algoritmi che utilizzano hash SHA-1, a causa di dell'efficacia degli attacchi di collisione con prefisso specificato (il costo di generare una collisione è stimato a circa 45.000 dollari). In una delle prossime versioni, si prevede di disabilitare di default la possibilità di utilizzare l'algoritmo di firma digitale con chiave pubblica «ssh-rsa», che è menzionato nell'RFC originale per il protocollo SSH e rimane ampiamente diffuso nella pratica (per verificare l'utilizzo di ssh-rsa nei propri sistemi, è possibile provare a connettersi tramite SSH con l'opzione «-oHostKeyAlgorithms=-ssh-rsa»).
Per facilitare la transizione verso i nuovi algoritmi, in una delle prossime versioni di OpenSSH verrà abilitata per impostazione predefinita l'impostazione UpdateHostKeys, che consentirà la migrazione automatica dei client verso algoritmi più 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).
Nella versione OpenSSH 8.2, la possibilità di connessione utilizzando 'ssh-rsa' è ancora presente, ma questo algoritmo è stato rimosso dall'elenco CASignatureAlgorithms, che definisce gli algoritmi consentiti per la firma digitale dei nuovi certificati. Allo stesso modo, l'algoritmo diffie-hellman-group14-sha1 è stato rimosso dagli algoritmi di scambio chiave supportati per impostazione predefinita. Si segnala che l'uso di SHA-1 nei certificati comporta un rischio aggiuntivo, poiché un attaccante ha tempo illimitato per trovare collisioni per un certificato esistente, mentre il tempo di attacco alle chiavi host è limitato dal timeout di connessione (LoginGraceTime).
Nell'esecuzione di ssh-keygen, ora viene applicato per impostazione predefinita l'algoritmo rsa-sha2-512, che è supportato a partire da OpenSSH 7.2, il che potrebbe creare problemi di compatibilità quando si tenta di elaborare certificati firmati in OpenSSH 8.2 su sistemi con versioni precedenti di OpenSSH (per aggirare il problema durante la creazione della firma, è possibile specificare esplicitamente 'ssh-keygen -t ssh-rsa' o utilizzare gli algoritmi ecdsa-sha2-nistp256/384/521, supportati da OpenSSH 5.7).
Altre modifiche:
- Nel файл sshd_config è stata aggiunta la direttiva Include, che consente di includere il contenuto di altri file nella posizione corrente del file di configurazione (è consentito l'uso di maschere glob per specificare il nome del file);
- Nel comando ssh-keygen è stata aggiunta l'opzione «no-touch-required», che disabilita la necessità di conferma fisica per l'accesso al token durante la generazione della chiave;
- Nel file sshd_config è stata aggiunta la direttiva PubkeyAuthOptions, che raggruppa diverse opzioni relative all'autenticazione tramite chiavi pubbliche. Attualmente, è supportato solo il flag «no-touch-required» per bypassare la verifica della presenza fisica durante l'autenticazione con un token. Analogamente, nel file authorized_keys è stata aggiunta l'opzione «no-touch-required»;
- Nel comando ssh-keygen è stata aggiunta l'opzione «-O write-attestation=/path», che consente di registrare ulteriori certificati di attestazione FIDO durante la generazione delle chiavi. OpenSSH non utilizza attualmente questi certificati, ma potrebbero essere utilizzati in futuro per verificare il posizionamento della chiave in un archivio hardware affidabile;
- Nelle impostazioni di ssh e sshd, tramite la direttiva IPQoS, ora è possibile impostare la modalità di priorità per il traffico (Lower-Effort Per-Hop Behavior);
- In ssh, when setting the value "AddKeysToAgent=yes", if the key lacks a comment field, it will be added to the ssh-agent with the key path as the comment.
ssh-keygen and ssh-agent now also use PKCS#11 labels and the X.509 subject name as comments for the key, instead of the library path. - The ability to export PEM for DSA and ECDSA keys has been added to ssh-keygen.
- A new executable file, ssh-sk-helper, has been introduced to isolate the FIDO/U2F token access library.
- The "—with-zlib" build option has been added to ssh and sshd for compiling with support for the zlib library.
- In accordance with RFC4253, the connection banner now displays a warning about access being blocked due to exceeding the MaxStartups limits. For easier diagnosis, the sshd process header, visible when using the ps utility, shows the number of currently authenticated connections and the status of the MaxStartups limit.
- In ssh and ssh-agent, when calling a program for displaying a prompt defined by $SSH_ASKPASS, an additional flag indicating the prompt type is now passed: 'confirm' — a confirmation dialog (yes/no), 'none' — an informational message, 'blank' — a password request;
- A new operation for digital signatures 'find-principals' has been added in ssh-keygen to search the allowed-signers file for the user associated with the specified digital signature;
- Improved support for isolating the sshd process in Linux using the seccomp mechanism: IPC system calls are restricted; clock_gettime64(), clock_nanosleep_time64, and clock_nanosleep() are allowed.
Fonte: opennet.ru
