Dopo quattro mesi di sviluppo rilasciare , un'implementazione client e server aperta per lavorare tramite i protocolli SSH 2.0 e SFTP.
Un miglioramento fondamentale nel rilascio di OpenSSH 8.2 è stata la possibilità di utilizzare l'autenticazione a due fattori utilizzando dispositivi che supportano il protocollo , sviluppato dall'alleanza . U2F consente la creazione di token hardware a basso costo per verificare la presenza fisica dell'utente, interagendo con lui tramite USB, Bluetooth o NFC. Tali dispositivi vengono promossi come mezzo di autenticazione a due fattori sui 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, sono state aggiunte a OpenSSH le nuove tipologie di chiavi “ecdsa-sk” e “ed25519-sk”, che utilizzano gli algoritmi di firma digitale ECDSA ed Ed25519, combinati con l'hash SHA-256. Le procedure per interagire con i token vengono inserite in una libreria intermedia, che viene caricata in modo simile alla libreria per il supporto PKCS#11 ed è un wrapper sopra la libreria , che fornisce strumenti per la comunicazione con token tramite USB (sono supportati i protocolli FIDO U2F/CTAP 1 e FIDO 2.0/CTAP 2). Libreria intermedia libsk-libfido2 preparata dagli sviluppatori OpenSSH nel core libfido2, così come per OpenBSD.
Per autenticarsi e generare una chiave, è necessario specificare il parametro “SecurityKeyProvider” nelle impostazioni 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. COSÌ). È possibile compilare openssh con il supporto integrato per la libreria dei livelli (--with-security-key-builtin), in questo caso è necessario impostare il parametro “SecurityKeyProvider=internal”.
Successivamente è necessario eseguire “ssh-keygen -t ecdsa-sk” o, se le chiavi sono già state create e configurate, connettersi al server utilizzando “ssh”. Quando esegui ssh-keygen, la coppia di chiavi generata verrà salvata in "~/.ssh/id_ecdsa_sk" e potrà essere utilizzata in modo simile ad altre chiavi.
La chiave pubblica (id_ecdsa_sk.pub) deve essere copiata sul server nel file Authorized_keys. Lato server viene verificata solo la firma digitale e l'interazione con i token viene eseguita 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 handle di chiave, che forma una chiave reale solo in combinazione con la sequenza segreta memorizzata sul lato token U2F. Se la chiave id_ecdsa_sk cade nelle mani di un attacker, per superare l'autenticazione dovrà anche accedere al token hardware, senza il quale la chiave privata memorizzata nel file id_ecdsa_sk è inutile.
Inoltre, per impostazione predefinita, quando si eseguono operazioni con le chiavi (sia durante la generazione che durante l'autenticazione), è richiesta la conferma locale della presenza fisica dell'utente, ad esempio, si propone di toccare il sensore sul token, il che rende difficile effettuare attacchi remoti ai sistemi con un token connesso. Come ulteriore linea di difesa, è possibile specificare una password anche durante la fase di avvio di ssh-keygen per accedere al file della chiave.
La nuova versione di OpenSSH ha anche annunciato l'imminente deprecazione degli algoritmi che utilizzano hash SHA-1 a causa l'efficacia degli attacchi di collisione con un determinato prefisso (il costo per la selezione di una collisione è stimato in circa 45mila dollari). In una delle prossime versioni, si prevede di disabilitare per impostazione predefinita la possibilità di utilizzare l'algoritmo di firma digitale a chiave pubblica “ssh-rsa”, che è menzionato nell'RFC originale per il protocollo SSH e rimane diffuso nella pratica (per testare l'uso di ssh-rsa nei vostri sistemi, potete provare a connettervi via ssh con l'opzione “-oHostKeyAlgorithms=-ssh-rsa”).
Per facilitare la transizione ai nuovi algoritmi in OpenSSH, in una versione futura l'impostazione UpdateHostKeys sarà abilitata per impostazione predefinita, che migrerà automaticamente i client ad algoritmi più affidabili. Gli algoritmi consigliati per la migrazione includono rsa-sha2-256/512 basato su RFC8332 RSA SHA-2 (supportato da OpenSSH 7.2 e utilizzato per impostazione predefinita), ssh-ed25519 (supportato da OpenSSH 6.5) e basato su ecdsa-sha2-nistp256/384/521 su RFC5656 ECDSA (supportato da OpenSSH 5.7).
In OpenSSH 8.2, la possibilità di connettersi utilizzando "ssh-rsa" è ancora disponibile, ma questo algoritmo è stato rimosso dall'elenco CASignatureAlgorithms, che definisce gli algoritmi consentiti per la firma digitale di nuovi certificati. Allo stesso modo, l'algoritmo diffie-hellman-group14-sha1 è stato rimosso dagli algoritmi di scambio chiavi predefiniti supportati. Si noti che l'uso di SHA-1 nei certificati è associato a un rischio aggiuntivo, poiché l'attaccante ha un tempo illimitato per cercare una collisione per un certificato esistente, mentre il tempo di attacco alle chiavi host è limitato dal timeout della connessione (LoginGraceTime ).
L'esecuzione di ssh-keygen ora utilizza per impostazione predefinita l'algoritmo rsa-sha2-512, che è supportato da OpenSSH 7.2, il che potrebbe creare problemi di compatibilità quando si tenta di elaborare i certificati firmati in OpenSSH 8.2 su sistemi che eseguono versioni precedenti di OpenSSH (per aggirare il problema quando Quando generando una firma, puoi specificare esplicitamente "ssh-keygen -t ssh-rsa" o utilizzare gli algoritmi ecdsa-sha2-nistp256/384/521, supportati da OpenSSH 5.7).
Altre modifiche:
- Una direttiva Include è stata aggiunta a sshd_config, che consente di includere il contenuto di altri file nella posizione corrente del file di configurazione (le maschere glob possono essere utilizzate quando si specifica il nome del file);
- È stata aggiunta l'opzione “no-touch-required” a ssh-keygen, che disabilita la necessità di confermare fisicamente l'accesso al token durante la generazione della chiave;
- Una direttiva PubkeyAuthOptions è stata aggiunta a sshd_config, che combina varie opzioni relative all'autenticazione con chiave pubblica. Attualmente, è supportato solo il flag "no-touch-required" per ignorare i controlli di presenza fisica per l'autenticazione del token. Per analogia è stata aggiunta l'opzione “no-touch-required” al file aware_keys;
- Aggiunta l'opzione "-O write-attestation=/path" a ssh-keygen per consentire la scrittura di certificati di attestazione FIDO aggiuntivi durante la generazione delle chiavi. OpenSSH non utilizza ancora questi certificati, ma potranno essere utilizzati in seguito per verificare che la chiave sia collocata in un negozio hardware attendibile;
- Nelle impostazioni ssh e sshd è ora possibile impostare la modalità di prioritizzazione del traffico tramite la direttiva IPQoS (Comportamento per-hop con sforzo inferiore);
- In ssh, quando si imposta il valore “AddKeysToAgent=yes”, se la chiave non contiene un campo commento, verrà aggiunta a ssh-agent indicando il percorso della chiave come commento. IN
Anche ssh-keygen e ssh-agent ora utilizzano le etichette PKCS#11 e il nome del soggetto X.509 invece del percorso della libreria come commenti nella chiave; - Aggiunta la possibilità di esportare PEM per chiavi DSA ed ECDSA su ssh-keygen;
- Aggiunto un nuovo eseguibile, ssh-sk-helper, utilizzato per isolare la libreria di accesso ai token FIDO/U2F;
- Aggiunta l'opzione di build "--with-zlib" a ssh e sshd per la compilazione con il supporto della libreria zlib;
- In conformità con il requisito della RFC4253, nel banner visualizzato durante la connessione viene fornito un avviso relativo al blocco dell'accesso dovuto al superamento dei limiti di MaxStartups. Per semplificare la diagnostica, l'intestazione del processo sshd, visibile quando si utilizza l'utilità ps, ora mostra il numero di connessioni attualmente autenticate e lo stato del limite MaxStartups;
- In ssh e ssh-agent, quando si richiama un programma per visualizzare un invito sullo schermo, specificato tramite $SSH_ASKPASS, ora viene inoltre trasmesso un flag con il tipo di invito: “confirm” - finestra di dialogo di conferma (sì/no), “none " - messaggio informativo, "vuoto" - richiesta password;
- Aggiunta una nuova operazione di firma digitale "find-principals" a ssh-keygen per cercare nel file dei firmatari consentiti l'utente associato a una firma digitale specificata;
- Supporto migliorato per l'isolamento del processo sshd su Linux utilizzando il meccanismo seccomp: disabilitando le chiamate di sistema IPC, consentendo clock_gettime64(), clock_nanosleep_time64 e clock_nanosleep().
Fonte: opennet.ru