ssh-keyscan - nadal obsługiwane w. Nie można ustalić autentyczności hosta „[nazwa hosta] ([adres IP])”


Piszę skrypt do zdalnej instalacji rsync i muszę dodać zdalny serwer do mojego lokalnego pliku znane_hosts, aby następujące monity nie były wyświetlane po pierwszym uruchomieniu skryptu:
Nie można ustalić tożsamości hosta „[nazwa hosta] ([adres IP])”. Odcisk cyfrowy klucza RSA to [odcisk palca klucza]. Czy na pewno chcesz kontynuować łączenie (tak/nie)?
Według

Czy mogę automatycznie dodać nowego hosta do moich znanych_hostów?
https://serverfault.com/questi ... hosts
Próbowałem (ze świeżym plikiem known_hosts):
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

Ale to nie działa, zawsze pojawia się monit o zaakceptowanie odcisku palca.
Kiedy pozwalam ssh dodać to za mnie, skrót klucza w pliku know_hosts jest zupełnie inny.
Co jeszcze muszę zrobić, aby rozwiązać ten problem?
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Spróbuj tego:
ssh-keyscan -t rsa [ip_address]

Weź wynik i wklej go do .ssh/known_hosts. Teraz, jeśli chcesz haszować znane_ hosty, zrób to:
ssh-keygen -H


edytować:

Oto jedyne rozwiązanie zespołu. Używa nazwy hosta, adresów IP i skrótów.
ssh-keyscan -Ht rsa [hostname],[IP address] >> known_hosts
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Odpowiedź Kschuriga zadziała, ale niekoniecznie najbezpieczniejsza. Zarabia dodatkowe punkty za dodatkową milę, umożliwiając identyfikację serwera za pomocą więcej niż jednego identyfikatora URI, to znaczy nazwy hosta i adresu IP. Oznacza to, że możesz nadal dodawać prawidłowe identyfikatory URI tego hosta, rozwijając listę oddzieloną przecinkami.
Jednak szukałem swobodnego sposobu na obejście nieznanej ręcznej interakcji z hostem podczas klonowania repozytorium git, jak pokazano poniżej, a to powinno pomóc w wyjaśnieniu, co się dzieje i jak można uniknąć tej części skryptu dla niektórych związanych z SSH rzeczy:
brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?

Zwróć uwagę na odcisk cyfrowy klucza RSA ...
Więc to jest SSH, będzie działać dla git zamiast SSH i tylko dla rzeczy związanych z SSH w ogóle ...
brad@computer:~$ nmap bitbucket.org --script ssh-hostkeyStarting Nmap 7.01 ( [url=https://nmap.org]https://nmap.org[/url] ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp open ssh
| ssh-hostkey:
| 1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_ 2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp open http
443/tcp open httpsNmap done: 1 IP address (1 host up) scanned in 42.42 seconds

Najpierw zainstaluj nmap na swoim codziennym sterowniku. Nmap jest bardzo przydatny do pewnych rzeczy, takich jak odkrywanie otwartych portów i ręczne sprawdzanie odcisków palców SSH. Ale wracając do tego, co robimy.
Dobry. Albo jestem zagrożony w kilku miejscach i na maszynach, które testowałem, albo istnieje bardziej prawdopodobne wyjaśnienie, że wszystko, co ssę, to dori.
Ten „odcisk palca” to po prostu linia, która została skrócona przy użyciu algorytmu jednokierunkowego dla wygody człowieka, z ryzykiem konwersji wielu linii na ten sam odcisk palca. Czasami nazywane są kolizjami.
Jednak wracając do oryginalnej linii, którą możemy zobaczyć w kontekście poniżej.
brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg

Dlatego z wyprzedzeniem możemy zażądać formularza identyfikacyjnego od pierwotnego gospodarza.
W tym momencie jesteśmy tak samo podatni na ataki jak i automatycznie - ciągi znaków pasują do siebie, mamy podstawowe dane, które tworzą odcisk palca i możemy zażądać tych podstawowych danych (zapobieganie konfliktom) w przyszłości.
Teraz, aby użyć tej linii w sposób, który nie pyta o autentyczność hosta ...
W tym przypadku plik znane_hosts nie używa wpisów w postaci zwykłego tekstu. Rozpoznasz zaszyfrowane wpisy, gdy je zobaczysz, wyglądają jak skróty z losowymi znakami zamiast xyz.com lub 123.45.67.89.
brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==

Pojawia się pierwsza linia komentarza, co jest denerwujące, ale możesz się go pozbyć za pomocą prostego przekierowania za pomocą przycisku „& >” lub „& > & >”.
Ponieważ zrobiłem wszystko, co w mojej mocy, aby uzyskać czyste dane, które będą używane do identyfikacji „hosta” i zaufania, dodam tę identyfikację do mojego pliku known_hosts w katalogu ~/.ssh. Ponieważ zostanie on teraz zidentyfikowany jako znany gospodarz, nie otrzymam powyższej prośby, gdy byłeś młodym mężczyzną.
Dzięki za pozostanie ze mną, gotowe. Dodaję klucz bitbucket RSA, aby móc wchodzić w interakcję z moimi repozytoriami git w sposób nieinteraktywny w ramach przepływu pracy CI, ale cokolwiek chcesz zrobić.
#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

Tak więc dzisiaj pozostajesz dziewicą. Możesz zrobić to samo na githubie, postępując zgodnie z podobnymi wskazówkami w dogodnym dla siebie czasie.
Widziałem tak wiele postów Stack Overflow sugerujących programowe dodawanie klucza na ślepo bez żadnej weryfikacji. Im częściej sprawdzasz poprawność klucza na różnych komputerach w różnych sieciach, tym większe będzie zaufanie, że host jest tym, o którym mówi - i jest to najlepsze, na co możesz liczyć na tym poziomie bezpieczeństwa.
ŹLE
<del>
ssh -oStrictHostKeyChecking = brak nazwy hosta [polecenie]
</del>
ŹLE
<del>
ssh-keyscan -t rsa -H nazwa hosta & > & > ~/.ssh/znane_hosty
</del>
Proszę nie wykonywać żadnej z powyższych czynności. Masz szansę zwiększyć swoje szanse na uniknięcie podsłuchania transmisji danych przez osobę będącą w centrum ataku - skorzystaj z tej okazji. Różnica polega na dosłownym potwierdzeniu, że posiadany klucz RSA jest prawdziwym kluczem serwera, a teraz wiesz, jak uzyskać te informacje, aby je porównać, aby móc zaufać połączeniu. Pamiętaj tylko, że więcej porównań z różnych komputerów i sieci zwykle zwiększa twoją zdolność zaufania do połączenia.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się