Czy można zapobiec wyświetlaniu komunikatu o: (ZMIENIONA IDENTYFIKACJA HOSTA ZDALNEGO)
Gdy używasz tylko tej składni połączenia
ssh xxx.xxx.xxx.xxx
przykład komunikatu ostrzegawczego:
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.
za każdym razem, gdy otrzymuję tę wiadomość, czyszczę /root/.ssh/known_hosts
jako
cp /dev/null /root/.ssh/known_hosts
Byłem też myśląc o ustawieniu polecenia cp / dev / null /root/.ssh/known_hosts w crontab,
więc codziennie o 24:00 czyści plik known_hosts (to rozwiązanie zmniejsza ten problem, ale go nie rozwiązuje )
więc to rozwiązanie nie jest zbyt dobrym rozwiązaniem, ponieważ użytkownik może otrzymać ostrzeżenie pomimo tego, że codziennie czyścimy plik known_hosts
może możemy coś zrobić na / etc / ssh / ssh_config, aby zapobiec sprawdzaniu klucza hosta SSH?
uwaga:
Nie chcę używać następującej metody, aby pr zdarzenie sprawdzanie klucza hosta SSH (ponieważ używam refleksji / putty)
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected]
Nalegam, aby używać tylko tej składni jako
ssh xxx.xxx.xxx.xxx
do połączenia
Komentarze
- Po prostu: don ' t zrób to. Czy w ogóle przeczytałeś to ostrzeżenie? Istnieje powód tego ostrzeżenia. Ma też chronić Cię przed atakiem MitM i innymi złymi rzeczami.
Odpowiedź
Aktualizacja: Obecnie możesz używać certyfikatów SSH , podobnych do TLS certyfikaty. Następnie możesz dodać wpis known_hosts
, aby ufać certyfikatowi , a nie poszczególnym kluczom, i już nigdy więcej nie otrzymasz tej wiadomości.
Uważaj na @ 0xC0000022L „ostrzeżenie !
Jeśli wiesz , klucz hosta się zmienił , możesz usunąć ten konkretny wpis z pliku known_hosts
:
ssh-keygen -R xxx.xxx.xxx.xxx
Jest to o wiele lepsze niż nadpisywanie całego Hosts (co można zrobić za pomocą > /root/.ssh/known_hosts
).
Jeśli nie chcesz używać ssh
opcje wiersza poleceń, myślę, że jedynym innym sposobem na to byłoby zmodyfikowanie kodu SSH i ponowna kompilacja. Co naprawdę nie chcę tego robić!
Komentarze
- ale chcę to zrobić w sposób automatyczny, kiedy użytkownik narzeka na to, nie nie chcę robić tego ręcznie
- Nie ' nie chcesz robić tego ręcznie (usunąć g
known_hosts
wpisów) i nie ' nie chcesz robić tego automatycznie (używającssh
opcje). Jak więc chcesz to zrobić? - @ l0b0 Podając opcję wiersza poleceń, aby wyłączyć tę funkcję. W niektórych środowiskach, takich jak środowiska maszyn wirtualnych i inne bardzo dynamiczne konfiguracje (zwłaszcza środowiska testowe), te klucze hostów często się zmieniają, a ponieważ znajdują się one w odizolowanej sieci, sprawdzanie ich wymaga niewielkiego bezpieczeństwa. Konieczność wykonywania
ssh-keygen -R
za każdym razem jest denerwująca. Przypuszczam, że można by napisać powłokę dla ssh, skrypt powłoki, który analizuje adres docelowy i wstępnie usuwa klucz przed przekazaniem opcji do ssh, ale wydaje się, że to przesada.
Odpowiedź
krok 1: usuń wadliwy klucz
ssh-keygen -R 192.168.1.1
krok 2: dodaj nowy klucz
ssh-keyscan 192.168.1.1 >> ~/.ssh/known_hosts
lub w zależności od sytuacji
> ~/.ssh/known_hosts ssh-keyscan 192.168.1.1 192.168.1.2 ... >> ~/.ssh/known_hosts
Komentarze
- -1 za dostarczenie broni bez ostrzeżenia.
- @ l0b0 W porządku, twój honor!
Odpowiedź
Podczas łączenia się z jednorazowymi maszynami wirtualnymi itp. lepiej nie przechowywać kluczy w pierwszej kolejności.
Utwórz ssh0
alias lub funkcja z następującą zawartością:
alias ssh0="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR"
W ten sposób nie „zanieczyszczasz swojego ~/.known_hosts
ze śmieciami, a ponieważ używasz innego polecenia, pojawi się błąd psychologiczny granica między „prawdziwym” ssh a tym używanym do instrumentowania jakiegoś lokalnego widżetu.
Innym użytecznym aliasem jest
alias sshy="ssh -o CheckHostIP=no"
, gdy „ponowne łączenie się z urządzeniem, które często zmienia swój adres IP, np. domowy router, do którego dostawca usług internetowych przydziela inny adres IP za każdym razem, gdy jest on przełączany na zasilanie.
Komentarze
- Doskonała odpowiedź!