Flusso di lavoro più fluido per gestire gli errori di verifica dell'host SSH?

Questo è un semplice problema che tutti noi affrontiamo e probabilmente risolviamo manualmente senza pensarci troppo.

Quando i server cambiano, vengono sottoposti a nuovo provisioning o gli indirizzi IP vengono riallocati, riceviamo di seguito il messaggio di verifica dell'host SSH. Sono interessato a semplificare il flusso di lavoro per risolvere questi errori di identificazione ssh.

Dato il seguente messaggio, in genere vi /root/.ssh/known_hosts +434rimuovo ( dd) la linea offensiva.

Ho visto sviluppatori / utenti di altre organizzazioni eliminare l' intero known_hosts file per frustrazione nel vedere questo messaggio. Anche se non vado così lontano, so che esiste un modo più elegante per gestirlo.

Suggerimenti?

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

È possibile utilizzare il ssh-keygencomando per rimuovere voci specifiche dall'host:

ssh-keygen -R las-db1

Se non hai questo comando, puoi sempre usare sed:

sed -i '/las-db1/d' /root/.ssh/known_hosts

Come utente fantoccio, il mio metodo per risolvere questo problema consiste nel fare in modo che il mio server fantoccio raccolga le mie chiavi host SSH e le pubblichi su tutti i miei sistemi che effettuano connessioni SSH.

In questo modo non devo preoccuparmi di rimuoverli. Il novantanove percento delle volte burattino ha funzionato e aggiornato le chiavi per me poiché i miei agenti sono in esecuzione ogni trenta minuti. Le eccezioni per me sono molto rare, quindi non mi dispiace una rapida modifica del sistema known_hosts se non sono disposto ad aspettare.

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

Vorrei aggiungere un suggerimento che può aiutarti in casi molto specifici in cui la sicurezza è meno preoccupante.

Ho un ambiente di laboratorio con macchine che vengono reinstallate spesso. Ogni volta che accade, vengono generate nuove chiavi host (probabilmente potrei salvare la chiave host da qualche parte e impostarla nello script post-installazione).

Poiché la sicurezza non è un problema per me in questo ambiente di laboratorio e le chiavi cambiano così spesso, nel mio file .ssh / config ho quanto segue:

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

Questo si assicura che la connessione ai miei computer non causerà mai più quell'errore e il mio client ssh si connetterà semplicemente senza controllare la chiave host.

Questo è qualcosa che dovresti fare solo se la sicurezza non ti preoccupa affatto, perché ti mette in una posizione vulnerabile per un attacco man-in-the-middle.

Secondo la nota di rilascio di openssh 5.6 , non è più necessario utilizzare le chiavi degli host:

L'autenticazione basata su host ora può utilizzare le chiavi host del certificato. Le chiavi CA devono essere specificate in un file known_hosts usando il marcatore @ cert-Authority come descritto in sshd (8).

Avvertenza : finora non ho mai sentito parlare di nessuno che utilizza questa funzione in produzione. Utilizzare a proprio rischio (ma credo che gli sviluppatori di openssh siano abbastanza paranoici da non rilasciare una tale funzione killer senza molti test e audit del codice).

Il DNS delle risorse SSHFP può essere d'aiuto a seconda di quanto il tuo client ssh ne trae vantaggio. Memorizza tutte le impronte digitali della chiave pubblica ssh con il nome host.

Implementare preventivamente DNSSEC o DNS su SSL.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org gestisce la gestione delle chiavi dell'host e dell'utente, nonché i certificati PKI. Inoltre, carica automaticamente i record DNS SSHFP quando vengono create nuove chiavi.

Il demone dei servizi di sicurezza del sistema (SSSD) può essere configurato per memorizzare nella cache e recuperare le chiavi SSH dell'host in modo che le applicazioni e i servizi debbano cercare in una sola posizione le chiavi dell'host. Poiché SSSD può utilizzare FreeIPA come uno dei suoi provider di informazioni sull'identità, FreeIPA fornisce un repository di chiavi universale e centralizzato. Gli amministratori non devono preoccuparsi di distribuire, aggiornare o verificare le chiavi SSH dell'host.

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html