ssh: L'autenticità di 'hostname' host non può essere stabilita

Question

Quando ho ssh a una macchina, a volte ottengo questo avviso di errore e si spinge a dire "sì" o "no". Questa causa qualche problema durante l'esecuzione di script che ssh 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 automaticamente dire "sì" o ignorare questo?

Answer 1

A seconda del client ssh, è possibile impostare l'opzione StrictHostKeyChecking al no sulla riga di comando, e / o inviare la chiave in un file known_hosts nulli. È inoltre possibile impostare queste opzioni nel vostro file di configurazione, sia per tutti gli host o per un determinato insieme di indirizzi IP o nomi host.

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

Modifica

Come note @IanDunn, ci sono rischi per la sicurezza per fare questo. Se la risorsa cui si è connessi è stato falsificato da un attaccante, che potrebbe potenzialmente riprodurre del server di destinazione sfida di nuovo a voi, voi ingannare nel pensare che ci si connette alla risorsa remota, mentre in realtà si connettono a quella risorsa con le credenziali. Si dovrebbe valutare attentamente se questo è un rischio adeguato ad assumere prima di modificare il meccanismo di collegamento di saltare HostKeyChecking.

riferimento .

Answer 2

vecchia domanda che merita una risposta migliore.

È possibile impedire interattivo pronta senza disabilitare StrictHostKeyChecking (che è insicura).

Incorporare la seguente logica nello script:

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

Verifica se la chiave pubblica del server è in known_hosts. In caso contrario, richiede la chiave pubblica dal server e lo aggiunge al known_hosts.

In questo modo si è esposti ad un attacco man-in-the-middle solo una volta, che può essere mitigato da:

• in modo che lo script si connette prima volta su un canale protetto
• ispezionando tronchi o known_hosts per controllare le impronte digitali manualmente (da effettuare una sola volta)

Answer 3

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

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

Opzioni:

• La sottorete host può essere * per consentire un accesso illimitato a tutti gli IP.
• Modifica /etc/ssh/ssh_config per la configurazione globale o ~/.ssh/config per configurazione utente specifico.

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

domanda simile su superuser.com - vedi https://superuser.com/a/628801/55163

Answer 4

Assicurarsi ~/.ssh/known_hosts è scrivibile. Quello fissato per me.

Answer 5

Il modo migliore per andare su questo è quello di utilizzare 'BatchMode' oltre a 'StrictHostKeyChecking'. In questo modo, lo script accetterà un nuovo nome host e scrivere al file known_hosts, ma non richiederà sì / no intervento.

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

Answer 6

Modificare il file di configurazione normalmente tua trova a '~ / .ssh / config', e al beggining del file, aggiungere il sotto le linee

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

Set utente per your_login_user dice che queste impostazioni appartiene a your_login_user
StrictHostKeyChecking impostata su No eviterà il prompt dei
IdentityFile è percorso a chiave RSA

Questo funziona per me e il mio script, buona fortuna a voi.

Answer 7

Questo avviso viene emesso a causa delle caratteristiche di sicurezza, non disattivare questa funzione.

E 'solo una volta visualizzato.

Se appare ancora dopo la seconda connessione, il problema è probabilmente iscritto al file known_hosts. In questo caso si avranno inoltre il seguente messaggio:

Failed to add the host to the list of known hosts 

E 'possibile risolvere il problema modificando proprietario di cambiare i permessi del file di essere scrivibili dal tuo utente.

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

Answer 8

Con riferimento alla risposta di Cori, ho modificato e utilizzato al di sotto di comando, che sta lavorando. Senza exit, comando rimanente è stato in realtà accede al computer remoto, che non volevo nello script

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

Answer 9

Fare questo -> chmod +w ~/.ssh/known_hosts. Questo aggiunge il permesso di scrittura per il file alla ~/.ssh/known_hosts. Dopo di che l'host remoto verrà aggiunto al file known_hosts quando ci si connette ad esso la prossima volta.

Answer 10

In genere questo problema si verifica quando si sta modificando le chiavi molto oftenly. Sulla base del server potrebbe richiedere un certo tempo per aggiornare la nuova chiave che avete generato e incollato nel server. Così, dopo aver generato la chiave e incollare nel server, attendere 3 o 4 ore e quindi provare. Il problema deve essere risolto. E 'successo a me.

Answer 11

Idealmente, si dovrebbe creare un'autorità di certificazione autogestita. Iniziare con la generazione di una coppia di chiavi: ssh-keygen -f cert_signer

Poi firmare chiave dell'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 firmato: /etc/ssh/ssh_host_rsa_key-cert.pub

In /etc/ssh/sshd_config, puntare il HostCertificate al file: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Riavviare il servizio sshd: service sshd restart

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

È possibile che questo contiene:

• @cert-authority
• Il *.example.com dominio
• I contenuti completi del cert_signer.pub chiave pubblica

La chiave pubblica cert_signer si fiderà qualsiasi server il cui pubblico ospite chiave è firmato con la chiave privata cert_signer.

Anche se questo richiede una configurazione di una volta sul lato client, ci si può fidare più server, compresi quelli che non sono ancora stati accantonati (a patto che si firma ogni server, che è).

Per ulteriori dettagli, vedere questa pagina wiki .

Answer 12

Aggiungi questi al vostro / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Answer 13

Esegui questo nel server host di essa la questione premonizione

chmod -R 700 ~/.ssh

Answer 14

ho avuto lo stesso errore e volevo attirare l'attenzione sul fatto che - come è appena successo a me -. Si potrebbe semplicemente avere privilegi sbagliate
Hai impostato la directory .ssh sia come normale o root utente e in tal modo è necessario essere l'utente corretto. Quando è apparso questo errore, ero root ma ho configurato .ssh come utente normale. Uscendo root riparato.

Answer 15

risolvo il problema che dà sotto l'errore scritta:
Errore:
non è possibile stabilire l'autenticità di host 'XXX.XXX.XXX'.
chiave RSA di impronte digitali è 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: A9: 27: 83:. 89

Soluzione:
1. Installare qualsiasi strumento openSSH.
2. Eseguire il comando ssh
3. si chiederà do u aggiungere questo host come.    accettare SI.
4. Questo host aggiungerà nella nota lista degli host.
5. Ora siete in grado di connettersi con questo host.

Questa soluzione sta funzionando ora ......