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.