SSH: L'autenticità dell'host non può essere stabilita

Ti dice che non ti sei mai connesso a questo server prima d'ora. Se te lo aspettavi, è perfettamente normale. Se sei paranoico, verifica il checksum/impronta della chiave usando un canale alternativo. (Ma notate che qualcuno che può reindirizzare la vostra connessione ssh può anche reindirizzare una sessione del browser web.)

Se vi siete collegati a questo server prima da questa installazione di ssh, allora o il server è stato riconfigurato con una nuova chiave, o qualcuno sta spoofing l'identità del server. A causa della gravità di un attacco man-in-the-middle, vi avverte della possibilità.

In entrambi i casi, avete un canale criptato sicuro per somebody. Nessuno senza la chiave privata corrispondente all'impronta digitale 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 può decodificare ciò che inviate.

La chiave che usate per autenticarvi non è correlata… non vorreste inviare informazioni di autenticazione a un server fraudolento che potrebbe rubarle, e quindi non dovreste aspettarvi alcun cambiamento a seconda che usiate una passphrase o una chiave privata per il login. Semplicemente non siete ancora arrivati a questo punto.

Diciamo che si incontra qualcuno per scambiare qualche segreto aziendale. Il vostro consulente vi dice che non avete mai incontrato quella persona prima d'ora e che può essere un impostore. Inoltre, per i prossimi incontri con lui, il vostro consulente non vi avvertirà più. Questo è il significato del messaggio. La persona è il server remoto, e il vostro consulente è il client ssh.

Non credo sia paranoico controllare due volte l'identità della persona prima di condividere segreti con lei. Per esempio, potreste aprire una pagina web con una sua foto e confrontarla con il volto che avete davanti. Oppure controllare la sua carta d'identità.

Per il server bitbucket, potreste usare un computer diverso, più affidabile, e ottenere da esso la immagine del suo viso, per poi confrontarla con quella che avete nel computer che state usando ora. Uso:

ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -
``` ```
ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

Se le facce corrispondono, si può aggiungere la chiave al file ad esempio ~/.ssh/known_hosts (posizione standard in molte distribuzioni Linux) con:

&001

e il client ssh non vi avviserà perché conosce già la sua faccia. Confronterà le facce ogni volta che vi connetterete. Questo è molto importante. Nel caso di un impostore (ad es. un attacco man-in-the-middle), il client ssh rifiuterà la connessione perché la faccia sarà cambiata.

Ho dovuto semplicemente creare il file di testo known_hosts in ~/.ssh

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

Dopo averlo fatto, ha aggiunto l'host e non ho più visto il messaggio.

C'è un altro modo semplice Semplicemente toccando un file “config” sotto /root/.ssh e aggiungendo il parametro StrictHostKeyChecking no La prossima volta che si effettua il login su un server, la loro chiave rsa sarà aggiunta a host conosciuti e non chiederà “sì” per la conferma dell'autenticità

Questo messaggio è solo SSH che vi dice che non ha mai visto questa particolare chiave host prima d'ora, quindi non è in grado di verificare veramente che vi state connettendo all'host che pensate di essere. Quando dici “Sì” mette la chiave ssh nel tuo file host conosciuto, e poi nelle connessioni successive confronta la chiave che riceve dall'host con quella nel file host conosciuto.

C'era un articolo correlato sullo stack overflow che mostrava come disabilitare questo avviso, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .

A parte le risposte già date (non vi siete mai collegati a questo host prima), c'è anche la netta possibilità che non vi siate mai collegati prima dall'host attuale (a quell'host); questo è solo psicologicamente diverso; pensate di collegarvi dall'host A (a B), mentre in realtà state cercando di collegarvi dall'host X (a B). Questo può accadere, per esempio, quando prima ssh-ed da A a X e poi dallo stesso terminale cercate di ssh a B pensando di essere ancora su A.

Nel mio caso la password meno il login non funzionava a causa delle autorizzazioni della mia home directory perché ho modificato le impostazioni predefinite. Infine, ecco cosa ha funzionato per me. le mie autorizzazioni per la directory home sono

/home/nome utente

drwxr----x. 18 username groupname 4096 May 11 11:52 username

/home/username/.ssh

268823097 drwx------ 2 username groupname 29 May 11 11:53 .ssh

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys