come evitare che ssh chieda il permesso?


59

Stiamo tentando di accelerare l'installazione di nodi Oracle per l'installazione RAC. questo richiede che ssh sia installato e configurato in modo che non richieda una password.

Il problema è: al primo utilizzo, viene richiesto

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

C'è un modo per evitarlo o siamo condannati a connetterci almeno una volta su ogni server da ogni server manualmente?

Risposte:


92

Imposta StrictHostKeyChecking nonel tuo /etc/ssh/ssh_configfile, dove sarà un'opzione globale utilizzata da tutti gli utenti sul server. Oppure impostalo nel tuo ~/.ssh/configfile, dove sarà l'impostazione predefinita solo per l'utente corrente. Oppure puoi usarlo dalla riga di comando:

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

Ecco una spiegazione di come funziona man ssh_config (o vedi questa versione più attuale ):

StrictHostKeyChecking

      Se questo flag è impostato su "yes", ssh non aggiungerà mai automaticamente le chiavi host al $HOME/.ssh/known_hostsfile e rifiuta di connettersi agli host la cui chiave host è stata modificata. Ciò fornisce la massima protezione contro gli attacchi di trojan horse, tuttavia può essere fastidioso quando il /etc/ssh/ssh_known_hostsfile è gestito in modo inadeguato o quando vengono spesso effettuate connessioni a nuovi host. Questa opzione obbliga l'utente ad aggiungere manualmente tutti i nuovi host. Se questo flag è impostato su "no", sshaggiungerà automaticamente nuove chiavi host ai file host conosciuti dall'utente. Se questo flag è impostato su "chiedi", le nuove chiavi host verranno aggiunte ai file host conosciuti dall'utente solo dopo che l'utente ha confermato che è ciò che realmente vuole fare e ssh si rifiuterà di connettersi agli host la cui chiave host è cambiata . Le chiavi host di host noti verranno verificate automaticamente in tutti i casi. L'argomento deve essere "sì", "no" o "chiedi". L'impostazione predefinita è "chiedi".


1
+1, anche questo per i miei server. E per essere chiari, il messaggio nella domanda proviene dal client SSH sul computer client di connessione e non dal server.
Patkos Csaba,

3
Questa risposta suona come un problema di sicurezza in preparazione.
SunSparc,

25

ssh-keyscan - Raccogli le chiavi pubbliche ssh

Se conosci già l'elenco degli host a cui ti collegherai, puoi semplicemente emettere:

ssh-keyscan host1 host2 host3 host4

Puoi dare la -Hpossibilità di avere ora i risultati come hash predefiniti di ssh

Inoltre si può dare -t keytypeeri KeyType è dsa, rsao ecdsase si dispone di una preferenza su quale tipo di chiave per afferrare al posto del default.

Una volta eseguito ssh-keyscan, avrà pre-popolato il file degli host conosciuti e non avrai ssh che ti chiederà il permesso di aggiungere una nuova chiave.


1
Sono un po 'perplesso sul commento "avrà pre-popolato" ... known_hosts non viene creato o modificato dopo averlo eseguito. Vuoi dire che il contenuto può essere reindirizzato al file per popolarlo?
rschwieb,

4
Confermando con techrepublic.com/article/… . ssh-keyscan -H myhost >> ~/.ssh/known_hosts, o per tutto il server,/etc/ssh/ssh_known_hosts
cole

12

È possibile aggiungere l'impronta digitale ai known_hosts di ciascun server. Per un singolo utente:

cat ~/.ssh/known_hosts
echo "$SERVER,$PORT ssh-rsa $SERVER_KEY_FINGERPRINT" >> ~/.ssh/known_hosts

3
Questo non è più il modo giusto per farlo da quando è stato introdotto l'hashing.
Deim0s

10

Ignora host

Ignora HostKeyChecking. Per questo uso ad esempio:

ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null user@example.net

Aggiungi host

Aggiungi l'impronta digitale dell'host / server .ssh/known_hostsprima della prima connessione. Questo è il modo più sicuro.


Ciao. Oracle emette il comando ssh, quindi non ho alcun controllo su come esegue questo.
Nicolas de Fontenay

Upvoted. La maggior parte delle risposte che ho visto manca la menzione di dev nulling del file hosts noto. Questo rende il comando molto più utilizzabile e non rovinerà alcuna configurazione esistente.
Alex,

(2) Certo, l'aggiunta dell'impronta digitale al file hosts noto è l'approccio ideale, ma come si fa? (1) Perché è utile impostare il file hosts noto dall'utente su  /dev/null? Non sarebbe meglio fare ssh -oStrictHostKeyChecking=no user@example.netuna volta per ottenere l'impronta digitale del server nel $HOME/.ssh/known_hostsfile, quindi le connessioni successive procederanno senza una richiesta di conferma?
G-Man dice "Reinstate Monica" il

3

Esegui il frammento seguente prima di provare.

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

ps: rigorosamente non per server di produzione, attenzione a ManInMiddle


0

Mi piace la risposta di Tim per le cose di un tipo, tuttavia, se questo è un host a cui intendi collegarti su base regolare, creerei una voce nella tua ~ / .ssh / config (crearla se il file non esiste).

# 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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.