ssh: l'autenticità dell'host 'hostname' non può essere stabilita

Quando ssh a una macchina, a volte ricevo questo avviso di errore e viene richiesto di dire "sì" o "no". Ciò causa alcuni problemi durante l'esecuzione da script che vengono inviati automaticamente ad altre macchine.

Messaggio di avviso:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

C'è un modo per dire automaticamente "sì" o ignorarlo?

A seconda del client ssh, è possibile impostare l'opzione StrictHostKeyChecking su no nella riga di comando e / o inviare la chiave a un file known_hosts null. Puoi anche impostare queste opzioni nel tuo file di configurazione, per tutti gli host o per un determinato set di indirizzi IP o nomi host.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

MODIFICARE

Come osserva @IanDunn, ci sono rischi per la sicurezza nel fare questo. Se la risorsa a cui ti stai connettendo è stata falsificata da un utente malintenzionato, potrebbero potenzialmente rispedirti la sfida del server di destinazione, inducendoti a pensare che ti stai connettendo alla risorsa remota mentre in realtà si stanno connettendo a quella risorsa con le tue credenziali. È necessario valutare attentamente se si tratta di un rischio adeguato da assumere prima di modificare il meccanismo di connessione per saltare HostKeyChecking.

Riferimento .

Vecchia domanda che merita una risposta migliore.

È possibile impedire la richiesta interattiva senza disabilitare StrictHostKeyChecking(che non è sicuro).

Incorporare la seguente logica nel tuo script:

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Verifica se è presente la chiave pubblica del server known_hosts. In caso contrario, richiede la chiave pubblica dal server e la aggiunge a known_hosts.

In questo modo sei esposto all'attacco Man-In-The-Middle una sola volta, che può essere mitigato da:

• assicurando che lo script si connetta per la prima volta su un canale sicuro
• ispezione dei registri o known_hosts per controllare manualmente le impronte digitali (da eseguire una sola volta)

Per disabilitare (o controllare la disabilitazione), aggiungere le seguenti righe all'inizio di /etc/ssh/ssh_config...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

Opzioni:

• La sottorete Host può essere quella *di consentire l'accesso senza restrizioni a tutti gli IP.
• Modifica /etc/ssh/ssh_configper la configurazione globale o ~/.ssh/configper la configurazione specifica dell'utente.

Vedi http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

Domanda simile su superuser.com: consultare https://superuser.com/a/628801/55163

Assicurati che ~/.ssh/known_hostssia scrivibile. Ciò ha risolto il problema per me.

Il modo migliore per farlo è usare 'BatchMode' oltre a 'StrictHostKeyChecking'. In questo modo, lo script accetterà un nuovo nome host e lo scriverà nel file known_hosts, ma non richiederà un intervento sì / no.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

Modifica il tuo file di configurazione che si trova normalmente in '~ / .ssh / config' e all'inizio del file aggiungi le righe seguenti

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

L'utente è impostato su your_login_userdice che questa impostazione appartiene a your_login_user.
StrictHostKeyControllo impostato su no eviterà il prompt
IdentityFile è percorso alla chiave RSA

Questo funziona per me e le mie sceneggiature, buona fortuna a te.

Questo avviso viene emesso a causa delle funzioni di sicurezza, non disabilitare questa funzione.

Viene visualizzato solo una volta.

Se appare ancora dopo la seconda connessione, il problema è probabilmente nella scrittura nel known_hostsfile. In questo caso riceverai anche il seguente messaggio:

Failed to add the host to the list of known hosts 

È possibile risolverlo modificando il proprietario modificando le autorizzazioni del file in modo che siano modificabili dall'utente.

sudo chown -v $USER ~/.ssh/known_hosts

Con riferimento alla risposta di Cori, l'ho modificata e utilizzata sotto il comando, che funziona. Senza exit, il comando rimanente stava effettivamente registrando su una macchina remota, cosa che non volevo nello script

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

Fai questo -> chmod +w ~/.ssh/known_hosts. Questo aggiunge il permesso di scrittura al file su ~/.ssh/known_hosts. Successivamente l'host remoto verrà aggiunto al known_hostsfile quando ci si connette ad esso la volta successiva.

Idealmente, è necessario creare un'autorità di certificazione autogestita. Inizia con la generazione di una coppia di chiavi: ssh-keygen -f cert_signer

Quindi firmare la chiave host pubblica di ciascun server: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Questo genera una chiave host pubblica firmata: /etc/ssh/ssh_host_rsa_key-cert.pub

In /etc/ssh/sshd_config, punta HostCertificatea questo file: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Riavvia il servizio sshd: service sshd restart

Quindi sul client SSH, aggiungere quanto segue a ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Quanto sopra contiene:

• @cert-authority
• Il dominio *.example.com
• Il contenuto completo della chiave pubblica cert_signer.pub

La cert_signerchiave pubblica si fiderà di qualsiasi server la cui chiave host pubblica è firmata dalla cert_signerchiave privata.

Sebbene ciò richieda una configurazione una tantum sul lato client, puoi fidarti di più server, inclusi quelli che non sono stati ancora sottoposti a provisioning (purché firmi ogni server, vale a dire).

Per maggiori dettagli, vedi questa pagina wiki .

Generalmente questo problema si verifica quando si modificano le chiavi molto spesso. In base al server, potrebbe essere necessario del tempo per aggiornare la nuova chiave generata e incollata nel server. Quindi, dopo aver generato la chiave e incollato nel server, attendere 3-4 ore e quindi provare. Il problema dovrebbe essere risolto. È successo con me

Aggiungi questi al tuo / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Esegui questo nel server host è un problema di premonizione

chmod -R 700 ~/.ssh

Ho avuto lo stesso errore e volevo attirare l'attenzione sul fatto che - come mi è appena successo - potresti avere solo privilegi sbagliati.
Hai impostato la tua .sshdirectory come normale o rootutente e quindi devi essere l'utente corretto. Quando è apparso questo errore, lo ero rootma ho configurato .sshcome utente normale. L'uscita l'ha rootrisolto.

Risolvo il problema che riporta l'errore scritto di seguito:
Errore:
impossibile stabilire l'autenticità dell'host "XXX.XXX.XXX".
L'impronta digitale della chiave RSA è 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Soluzione:
1. installare qualsiasi strumento openSSH.
2. esegui il comando ssh
3. ti chiederà di aggiungere questo host come. accetta SÌ.
4. Questo host verrà aggiunto all'elenco host noto.
5. Ora sei in grado di connetterti con questo host.

Questa soluzione funziona ora ......