Oto moja sytuacja: konfiguruję wiązkę testową, która od klienta centralnego uruchamia wiele instancji maszyn wirtualnych, a następnie wykonuje na nich polecenia ssh
. Maszyny wirtualne będą miały wcześniej nieużywane nazwy hostów i adresy IP, więc nie będą one znajdować się w ~/.ssh/known_hosts
pliku na kliencie centralnym.
Problem, który mam, polega na tym, że pierwsze ssh
polecenie uruchomione przeciwko nowej instancji wirtualnej zawsze pojawia się z interaktywnym monitem:
The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?
Czy istnieje sposób na obejście tego i sprawienie, by nowy host był już znany maszynie klienckiej, może za pomocą klucza publicznego, który jest już zapisany w obrazie maszyny wirtualnej? Naprawdę chciałbym uniknąć konieczności korzystania z funkcji Oczekiwanie lub czegokolwiek, aby odpowiedzieć na interaktywny monit, jeśli mogę.
źródło
Odpowiedzi:
Ustaw
StrictHostKeyChecking
opcję nano
albo w pliku konfiguracyjnym, albo poprzez-o
:ssh -o StrictHostKeyChecking=no [email protected]
źródło
Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts.
Aby uniknąć ostrzeżenia i aby uniknąć dodawania wpisu do dowolnego pliku znanego_hosta, robię:ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null [email protected]
IMO, najlepszym sposobem na to jest:
To sprawi, że nie będzie żadnych zduplikowanych wpisów, że jesteś objęty zarówno nazwą hosta, jak i adresem IP, a także haszuje dane wyjściowe, dodatkowy środek bezpieczeństwa.
źródło
ssh-keyscan
nami nie powiodły się, ponieważ mój docelowy host nie obsługuje domyślnego typu klucza wersji 1. Dodanie-t rsa,dsa
do polecenia naprawiło to.ssh-keygen -F [address]
zamiast tego status zwrotu . medium.com/@wblankenship/…Dla leniwych:
-H haszy nazwę hosta / adres IP
źródło
Jak wspomniano, użycie skanu klucza byłoby właściwym i dyskretnym sposobem na zrobienie tego.
Powyższe załatwi sprawę, aby dodać hosta, TYLKO jeśli nie został jeszcze dodany. Nie jest również bezpieczny dla współbieżności; nie wolno wykonywać fragmentu kodu na tym samym komputerze źródłowym więcej niż raz w tym samym czasie, ponieważ plik tmp_hosts może zostać zablokowany, co ostatecznie prowadzi do wzdęcia pliku znanego hosta ...
źródło
ssh-keyscan
? Powodem jest to, że wymaga to trochę czasu i dodatkowego połączenia sieciowego.cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts
, ale późniejsza zmiana go zmieniła na>>
. Używanie>>
jest błędem. Pokonuje cel wyjątkowości w pierwszym wierszu i powoduje, że zrzuca nowe wpisy przyknown_hosts
każdym uruchomieniu. (Właśnie opublikowałem edycję, aby go zmienić.)Możesz użyć
ssh-keyscan
polecenia, aby pobrać klucz publiczny i dołączyć go doknown_hosts
pliku.źródło
Oto jak możesz włączyć ssh-keyscan do swojej gry:
źródło
byłoby to kompletne rozwiązanie, przyjmujące klucz hosta tylko po raz pierwszy
źródło
Miałem podobny problem i stwierdziłem, że niektóre z udzielonych odpowiedzi pomogły mi tylko częściowo zautomatyzować rozwiązanie. Skończyło się na tym, mam nadzieję, że to pomoże:
Dodaje klucz
known_hosts
i nie monituje o hasło.źródło
Szukałem więc przyziemnego sposobu na ominięcie ręcznej interakcji nieznanego hosta klonowania repozytorium git, jak pokazano poniżej:
Zanotuj odcisk palca klucza RSA ...
Więc to jest sprawa SSH, to zadziała dla git nad SSH i ogólnie po prostu rzeczy związane z SSH ...
Najpierw zainstaluj nmap w swoim codziennym sterowniku. nmap jest bardzo pomocny w przypadku niektórych rzeczy, takich jak wykrywanie otwartych portów, a to - ręczna weryfikacja odcisków palców SSH. Wróćmy jednak do tego, co robimy.
Dobry. Jestem narażony na kompromis w wielu miejscach i maszynach, które sprawdziłem - albo bardziej prawdopodobne jest to, że dzieje się bardziej prawdopodobne wyjaśnienie, że wszystko jest jak przystojniak.
Ten „odcisk palca” jest po prostu łańcuchem skróconym za pomocą algorytmu jednokierunkowego dla naszej ludzkiej wygody, na ryzyko, że więcej niż jeden ciąg rozdzieli się na ten sam odcisk palca. Zdarza się, że nazywane są zderzeniami.
Niezależnie od tego, wracamy do oryginalnego ciągu, który możemy zobaczyć w kontekście poniżej.
Tak więc z wyprzedzeniem możemy poprosić o formę identyfikacji od pierwotnego hosta.
W tym momencie jesteśmy ręcznie tak samo narażeni jak automatycznie - ciągi pasują do siebie, mamy podstawowe dane, które tworzą odcisk palca, i możemy poprosić o te podstawowe dane (zapobiegające kolizjom) w przyszłości.
Teraz użyj tego ciągu w sposób, który zapobiega pytaniu o autentyczność hosta ...
Plik znane_hosty w tym przypadku nie używa wpisów w postaci zwykłego tekstu. Poznasz skróty, gdy je zobaczysz, wyglądają jak skróty z losowymi znakami zamiast xyz.com lub 123.45.67.89.
Pierwszy wiersz komentarza pojawia się irytująco - ale możesz się go pozbyć za pomocą prostego przekierowania za pomocą konwencji „>” lub „>>”.
Ponieważ dołożyłem wszelkich starań, aby uzyskać nieskażone dane do identyfikacji „hosta” i zaufania, dodam tę identyfikację do mojego pliku znane_hosty w moim katalogu ~ / .ssh. Ponieważ będzie on teraz identyfikowany jako znany gospodarz, nie otrzymam wspomnianego wyżej monitu, gdy byłeś młodszy.
Dzięki za trzymanie się mnie, proszę bardzo. Dodam klucz RSA bitbucket, abym mógł tam wchodzić w interakcje z moimi repozytoriami git w sposób nieinteraktywny w ramach przepływu pracy CI, ale cokolwiek robisz, co chcesz.
W ten sposób pozostajesz dziś dziewicą. Możesz zrobić to samo z github, postępując według podobnych wskazówek we własnym czasie.
Widziałem tak wiele postów przepełnienia stosu, mówiących o programowym dodawaniu klucza na ślepo bez żadnego sprawdzania. Im bardziej sprawdzasz klucz z różnych komputerów w różnych sieciach, tym większe masz zaufanie, że host jest tym, o którym mówi, że jest - i to najlepsze, czego możesz oczekiwać od tej warstwy bezpieczeństwa.
ŹLE
ssh -oStrictHostKeyChecking = brak nazwy hosta [polecenie]ŹLE
ssh-keyscan -t rsa -H nazwa hosta >> ~ / .ssh / known_hostsProszę nie rób żadnej z powyższych rzeczy. Masz możliwość zwiększenia szansy na uniknięcie podsłuchiwania twoich transferów danych przez człowieka w środku ataku - skorzystaj z okazji. Różnicą jest dosłownie sprawdzenie, czy posiadany klucz RSA jest serwerem bona fide, a teraz wiesz, jak uzyskać te informacje, aby je porównać, abyś mógł zaufać połączeniu. Pamiętaj tylko, że więcej porównań z różnych komputerów i sieci zwykle zwiększy twoją zdolność do zaufania połączenia.
źródło
Robię skrypt jednowierszowy, nieco długi, ale przydatny, aby wykonać to zadanie dla hostów z wieloma adresami IP, używając
dig
ibash
źródło
Następujące unikają powielania wpisów w ~ / .ssh / known_hosts:
źródło
mkdir -p ~/.ssh/known_hosts;
Jak budujesz te maszyny? czy możesz uruchomić skrypt aktualizacji dns? czy możesz dołączyć do domeny IPA?
FreeIPA robi to automatycznie, ale zasadniczo wszystko, czego potrzebujesz, to rekordy dns SSHFP i DNSSEC w twojej strefie (freeipa zapewnia konfigurowalne opcje (domyślnie wyłączone dnssec)).
Możesz uzyskać istniejące rekordy SSHFP od swojego hosta, uruchamiając.
ssh-keygen -r jersey.jacobdevans.com
a następnie po opublikowaniu dodasz
VerifyHostKeyDNS yes
do swojego ssh_config lub ~ / .ssh / configJeśli / Kiedy Google zdecyduje się włączyć DNSSEC, możesz ssh wejść bez pytania o klucz hosta.
ssh jersey.jacobdevans.com
ALE moja domena nie jest jeszcze podpisana, więc na razie zobaczysz ....
źródło
Aby to zrobić poprawnie, tak naprawdę chcesz zebrać klucze publiczne hosta maszyn wirtualnych podczas ich tworzenia i upuścić w
known_hosts
formacie pliku. Następnie możesz użyć przycisku-o GlobalKnownHostsFile=...
, wskazując na ten plik, aby upewnić się, że łączysz się z hostem, z którym Twoim zdaniem powinieneś się połączyć. To, jak to zrobisz, zależy jednak od konfiguracji maszyn wirtualnych, ale odczytywanie go z wirtualnego systemu plików, jeśli to możliwe, lub nawet nakłonienie hosta do wydrukowania zawartości/etc/ssh/ssh_host_rsa_key.pub
podczas konfiguracji może załatwić sprawę.To powiedziawszy, może to nie być opłacalne, w zależności od tego, w jakim środowisku pracujesz i kim są twoi spodziewani przeciwnicy. Wykonanie prostego „przechowywania przy pierwszym połączeniu” (przez skanowanie lub po prostu podczas pierwszego „rzeczywistego” połączenia), jak opisano w kilku innych odpowiedziach powyżej, może być znacznie łatwiejsze i nadal zapewniać pewien stopień bezpieczeństwa. Jednak jeśli to zrobisz, zdecydowanie sugeruję zmianę znanego pliku hosts (
-o UserKnownHostsFile=...
) na plik specyficzny dla tej konkretnej instalacji testowej; pozwoli to uniknąć zanieczyszczenia twojego znanego pliku hosts informacjami testowymi i ułatwi wyczyszczenie niepotrzebnych teraz kluczy publicznych po usunięciu maszyn wirtualnych.źródło
To wszystko
biznes ciągle mnie denerwował, więc wybrałem
Jeden skrypt do rządzenia nimi wszystkimi
Jest to wariant skryptu ze strony https://askubuntu.com/a/949731/129227 z odpowiedzią Amadu Baha https://serverfault.com/a/858957/162693 w pętli.
przykładowe połączenie
./sshcheck somedomain site1 site2 site3
Skrypt zapętli nazwy witryn i zmodyfikuje plik .ssh / config i .ssh / known_hosts i wykona ssh-copy-id na żądanie - dla ostatniej funkcji pozwól, by wywołania testowe ssh zawiodły, np. Naciskając 3 razy prośba o hasło.
skrypt sshcheck
źródło
Oto jak zrobić zbiór hostów
zdefiniuj kolekcję hostów
Następnie zdefiniuj dwa zadania, aby dodać klucze do znanych hostów:
źródło
Najlepiej byłoby sprawdzić odcisk palca każdego nowego serwera / hosta. Jest to jedyny sposób na uwierzytelnienie serwera. Bez tego twoje połączenie SSH może zostać poddane atakowi typu man-in-the-middle .
Jeśli naprawdę masz pewność, że chcesz zignorować sprawdzenie odcisku palca, skorzystaj z drugiej najlepszej, mniej bezpiecznej opcji
StrictHostKeyChecking=accept-new
, która została wprowadzona w wersji OpenSSH 7.6 (2017-10-03) :Nie używaj starej wartości,
StrictHostKeyChecking=no
która nigdy nie sprawdza autentyczności serwera. (Chociaż znaczenie tego=no
ustawienia zostanie później zmienione w niektórych wydaniach ).źródło