Is het mogelijk om het volgende bericht te voorkomen over: (REMOTE HOST IDENTIFICATION HAS CHANGED)
Bij gebruik van alleen deze verbindingssyntaxis
ssh xxx.xxx.xxx.xxx voorbeeld van waarschuwingsbericht:
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. elke keer dat ik dit bericht ontvang, maak ik de /root/.ssh/known_hosts
schoon als
cp /dev/null /root/.ssh/known_hosts Ik was ook denkend om het commando cp / dev / null /root/.ssh/known_hosts in de crontab in te stellen,
dus elke dag om 24:00 uur maakt het het known_hosts-bestand schoon (deze oplossing vermindert dit probleem maar lost het niet op )
dus deze oplossing is niet zo goede oplossing omdat de gebruiker het waarschuwingsbericht kan krijgen ondanks dat we het bestand bekend_hosts elke dag opschonen
misschien kunnen we iets doen op / etc / ssh / ssh_config om te voorkomen dat de SSH-hostsleutel wordt gecontroleerd?
opmerking:
Ik wil de volgende methode niet gebruiken om event de SSH-hostsleutel controleren (omdat ik reflectie / stopverf gebruik)
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] Ik sta erop om alleen deze syntaxis te gebruiken als
ssh xxx.xxx.xxx.xxx voor verbinding
Reacties
- Simpel gezegd: don ' t doen. Heeft u die waarschuwing überhaupt gelezen? Er is een reden voor deze waarschuwing. En het is bedoeld om u te beschermen tegen schade door een MitM-aanval en andere slechte dingen.
Answer
Update: Tegenwoordig kunt u SSH-certificaten gebruiken, vergelijkbaar met TLS certificaten. Vervolgens kunt u een known_hosts -item toevoegen om het certificaat te vertrouwen in plaats van de individuele sleutels, en u zult dit bericht nooit meer krijgen.
Let op @ 0xC0000022L “s waarschuwing !
Als je weet de hostsleutel is gewijzigd , kunt u dat specifieke item verwijderen uit het known_hosts -bestand:
ssh-keygen -R xxx.xxx.xxx.xxx Dit is veel beter dan het volledige hosts-bestand (wat kan worden gedaan met slechts > /root/.ssh/known_hosts).
Als u ssh niet wilt gebruiken commando-regel opties, ik denk dat de enige andere manier om dit te doen zou zijn door de SSH-code te wijzigen en opnieuw te compileren. Wat je echt wil het niet doen!
Opmerkingen
- maar ik wil dit op een automatische manier doen, als de gebruiker hierover klaagt, doe ik dat niet. ik wil het niet handmatig doen
- Je ' wil het niet handmatig doen (removein g
known_hostsvermeldingen), en u ' wilt dit niet automatisch doen (metsshopties). Hoe wil je het dan doen? - @ l0b0 Door een opdrachtregeloptie te geven om de functie te onderdrukken. In sommige omgevingen, zoals virtuele machine-omgevingen en andere zeer dynamische configuraties (vooral testomgevingen), veranderen deze hostsleutels regelmatig en omdat ze zich op een geïsoleerd netwerk bevinden, is er weinig beveiliging te behalen door de controle uit te voeren. Elke keer een
ssh-keygen -Rmoeten doen is vervelend. Ik veronderstel dat je een shell voor ssh zou kunnen schrijven, een shellscript dat het bestemmingsadres parseert en de sleutel vooraf verwijdert voordat opties aan ssh worden doorgegeven, maar dit lijkt overdreven.
Answer
stap 1: verwijder defecte sleutel
ssh-keygen -R 192.168.1.1 stap 2: voeg nieuwe sleutel toe
ssh-keyscan 192.168.1.1 >> ~/.ssh/known_hosts of afhankelijk van uw situatie
> ~/.ssh/known_hosts ssh-keyscan 192.168.1.1 192.168.1.2 ... >> ~/.ssh/known_hosts Reacties
- -1 voor het verstrekken van een footgun zonder waarschuwing.
- @ l0b0 Eerlijk genoeg, edelachtbare!
Antwoord
Wanneer u verbinding maakt met virtuele machines of dergelijke, moet u de sleutels beter niet opslaan.
Maak een ssh0 alias of functie met de volgende inhoud:
alias ssh0="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR" Op deze manier “vervuil je je ~/.known_hosts bestand met garbage, en aangezien je een ander commando gebruikt, zou er een psychologisch grens tussen de “echte” SSH en degene die wordt gebruikt om een of andere lokale widget te instrumenteren.
Een andere nuttige alias is
alias sshy="ssh -o CheckHostIP=no" voor wanneer u “opnieuw verbinding maken met een apparaat waarvan het IP-adres regelmatig verandert, zoals bijv. een thuisrouter waaraan de ISP een ander IP-adres toewijst elke keer dat deze wordt uitgezet.
Opmerkingen
- Perfect antwoord hierop!