È possibile impedire il seguente messaggio su: (LIDENTIFICAZIONE HOST REMOTO È CAMBIATA)
Quando si utilizza solo questa sintassi di connessione
ssh xxx.xxx.xxx.xxx esempio di messaggio di avviso:
ssh 10.19.11.1 CentOS release 5.8 (Final) Kernel 2.6.18-308.el5 on an i686 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 dd:6f:32:8f:8f:8c:70:9c:95:f1:48:83:60:97:cc:ed. 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:7 RSA host key for 10.19.11.1 has changed and you have requested strict checkin. Host key verification failed. ogni volta che ricevo questi messaggi, pulisco /root/.ssh/known_hosts
come
cp /dev/null /root/.ssh/known_hosts anchio ero pensando di impostare il comando cp / dev / null /root/.ssh/known_hosts nel crontab,
quindi ogni giorno alle 24:00 pulisce il file known_hosts (questa soluzione riduce questo problema ma non lo risolve )
quindi questa soluzione non è così buona perché lutente può ricevere il messaggio di avviso nonostante puliamo il file known_hosts ogni giorno
forse possiamo fare qualcosa su / etc / ssh / ssh_config per impedire il controllo della chiave dellhost SSH?
commento:
Non voglio utilizzare il seguente metodo per pr evento il controllo della chiave dellhost SSH (perché uso reflection / putty)
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] Insisto a usare solo questa sintassi come
ssh xxx.xxx.xxx.xxx per la connessione
Commenti
- In poche parole: don ' t farlo. Hai effettivamente letto lavviso? Cè un motivo per questo avviso. Ed è per proteggerti dai danni di un attacco MitM e altre cose brutte.
Answer
Aggiornamento: Oggigiorno puoi utilizzare certificati SSH , simili a TLS certificati. Quindi puoi aggiungere una voce known_hosts per considerare attendibile il certificato anziché le singole chiavi e non riceverai mai più questo messaggio.
Rispetta lavviso di @ 0xC0000022L “!
Se sai la chiave host è cambiata , puoi rimuovere quella voce specifica dal known_hosts file:
ssh-keygen -R xxx.xxx.xxx.xxx È molto meglio che sovrascrivere lintero file hosts (che può essere eseguito semplicemente con > /root/.ssh/known_hosts).
Se non si desidera utilizzare ssh opzioni della riga di comando, credo che lunico altro modo per farlo sia modificare il codice SSH e ricompilarlo. Che realmente non voglio farlo!
Commenti
- ma voglio farlo in modo automatico, quando lutente si lamenta di questo, non lo faccio non voglio farlo manualmente
- Non ' vuoi farlo manualmente (removin g
known_hostsvoci) e non ' vuoi farlo automaticamente (utilizzandosshopzioni). Come vuoi farlo allora? - @ l0b0 Fornendo unopzione della riga di comando per sopprimere la funzione. In alcuni ambienti, come gli ambienti di macchine virtuali e altre configurazioni molto dinamiche (in particolare gli ambienti di test), queste chiavi host cambiano frequentemente e poiché si trovano su una rete isolata, cè poca sicurezza da guadagnare eseguendo il controllo. Dover fare un
ssh-keygen -Rogni volta è fastidioso. Suppongo che si possa scrivere una shell per ssh, uno script di shell che analizza lindirizzo di destinazione e pre-rimuove la chiave prima di passare le opzioni a ssh, ma questo sembra eccessivo.
Risposta
passaggio 1: rimozione della chiave difettosa
ssh-keygen -R 192.168.1.1 passaggio 2: aggiunta di una nuova chiave
ssh-keyscan 192.168.1.1 >> ~/.ssh/known_hosts o a seconda della situazione
> ~/.ssh/known_hosts ssh-keyscan 192.168.1.1 192.168.1.2 ... >> ~/.ssh/known_hosts Commenti
- -1 per aver fornito un footgun senza preavviso.
- @ l0b0 Abbastanza giusto il tuo onore!
Risposta
Quando ti connetti a macchine virtuali usa e getta o simili, è meglio non memorizzare le chiavi in primo luogo.
Crea un ssh0 alias o funzione con il seguente contenuto:
alias ssh0="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR" In questo modo, non inquinerai il tuo ~/.known_hosts con spazzatura, e poiché stai usando un comando diverso, ci sarebbe un problema psicologico confine tra il “vero” ssh e quello utilizzato per strumentare alcuni widget locali.
Un altro alias utile è
alias sshy="ssh -o CheckHostIP=no" per quando “ti stai collegando a un dispositivo che cambia frequentemente il suo IP, come ad es. un router domestico a cui lISP assegna un IP diverso ogni volta che viene spento e riacceso.
Commenti
- Risposta perfetta a questa!