Come modificare gli host noti quando più host condividono lo stesso nome IP e DNS?

Ssh regolarmente in un computer che è un computer OS X / Linux a doppio avvio. Le due istanze del sistema operativo non condividono la stessa chiave host, quindi possono essere viste come due host che condividono lo stesso IP e DNS. Diciamo che l'IP è 192.168.0.9e i nomi sono hostnameehostname.domainname

Per quanto ho capito, la soluzione per essere in grado di connettersi ai due host è di aggiungerli entrambi al ~/.ssh/know_hostsfile. Tuttavia, è più facile a dirsi che a farsi, perché il file è hash, e ha probabilmente diverse voci per host ( 192.168.0.9, hostname, hostname.domainname). Di conseguenza, ho il seguente avvertimento

Warning: the ECDSA host key for 'hostname' differs from the key for the IP address '192.168.0.9'

C'è un modo semplice per modificare il known_hostsfile, mantenendo gli hash. Ad esempio, come posso trovare le righe corrispondenti a un determinato hostame? Come posso generare gli hash per alcuni host conosciuti?

La soluzione ideale mi consentirebbe di connettermi perfettamente a questo computer con ssh, indipendentemente dal fatto che io lo chiami 192.168.0.9, hostnameo hostname.domainname, se non usa la sua hostkey Linux o la sua hostkey OSX. Tuttavia, desidero comunque ricevere un avviso se esiste un vero attacco intermedio, ovvero se viene utilizzata una chiave diversa da queste due.

La soluzione più semplice qui è solo usare le stesse chiavi host per Linux e OS X. Cioè, selezionare un set di /etc/ssh/ssh_host_*_key*file e copiarli sull'altro sistema operativo. Quindi la stessa chiave host verrà presentata a un client SSH indipendentemente dal sistema operativo in cui è stato avviato e il client SSH non sarà il più saggio.

Come suggerito da @Izzy in un commento sopra, ssh ti dice la linea offensiva e rimuovendo quella linea (salvandola altrove), accettando la nuova chiave e quindi copiando di nuovo la linea rimossa, ti ritrovi con due chiavi per lo stesso host e ssh accetterà entrambi.

(È inoltre possibile utilizzare ssh-keygen -H -F <hostname>per trovare le righe nel file known_hosts che corrispondono a quel nome host. L'esecuzione dopo aver copiato la riga rimossa dovrebbe elencare due voci.)

Se qualcuno sa come fare in modo che PuTTY faccia la stessa cosa, sarei molto interessato a saperlo.

Ho trovato questo che potrebbe aiutarti con ciò che vuoi ottenere.

Fonte: https://stackoverflow.com/questions/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but

Creare un file di configurazione nella directory .ssh come segue:

Host server1
  Hostname x1.example.com
  HostKeyAlias server1
  CheckHostIP no
  Port 22001
  User karl

Host server2
  Hostname x2.example.com
  HostKeyAlias server2
  CheckHostIP no
  Port 22002
  User karl

Spiegazione di seguito (da man ssh_config)

CheckHostIP

Se questo flag è impostato su "yes", ssh (1) verificherà inoltre l'indirizzo IP dell'host nel file known_hosts. Ciò consente a ssh di rilevare se una chiave host è cambiata a causa dello spoofing DNS. Se l'opzione è impostata su "no", il controllo non verrà eseguito. L'impostazione predefinita è "sì".

HostKeyAlias

Specifica un alias che deve essere utilizzato al posto del nome host reale quando si cerca o si salva la chiave host nei file del database delle chiavi host. Questa opzione è utile per il tunneling delle connessioni SSH o per più server in esecuzione su un singolo host.

Il nome utente e la linea di porta evitano di dover fornire anche quelle opzioni sulla riga di comando, quindi puoi semplicemente usare:

% ssh server1
% ssh server2

Il modo più semplice per risolvere il problema è assegnare a ciascun host un indirizzo IP proprio / distinto. Con 253 indirizzi disponibili nella tua rete (privata) e IPv4, questo non dovrebbe essere un grosso problema. Assegna loro IP fissi (poiché un server DHCP identificherebbe la macchina in base all'indirizzo MAC delle schede di rete ed entrambi otterrebbero lo stesso indirizzo). Non vedo nessun'altra soluzione se vuoi mantenere le misure di sicurezza (che non abbandonerei nemmeno per quel piccolo "conforto").

Non ho riscontrato questo problema quando mi collego a varie scatole VPS che condividono lo stesso IP perché ognuna ha una porta SSH diversa (20022,30022, ecc.), Quindi sono registrate come host noti con chiavi diverse.

Potrebbe essere una soluzione alternativa per te?

Un altro articolo , che descrive diversi modi per gestire il problema:

Il secondo metodo utilizza due parametri openSSH:, StrictHostKeyCheckine UserKnownHostsFile. Questo metodo inganna SSH configurandolo per l'utilizzo di un file known_hosts vuoto e NON per chiedere di confermare la chiave di identità dell'host remoto.

Dato che vuoi mantenere il controllo rigoroso della chiave host, vorrei che usassero known_hostsfile diversi . Per fare ciò, imposta il tuo ~/.ssh/configfile (o il /etc/ssh/ssh_configfile se ne hai bisogno per lavorare su più account utente locali) in questo modo:

Host myserver.osx
  UserKnownHostsFile ~/.ssh/known_hosts.dual.osx
  # default is ~/.ssh/known_hosts
  Hostname $REALHOSTNAME

Host myserver.linux
  UserKnownHostsFile ~/.ssh/known_hosts.dual.linux
  Hostname $REALHOSTNAME

, sostituendo $REALHOSTNAMEcon il nome host o l'indirizzo IP effettivo, ovviamente. (Non importa quale si sceglie, purché si scelga qualcosa dopo "Nome host" che si risolva nell'indirizzo IP, ma utilizzerei il nome host preferibilmente a un indirizzo IP, solo su principi generali.)

Quindi ssh myserver.linuxe ssh myserver.osxpuò quindi avere diverse chiavi host, ma ottieni comunque il controllo. Se è Linux che funziona e digiti OS X (o viceversa), riceverai l'avvertimento (che credo sia l'effetto desiderato).

Se avessi questo problema, mi assicurerei che ci fosse qualcosa di completamente sbagliato nel known_hostsfile principale che non corrisponde a nessuno dei due, in modo che se si digita $REALHOSTNAMEinvece di myserver.osxricevere l'avviso. :-) Lo farei mettendo qualcosa di simile

<ip-address-of-github.com> $REALHOSTNAME

nel mio /etc/hosts, quindi fare un ssh $REALHOSTNAMEe accettare la nuova chiave, quindi prendere quella voce.