Quando si collega per la prima volta tramite SSH al mio server, l'impronta digitale segnalata non corrisponde a quella che mi è stata data quando ho generato la chiave SSH

Question

Quando si collega per la prima volta tramite SSH al mio server, l'impronta digitale segnalata non corrisponde a quella che mi è stata data quando ho generato la chiave SSH

#1 da (2 voti)

1

Quando ho usato ssh-genkey su macOS per generare la coppia di file chiave (uno chiamato con .pub ), quello strumento ha riportato un SHA256 hash come fingerprint della chiave pubblica .

Al primo collegamento al mio server, una Digital Ocean droplet istanza del server virtuale in esecuzione < a href="https://en.wikipedia.org/wiki/FreeBSD"> FreeBSD inizializzato con i contenuti del mio file .pub chiave pubblica, al primo tentativo di connettermi con ssh 1.2.3.4 ottengo il messaggio :

The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established.

ECDSA key fingerprint is SHA256:tjdoQBGbHexAm+uwZ5rZwxyJH0nxjMC08QtO47QGQjE.

Questo non sembra corrispondere allo SHA256 restituito da ssh-keygen quando ho creato i file chiave.

Alcuni siti sembrano dire che dovrei ignorare questo problema. Affermano che l'impronta digitale chiave che appare quando si connette al mio server tramite ssh non è correlata all'impronta digitale del contenuto del file della chiave pubblica ssh che ho caricato su Digital Ocean per essere utilizzato nella creazione dell'istanza del server. Trovo questo difficile da capire.

Che punto c'è in Digital Ocean insistendo nel fornire una chiave pubblica SSH da usare nella configurazione del mio nuovo server se viene ignorata o è irrilevante?
Cosa ferma un attacco Man-In-The-Middle se devo ignorare l'impronta digitale riportata durante il primo tentativo di stabilire una connessione / sessione ssh?
Perché ssh riporta anche un'impronta digitale chiave se vogliamo ignorarla?

ssh fingerprint

posta Basil Bourque 21.11.2018 - 01:56

fonte

1 risposta

Leggi altre domande sui tag ssh fingerprint

Come implementare sessioni utente sicure usando i cookie HttpOnly? C'è qualche rischio con il riflesso del valore dell'intestazione HTTP?

score 2 · Answer 1

Ci sono due tasti separati in gioco qui:

La tua chiave ssh del client personale che hai generato sul tuo laptop, la chiave privata è sul tuo laptop e quindi questa chiave identifica che una connessione proviene dal tuo laptop.
La chiave ssh del server che è stata generata sul server durante l'avvio per la prima volta (almeno suppongo di sì, dal momento che dici di aver caricato solo una chiave pubblica), la chiave privata è sul server, e quindi questa chiave identifica che la connessione sta terminando sul tuo server.

La tua domanda principale sembra essere: Che cosa fa Digital Ocean con la chiave pubblica che ho caricato durante la creazione della VM?

Per una risposta autorevole, dovresti leggere la documentazione di Digital Ocean, ma suppongo che la inseriscano in /home/user/.ssh/authorized_keys in modo che la tua chiave pubblica (ovvero il tuo laptop) sia l'unica a cui è consentito connettersi macchina. Vedi questa guida per maggiori informazioni.

Per rispondere alle tue 2a e 3a domanda: i client ssh seguono il paradigma Trust On First Use (TOFU) e ereditano tutti i punti di forza e di debolezza. Non è l'ideale, ma probabilmente è almeno buono come quello che succederebbe se provaste a cambiare ssh con i certificati: metà dei server ssh nel mondo userebbe il certificato predefinito fornito con openssh.