Dopo quattro mesi di sviluppo il rilascio , implementazione open-source di un client e server per operare con i protocolli SSH 2.0 e SFTP.
Un'importante innovazione nella versione di OpenSSH 8.2 è stata la possibilità di utilizzare l'autenticazione a due fattori tramite dispositivi che supportano il protocollo , sviluppato dall'alleanza . 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à supportati dai principali browser e sono prodotti da vari 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» ed «ed25519-sk», che utilizzano algoritmi di firma digitale ECDSA e Ed25519, in combinazione con l'hash SHA-256. Le procedure di interazione con i token sono state trasferite in una libreria intermedia, che viene caricata in modo simile alla libreria di supporto PKCS#11 e funge da interfaccia per la libreria , 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 è parte integrante di libfido2, così come per OpenBSD.
Per l'autenticazione e la generazione della chiave è necessario specificare nelle impostazioni il parametro «SecurityKeyProvider» o impostare la variabile d'ambiente SSH_SK_PROVIDER, indicando il percorso della 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 deve essere impostato il parametro «SecurityKeyProvider=internal».
Dopo, bisogna eseguire «ssh-keygen -t ecdsa-sk» o, se le chiavi sono già state create e configurate, collegarsi al server tramite «ssh». Quando si esegue ssh-keygen, la coppia di chiavi creata verrà salvata in «~/.ssh/id_ecdsa_sk» e potrà essere utilizzata come le altre chiavi.
La chiave pubblica (id_ecdsa_sk.pub) deve essere copiata sul server nel file authorized_keys. Sul lato del server viene solo verificata 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 il tipo di chiave "ecdsa-sk"). La chiave privata generata (id_ecdsa_sk) è essenzialmente un descrittore della chiave, che forma la chiave reale solo in combinazione con la sequenza segreta memorizzata sul token U2F. Se la chiave id_ecdsa_sk cade nelle mani di un attaccante, per superare l'autenticazione sarà comunque necessario ottenere l'accesso al token hardware, senza il quale la chiave privata memorizzata nel file id_ecdsa_sk è inutile.
Inoltre, per impostazione predefinita, durante l'esecuzione di qualsiasi operazione con le chiavi (sia nella generazione che nell'autenticazione) è richiesta una conferma fisica della presenza dell'utente, ad esempio toccando il sensore sul token, il che rende più difficili gli attacchi remoti ai sistemi con un token connesso. Come ulteriore livello di protezione, all'avvio di ssh-keygen può anche essere richiesto di impostare una password per accedere al file della chiave.
Nella nuova versione di OpenSSH è stata annunciata anche la prossima deprecazione degli algoritmi che utilizzano hash SHA-1, in relazione a dell'efficacia degli attacchi di collisione con un prefisso specificato (il costo per trovare una collisione è stimato intorno ai 45.000 dollari). In uno dei prossimi aggiornamenti, si prevede di disabilitare per impostazione predefinita l'uso dell'algoritmo di firma digitale a chiave pubblica «ssh-rsa», menzionato nell'RFC originale per il protocollo SSH e ancora ampiamente utilizzato nella pratica (per verificare l'uso di ssh-rsa nei propri sistemi, si può provare a connettersi via ssh con l'opzione «-oHostKeyAlgorithms=-ssh-rsa»).
Per facilitare la transizione verso i nuovi algoritmi in OpenSSH, in uno dei prossimi aggiornamenti sarà abilitata per impostazione predefinita l'impostazione UpdateHostKeys, che consentirà di trasferire automaticamente i client a algoritmi più 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).
Nella versione OpenSSH 8.2, l'opzione di connessione utilizzando "ssh-rsa" è ancora disponibile, ma questo algoritmo è stato rimosso dall'elenco dei CASignatureAlgorithms, che definisce gli algoritmi consentiti per le firme digitali nei nuovi certificati. Analogamente, l'algoritmo diffie-hellman-group14-sha1 è stato rimosso dagli algoritmi di scambio chiavi supportati di default. Si segnala che l'uso di SHA-1 nei certificati comporta un rischio aggiuntivo, poiché un attaccante ha tempo illimitato per cercare una collisione per un certificato esistente, mentre il tempo di attacco sulle chiavi host è limitato dal timeout di connessione (LoginGraceTime).
Quando viene eseguito ssh-keygen, viene ora utilizzato per impostazione predefinita l'algoritmo rsa-sha2-512, supportato a partire da OpenSSH 7.2, il che potrebbe creare problemi di compatibilità durante la gestione dei certificati firmati in OpenSSH 8.2 su sistemi con versioni più vecchie di OpenSSH (per aggirare il problema durante la formazione della firma, è possibile specificare esplicitamente «ssh-keygen -t ssh-rsa» oppure utilizzare gli algoritmi ecdsa-sha2-nistp256/384/521, supportati a partire da OpenSSH 5.7).
Altre modifiche:
- Nel file sshd_config è stata aggiunta la direttiva Include, che consente di includere il contenuto di altri file nella posizione attuale del file di configurazione (è consentito l'uso di maschere glob per specificare il nome del file);
- In ssh-keygen è stata aggiunta l'opzione «no-touch-required», che disabilita la necessità di conferma fisica dell'accesso al token durante la generazione della chiave;
- Nel file sshd_config è stata aggiunta la direttiva PubkeyAuthOptions, che unisce diverse opzioni relative all'autenticazione tramite chiave pubblica. Attualmente è supportata solo l'opzione «no-touch-required» per saltare il controllo della presenza fisica durante l'autenticazione tramite token. Analogamente, nel file authorized_keys è stata aggiunta l'opzione «no-touch-required»;
- In ssh-keygen è stata aggiunta l'opzione «-O write-attestation=/path», che consente di registrare certificati di attestazione FIDO aggiuntivi durante la generazione delle chiavi. OpenSSH attualmente non utilizza questi certificati, ma potrebbero essere utilizzati in futuro per verificare la posizione della chiave in un'archiviazione hardware attendibile;
- Nelle impostazioni di ssh e sshd, tramite la direttiva IPQoS, ora è possibile impostare la modalità di priorizzazione del traffico; (Lower-Effort Per-Hop Behavior);
- In ssh, quando è impostato il valore «AddKeysToAgent=yes», se la chiave non contiene un campo di commento, verrà aggiunta all'ssh-agent specificando come commento il percorso della chiave. In
ssh-keygen e ssh-agent, anche ora vengono utilizzate come commenti nella chiave le etichette PKCS#11 e il nome del soggetto X.509 anziché il percorso della libreria; - In ssh-keygen è stata aggiunta la possibilità di esportare PEM per chiavi DSA ed ECDSA;
- È stato aggiunto un nuovo file eseguibile ssh-sk-helper, utilizzato per isolare la libreria di accesso ai token FIDO/U2F;
- In ssh e sshd è stata aggiunta un'opzione di compilazione «—with-zlib» per la compilazione con supporto per la libreria zlib;
- In conformità con i requisiti del RFC4253, è stata fornita una visualizzazione di avviso nel banner visualizzato durante la connessione riguardo al blocco dell'accesso a causa del superamento dei limiti di MaxStartups. Per semplificare la diagnosi, è stato implementato nell'intestazione del processo sshd, visibile utilizzando l'utility ps, il conteggio delle connessioni attualmente autenticate e lo stato del limite MaxStartups;
- In ssh e ssh-agent, quando viene chiamato il programma per visualizzare sullo schermo il prompt impostato tramite $SSH_ASKPASS, viene ora passata un'ulteriore flag con il tipo di prompt: "confirm" — dialogo di conferma (sì/no), "none" — messaggio informativo, "blank" — richiesta di password;
- In ssh-keygen è stata aggiunta una nuova operazione con le firme digitali "find-principals" per cercare nel file allowed-signers dell'utente associato alla firma digitale specificata;
- Migliorato il supporto per l'isolamento del processo sshd in Linux tramite il meccanismo seccomp: le chiamate di sistema IPC sono state vietate, mentre clock_gettime64(), clock_nanosleep_time64 e clock_nanosleep() sono state autorizzate.
Fonte: opennet.ru
