La comunicazione SSH è protetta utilizzando la crittografia a chiave pubblica. Quando un utente si connette al server SSH utilizzando il client SSH per la prima volta, il programma SSH memorizza la chiave pubblica del server SSH nella directory home dell'utente all'interno di un file, host_noti, in una cartella nascosta denominata ~/.ssh/, come mostrato nella schermata seguente:
Ora, successivamente, ogni volta che ssh-client si connette al server, confronta la chiave pubblica inviata dal server con la chiave pubblica del server memorizzata nel file ~/.ssh/known_hosts. Se la chiave pubblica non corrisponde, il client presume che il traffico di rete sia stato dirottato o che il server a cui viene stabilita la connessione non sia lo stesso, e quindi il client SSH interrompe la connessione, come mostrato qui:
$ ssh [email protected] @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59. Please contact your system administrator. Add correct host key in /home/admin/.ssh/known_hosts to get rid of this message. Offending key in /home/admin/.ssh/known_hosts:3 RSA host key for 192.168.12.12 has changed and you have requested strict checking. Host key verification failed.$
Esistono diversi motivi per cui la chiave dell'host remoto è cambiata. Un attacco Man-in-the-Middle è solo una delle possibili ragioni. Altri possibili motivi includono:
- OpenSSH è stato reinstallato sull'host remoto ma, per qualsiasi motivo, la chiave host originale non è stata ripristinata.
- L'host remoto è stato sostituito legittimamente da un'altra macchina.
È anche possibile che il server sia stato riformattato o che la chiave del server sia stata sostituita per qualsiasi motivo legittimo. In tali circostanze, l'utente deve aggiornare i propri file ~/.ssh/known_hosts eliminando le vecchie chiavi per consentire l'accesso al server.
Se sei sicuro che questo sia innocuo, puoi utilizzare uno dei 2 metodi seguenti per ingannare openSSH e farti accedere. Ma tieni presente che sei diventato vulnerabile agli attacchi man-in-the-middle.
Metodo 1:rimuovere la chiave host dal file ~/.ssh/known_hosts
Il primo metodo consiste nel rimuovere l'host remoto dal file ~/.ssh/known_hosts. Si noti che il messaggio di avviso indica già il numero di riga nel file known_hosts che corrisponde all'host remoto di destinazione. La riga incriminata nell'esempio sopra è la riga 3 ("Chiave incriminata in /home/admin/.ssh/known_hosts:3")
Puoi utilizzare la riga seguente per rimuovere quella riga (riga 3) dal file.
$ sed -i 3d ~/.ssh/known_hosts
Nota che con il metodo sopra, ti verrà chiesto di confermare l'impronta digitale della chiave host quando esegui ssh per accedere.
Metodo 2:disabilitare StrictHostKeyChecking
Il secondo metodo utilizza due parametri openSSH:
- StrictHostKeyChecking
- File UserKnownHosts
Questo metodo inganna SSH configurandolo per utilizzare un file known_hosts vuoto e NON per chiederti di confermare la chiave di identità dell'host remoto.
$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] Warning: Permanently added '192.168.12.12' (RSA) to the list of known hosts. [email protected]'s password:
Il parametro UserKnownHostsFile consente di specificare il file di database da utilizzare per archiviare le chiavi host dell'utente (l'impostazione predefinita è ~/.ssh/known_hosts). Il file /dev/null è uno speciale file di dispositivo di sistema che elimina qualsiasi cosa e tutto ciò che è stato scritto su di esso e, quando viene utilizzato come file di input, restituisce immediatamente End Of File.
Configurando il file del dispositivo nullo come database della chiave host, SSH viene ingannato nel pensare che il client SSH non si sia mai connesso a nessun server SSH prima, e quindi non si imbatterà mai in una chiave host non corrispondente. Il parametro StrictHostKeyChecking specifica se SSH aggiungerà automaticamente nuove chiavi host al file del database delle chiavi host. Impostandolo su no, la chiave host viene aggiunta automaticamente, senza la conferma dell'utente, per tutte le prime connessioni. A causa del file di database della chiave nulla, tutte le connessioni vengono visualizzate per la prima volta per qualsiasi host del server SSH. Pertanto, la chiave host viene aggiunta automaticamente al database delle chiavi host senza alcuna conferma da parte dell'utente. La scrittura della chiave nel file /dev/null elimina la chiave e segnala l'esito positivo.
Specificando le 2 opzioni SSH precedenti sulla riga di comando, puoi ignorare il controllo della chiave host per quel particolare accesso SSH. Se si desidera ignorare il controllo della chiave host in modo permanente, è necessario specificare le stesse opzioni nel file di configurazione SSH. Puoi modificare il file di configurazione SSH globale (/etc/ssh/ssh_config) se vuoi rendere le modifiche permanenti per tutti gli utenti.
Se vuoi scegliere come target un particolare utente, modifica il file di configurazione SSH specifico dell'utente (~/.ssh/config). Le istruzioni seguenti si applicano a entrambi i file. Supponiamo di voler ignorare il controllo delle chiavi per una particolare sottorete (192.168.0.0/24).
Aggiungi le seguenti righe all'inizio del file di configurazione SSH.
Host 192.168.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null
Si noti che il file di configurazione dovrebbe avere una riga come Host * seguita da una o più coppie parametro-valore. Host *significa che corrisponderà a qualsiasi host. In sostanza, i parametri che seguono Host * sono i valori predefiniti generali. Poiché viene utilizzato il primo valore corrispondente per ogni parametro SSH, si desidera aggiungere i parametri specifici dell'host o della sottorete all'inizio del file.
Come ultima parola di cautela, a meno che tu non sappia cosa stai facendo, è probabilmente meglio ignorare il controllo delle chiavi caso per caso, piuttosto che apportare modifiche permanenti ai file di configurazione SSH.