Guida alla risoluzione dei problemi di connessione con ssh

 

2 – Incompatibilità di algoritmi crittografici tra client e server

Nel corso degli anni alcuni degli algoritmi di crittografia utilizzati da ssh sono cambiati: i più vecchi sono risultati vulnerabili e sono stati sostituiti da nuovi algoritmi più resistenti. Può capitare quindi che client e server non riescano a negoziare un algoritmo di crittografia comune e pertanto la connessione non possa essere stabilita. Se il client usato per la connessione è più recente del server, allora in molti casi è possibile forzarlo ad usare uno degli algoritmi disponibili sul server. Viceversa quando è il server ad essere molto più recente del client, non c`è altra soluzione che aggiornare il client o utilizzare un server intermedio che accetti le connessioni dal client vecchio e sia in grado di connettersi al server desiderato.

Vediamo qualche esempio.

Client recente, server vecchio

Qui si vede che il vecchio server supporta per la chiave dell’host solo gli algoritmi ssh-rsa e ssh-dss. Si può forzare il client ad usarli utilizzando l’opzione HostKeyAlgorithms:

In altri casi client e server non riescono a negoziare un metodo per scambiarsi le chiavi con cui crittografare la connessione:

Questa volta, tramite l’opzione KexAlgorithms possiamo forzare il client ad utilizzare uno degli algoritmi obsoleti supportati dal server:

Qui si vede che abbiamo risolto il problema dello scambio delle chiavi crittografiche, ma ora si presenta il problema dell’incompatibilità del tipo di chiave dell’host, già visto nel caso precedente, che sappiamo risolvere con l’opzione HostKeyAlgorithms. Quindi usando entrambe le opzioni riusciamo a connetterci:

Un altro tipico errore che si può riscontrare quando si utilizza un client recente per collegarsi ad un server vecchio è

Il motivo è che il server usa una chiave di identificazione di tipo RSA di lunghezza troppo piccola (generalmente 1024 bit invece di 2048 o superiori).

In questi casi si può usare l’opzione -o PubkeyAcceptedAlgorithms=ssh-dss per forzare il client ad usare chiavi di tipo DSS invece che RSA (sempre che il server le supporti). Oppure, solo sui client ssh di sistemi RedHat e derivati, si può usare l’opzione -o RSAMinSize=1024 per abbassare la lunghezza minima consentita della chiave ssh di tipo RSA.

Una volta trovate le opzioni necessarie per connettersi con un certo host, possiamo inserire tali opzioni nel file di configurazione ~/.ssh/config in modo da non doverle scrivere ogni volta. Nel file possiamo indicare le opzioni necessarie per ciascun host in questo modo:

Dopo la direttiva Host possono essere inseriti più nomi di host separati da spazi, o anche lo stesso host con e senza il dominio, in modo che la direttiva venga utilizzata indipendentemente da come scriviamo il nome dell’host sulla riga di comando.

Maggiori informazioni sulle opzioni disponibili da fornire al comando ssh o da inserire nel file di configurazione si possono trovare usando il comando “man ssh_config”.

Client vecchio, server nuovo

Può verificarsi anche la situazione inversa alla precedente, se utilizziamo un client datato per collegarci ad un server aggiornato con le ultime versioni di ssh:

In questo caso non abbiamo molte possibilità: il server rifiuta la connessione perché il nostro client utilizza algoritmi obsoleti. Normalmente non abbiamo modo di riconfigurare il server per consentire l’accesso anche con algoritmi vecchi e meno sicuri (cosa comunque non consigliabile). Quindi l’unico modo per risolvere il problema è aggiornare il client. Altrimenti, se ne abbiamo la possibilità, possiamo utilizzare un server intermedio che accetti la connessione dal nostro client vecchio e abbia a sua volta in dotazione un client abbastanza recente da essere accettato dal server sul quale vogliamo collegarci.