jak uniknąć ssh pytając o pozwolenie?

57

Próbujemy przyspieszyć instalację węzłów Oracle dla instalacji RAC. wymaga to, abyśmy zainstalowali i skonfigurowali ssh, aby nie pytał o hasło.

Problem polega na tym: przy pierwszym użyciu pojawia się monit

RSA key fingerprint is 96:a9:23:5c:cc:d1:0a:d4:70:22:93:e9:9e:1e:74:2f.
Are you sure you want to continue connecting (yes/no)? yes

Czy istnieje sposób, aby tego uniknąć, czy też jesteśmy skazani na łączenie się przynajmniej raz na każdym serwerze z każdego serwera ręcznie?

ssh key-authentication Nicolas de Fontenay
źródło

Odpowiedzi:

90

Ustaw StrictHostKeyChecking now swoim /etc/ssh/ssh_configpliku, gdzie będzie globalną opcją używaną przez każdego użytkownika na serwerze. Lub ustaw go w swoim ~/.ssh/configpliku, gdzie będzie domyślny tylko dla bieżącego użytkownika. Możesz też użyć go w wierszu poleceń:

ssh -o StrictHostKeyChecking=no -l "$user" "$host"

Oto wyjaśnienie, jak to działa man ssh_config (lub zobacz tę bardziej aktualną wersję ):

StrictHostKeyChecking

      Jeśli ta flaga jest ustawiona na „tak”, ssh nigdy nie doda automatycznie kluczy hosta do $HOME/.ssh/known_hostspliku i odmówi połączenia z hostami, których klucz został zmieniony. Zapewnia to maksymalną ochronę przed atakami koni trojańskich, jednak może być denerwujące, gdy /etc/ssh/ssh_known_hostsplik jest źle zarządzany lub często nawiązywane są połączenia z nowymi hostami. Ta opcja zmusza użytkownika do ręcznego dodawania wszystkich nowych hostów. Jeśli ta flaga jest ustawiona na „nie”, sshautomatycznie doda nowe klucze hosta do znanych plików hostów. Jeśli ta flaga jest ustawiona na „pytaj”, nowe klucze hosta zostaną dodane do znanych plików hosta dopiero wtedy, gdy użytkownik potwierdzi, że tak naprawdę chce zrobić, a ssh odmówi połączenia z hostami, których klucz został zmieniony . Klucze znanych hostów będą weryfikowane automatycznie we wszystkich przypadkach. Argumentem musi być „tak”, „nie” lub „zapytaj”. Domyślnie jest to „zapytaj”.

Tim Kennedy
źródło
1
+1, ja też to dla moich serwerów. I dla jasności, wiadomość w pytaniu pochodzi od klienta ssh na łączącym się komputerze klienckim, a nie z serwera.
Patkos Csaba
3
Ta odpowiedź brzmi jak problem bezpieczeństwa.
SunSparc
25

ssh-keyscan - Zbierz klucze publiczne ssh

Jeśli znasz już listę hostów, z którymi się połączysz, możesz po prostu wydać:

ssh-keyscan host1 host2 host3 host4

Możesz podać -Hopcję mieszania wyników, takich jak domyślne ssh do teraz

Również można dać -t keytypebyły keytype jest dsa, rsalub ecdsajeśli masz preferencje co do których rodzaj klucza chwycić zamiast domyślnego.

Po uruchomieniu ssh-keyscanplik zostanie wstępnie zapełniony i nie będziesz ssh pytał o pozwolenie na dodanie nowego klucza.

kurtm
źródło
1
Jestem trochę zdziwiony komentarzem „będą miały wstępnie wypełnione” ... znane_hosty nie są tworzone ani modyfikowane po uruchomieniu tego. Masz na myśli, że zawartość może być przesłana do pliku w celu zapełnienia?
rschwieb
4
Potwierdzenie z techrepublic.com/article/… . ssh-keyscan -H myhost >> ~/.ssh/known_hostslub dla całego serwera,/etc/ssh/ssh_known_hosts
cole
12

Możesz dodać odcisk palca do znanych hostów każdego serwera. Dla jednego użytkownika:

cat ~/.ssh/known_hosts
echo "$SERVER,$PORT ssh-rsa $SERVER_KEY_FINGERPRINT" >> ~/.ssh/known_hosts
David Souther
źródło
3
To już nie jest właściwy sposób, aby to zrobić, odkąd wprowadzono haszowanie.
Deim0s,
10

Zignoruj ​​hosta

Zignoruj ​​HostKeyChecking. Do tego używam np .:

ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null [email protected]

Dodaj hosta

Dodaj odcisk palca hosta / serwera .ssh/known_hostsprzed pierwszym połączeniem. To jest bezpieczniejszy sposób.

xebeche
źródło
Cześć. Oracle wydaje polecenie ssh, więc nie mam kontroli nad tym, jak to wykonuje.
Nicolas de Fontenay
Pozytywne. W większości odpowiedzi, które widziałem, brakuje wzmianki o dev zerowaniu znanego pliku hosts. To sprawia, że ​​polecenie jest znacznie bardziej użyteczne i nie zniszczy żadnej istniejącej konfiguracji.
Alex
(2) Oczywiście dodanie odcisku palca do znanego pliku hosts jest idealnym podejściem - ale jak to zrobić? (1) Dlaczego warto ustawić plik hosts znany dla użytkownika  /dev/null? Czy nie lepiej byłoby zrobić ssh -oStrictHostKeyChecking=no [email protected]raz, aby pobrać odcisk palca serwera do $HOME/.ssh/known_hostspliku, aby kolejne połączenia przebiegały bez prośby o potwierdzenie?
G-Man
3

Przed próbą wykonaj następujący fragment kodu.

mkdir -p ~/.ssh     
echo "Host *" > ~/.ssh/config     
echo " StrictHostKeyChecking no" >> ~/.ssh/config

ps: Ściśle nie dla serwerów produkcyjnych, strzeż się ManInMiddle

147,3 tys
źródło
0

Podoba mi się odpowiedź Tima na rzeczy jednorazowe, jeśli jednak jest to host, z którym zamierzasz się regularnie łączyć, utworzyłbym wpis w twoim ~ / .ssh / config (utwórz go, jeśli plik nie istnieje).

# this example shows wildcard for IP
# you can even use more than one wildcard 10.0.*.* for example
Host 192.168.56.*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
# you can even alias it, which is really useful when scp'ing/rsyncing foo:/path/to/remote
Host foo
    HostName foo-long-192-10-135-55.hostname.not-going-to-remember.doh
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
Jaime
źródło