Problemi di verifica della chiave host SSH tramite VIP

Abbiamo 2 server di produzione su un VIP, solo uno è in uso alla volta, ad esempio:

myservice.mycompany.uk normalmente punta a server1, nel caso in cui server1 fallisca, si passa a server2.

Esistono altri server che devono inviare file a myservice.mycompany.uk tramite SFTP e dovrebbero essere totalmente trasparenti in caso di failover su server2.

Il problema è che mentre le chiavi sono installate sia su server1 che su server2, gli altri server avranno problemi di verifica della chiave host, poiché la chiave host di server2 è diversa dalla chiave host di server1. Ciò provoca un errore di sicurezza (poiché è attivo un controllo rigoroso) e una linea deve essere rimossa da known_hosts per farlo funzionare.

Il nostro responsabile IT ha suggerito di poter creare 2 voci in known_hosts, una con la chiave per server1 e una con server2, entrambe con l'host myservice.mycompany.uk.

È probabile che funzioni? Come si può fare con putty / psftp su Windows? Poiché la chiave host è memorizzata nel registro e non sono consentiti nomi duplicati. Esiste un modo migliore, possiamo ad esempio forzare i server ad avere la stessa chiave host?

ssh cluster sftp

— Paul Creasey
fonte

Risposte:

Per rendere più facile per i clienti, utilizzerei la stessa chiave host su entrambe le macchine. Basta copiare una delle chiavi (quella del server attualmente in uso) sulla seconda macchina. Ci sono le chiavi /etc/ssh/ssh_host_*.

Un'altra opzione è quella di disattivare il controllo della chiave host sui client. Questo può essere fatto sintonizzandoli ssh_configper usare:

Host myservice.mycompany.uk
    StrictHostKeyChecking

— ℝaphink
fonte

Disattivare il controllo della chiave host piuttosto indebolisce il punto di usare SSH per trasferire questi file, duplicare la chiave host è probabilmente la soluzione migliore.

— James Yale,

La disattivazione del controllo della chiave host non significa che la comunicazione non sia crittografata correttamente, che è il punto principale di SSH. Detto questo, come ho già detto, preferisco io stesso la prima soluzione.

— inkaphink,

Nella versione client (con diverse chiavi del server) della soluzione è necessario aggiungere UserKnownHostsFile=/dev/nullaltro, la prima chiave andrà negli host noti e la seconda genererà un avviso "man in the middle".

— Nils,

@Nils questo non è necessario; L'impostazione StrictHostKeyChecking yesrenderà il file UserKnownHosts ignorato a favore del file hosts noto del sistema. Quindi tutto ciò che modifica UserKnownHosts è piuttosto inutile.

— Michael Lowman,

Ok - Devo chiarire ulteriormente questo aspetto: parlo del caso in cui hai due chiavi server diverse. Lì devi specificare StrictHostKeyChecking noe impostare ulteriormente UserKnownHostsFilesu / dev / null. In tal caso, verranno accettate tutte le chiavi host (rendendo ovviamente inutile questo livello di sicurezza).

— Nils,

L'ho archiviato in questo modo, l'utente root esegue uno script alle 23:00 PM che si collega all'indirizzo IP logico del cluster linux, quindi in caso di failover dell'indirizzo IP la mia impronta digitale ssh cambia

echo "StrictHostKeyChecking no" >> /root/.ssh/config 
echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config

In questo modo, l'impostazione è solo per root

— c4f4t0r
fonte