Come fa il client SSH a garantire che il server SSH porti la chiave privata, che è la coppia della chiave pubblica nel file "known_hosts" del client?

Il protocollo Secure Layer (SSH) Transport Layer Protocol (RFC 4253) descrive come viene eseguita l'autenticazione del server. Secondo la sezione 7 esiste un'autenticazione server implicita ed esplicita. L'autenticazione implicita richiede un segreto condiviso tra client. L'autenticazione esplicita significa che i messaggi di scambio della chiave "includono una firma o altra prova dell'autenticità del server" . Questo è il tipo di autenticazione del server che di solito si usa, vale a dire dove il server ha una coppia di chiavi, la chiave pubblica è nota al client e vuole verificare che la destinazione della connessione conosca la chiave privata corrispondente.

Come l'autenticazione esplicita è inclusa nello scambio di chiavi Diffie-Hellman è descritta nella sezione 8. Essenzialmente il server firma alcuni dati dal client usando la chiave privata del server per provare la proprietà della chiave e il client convalida questa firma usando il noto chiave pubblica. Questi dati forniti dai clienti includono dati casuali, quindi è impossibile eseguire la riproduzione di una firma precedente. Per i dettagli molto più profondi, vedi RFC stesso .

Non penso che questo controllo sia l'autenticazione da parte del client SSH, ciò a cui ti riferisci sembra che sia la cache per le chiavi host del server nel client SSH. Questo serve a identificare il server, ma non è l'autenticazione

Ci sono due scenari di autenticazione per SSH (che io sappia), in entrambi i casi è il client che è autenticato, non il server:

1) (predefinito) autenticazione con password semplice, in cui il server sfida il client per una password. In questo caso non ci sono controlli da parte del cliente.

2) Utilizzo delle chiavi SSH: ciò comporta la generazione di una chiave privata sul computer client e l'importazione della chiave pubblica corrispondente sul server. In questo caso, qualcosa di simile accade a ciò che stai descrivendo, ma il client sta utilizzando la propria chiave privata per crittografare il messaggio del server. Il server sta quindi controllando questo messaggio crittografato contro la chiave pubblica del client. È considerato più sicuro e facile da gestire rispetto a una semplice password, a condizione che la chiave privata sia mantenuta sicura

Ecco una buona ripartizione del processo di autenticazione della chiave SSH da Digital Ocean

Essendo frustrato da DigitalOcean anche per questo argomento, propongo questa risposta. Il riferimento è la sezione 8 della RFC4253 che pretende, durante Diffie-Hellman Key Exchange:

First, the client sends the following:

  byte      SSH_MSG_KEXDH_INIT
  mpint     e

The server then responds with the following:

  byte      SSH_MSG_KEXDH_REPLY
  string    server public host key and certificates (K_S)
  mpint     f
  string    signature of H

In sostanza, durante Diffie-Hellman scambio di chiavi / generando , cliente crea il tasto "E" dalla sua chiave segreta "x"; il server farà lo stesso con "f" da "y". Con "x" e "f" (client) o "y" e "e" (server), la crittografia chiave segreta "K" è calcolato su entrambi i lati (ho lasciato si guarda la magia Diffie-Hellman).

Poi arriva il trucco :) Un grande calcolo viene eseguito su entrambi i lati: "H". Che è un hash di una lunga stringa che include molte cose come e, f, nome del server "V_S", nome del client "V_C", contenuto dei messaggi precedenti ("SSH_MSG_KEXINIT" dal client / server="I_C" / "I_S") , chiave del server pubblico "K_S" e, last but not least, la chiave segreta K:

H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)

H non è esplicitamente fornito al client poiché conosce tutte queste informazioni e quindi può anche calcolarlo; ma piuttosto, il server fornisce la firma di H, calcolata con la chiave privata del server. Il client può quindi controllare questa firma grazie al proprio calcolo di H e alla chiave pubblica K_S per autenticare il server.

Il punto principale secondo me è quello di mescolare -a meno- K (segreto) e firma: nessuna MitM può mascherarsi un tale messaggio

Questa sembra una risposta pertinente alla tua domanda: Verifica dell'impronta digitale SSH di un server pubblico

In breve, il server SSH ha una chiave pubblica e privata che vengono utilizzate mentre si stabilisce una connessione dal client SSH. Il server fornirà una copia della sua chiave pubblica al client dove viene presentata all'utente per la verifica. L'utente è quindi responsabile della convalida di quella chiave con l'amministratore del server e quindi dell'accettazione della chiave.

Una volta accettato, l'utente lo vedrà sempre solo se la chiave cambia. Quando la chiave cambia, potrebbe essere una ri-chiave eseguita sul server dall'amministratore o tramite attacco in stile MITM; dovresti ricontrollare la chiave con l'amministratore per vedere quale è quale.

Non ci sono "sfide" perché credo che tu stia cercando di dirlo, poiché questo è esattamente come Chiave pubblica La crittografia funziona.

Modifica Un server SSH genererà automaticamente le sue chiavi host durante l'installazione tramite l'utilizzo dell'applicazione ssh-keygen . Questo in genere crea una chiave RSA, DSA, ecdsa o ed25519, o qualche variazione lì (a seconda della configurazione).

Un client che si connette al server utilizzerà ssh-keyscan per verificare l'impronta digitale del server e presentarlo all'utente come verifica. Quando accetti quella chiave, la scrive nel file ~/.ssh/known_hosts per ricordarla. Ogni volta che il tuo client ssh lo collega a quel server, legge l'impronta digitale, lo controlla nel file known_hosts e assicura che non sia cambiato. Se lo fa, tu, l'utente, ti viene presentato un avvertimento che la chiave è cambiata e che la connessione è stata interrotta. È necessario eliminare o modificare manualmente la chiave per potersi connettere di nuovo.

$ ssh-keyscan some.remote.server
some.remote.server ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA8BPNr+Q8cQfU95jfJKIfAH+z0+q03QDeFH1ndeTC3Zf0EDjZOg1OXs+Xiwjgrkq+vcNIA5DPaux3aStrcSa5o1AjgBNKN4rMyaLMW1c5LUnSic2oE7YTGvO1AHL55+Z4rCiEbDHeK2LXwhZifNvqkxf44pKrIe8kCvt89dkRsCria4n5EedGazKxO0mvbHM9JSpg03CiD4B+/afOrZqCJrf5dYcDCmeiBPSn9vjiZzAl2NYj05GVSqoe8KeFQV9n4c4LtWfzSDshvLlypuSfylzhL3euWG6JP8G6HnBohSiSQFk/Y0VFX/4wYshKjN3px0ugYUrucXXv8Sznv6n1Dw==

Se dovessi aprire il file known_hosts sul mio sistema, vedresti questa voce esatta lì dentro.

EDIT 2:

Leggendo i commenti, ti sembra di essere bloccato su questo bit di impronta digitale. L'impronta digitale è la parte pubblica della crittografia a chiave pubblica. Dovresti davvero leggere di più su questo come ho collegato prima per comprendere appieno questo concetto. In Crypto a chiave pubblica, una chiave privata e una chiave pubblica vengono create matematicamente contemporaneamente. Questa coppia di chiavi possiede un'abilità speciale in quanto qualsiasi cosa criptata dalla chiave privata può essere SOLO decrittografata dalla chiave pubblica e qualsiasi cosa criptata dalla chiave pubblica può SOLO essere decodificata dal Chiave privata Questo è cypto asimmetrico, NON crypto simmetrico (usando una chiave per cifrare / decifrare).

Devi anche capire come funziona la firma per comprendere l'uso della crittografia a chiave pubblica. Se scrivo un messaggio in chiaro e te lo mando, non sai che l'ho inviato. Se invece scrivo un messaggio di testo in chiaro e in fondo aggiungo un blob crittografato che contiene un hash del messaggio ed è stato crittografato usando la mia chiave privata, quindi la mia chiave pubblica può essere usata per decrittografare il blob, il messaggio di testo in chiaro può essere sottoposto a hash e confrontato con l'hash che ho incluso nel blob crittografato.

Questo stesso concetto è applicato qui con SSH. Poiché solo la chiave privata utilizzata sul server è in grado di funzionare con la chiave pubblica del client, è possibile provare matematicamente che si tratta della stessa macchina. Come accennato nel mio commento, è quasi impossibile generare due chiavi private che sono una corrispondenza esatta fornendo così un'impronta digitale duplicata. Se potessi generare una chiave privata che era esattamente la stessa della chiave privata di un altro server, allora sì, avresti la stessa impronta di quella di un altro server. Consideralo impossibile oggi.

Ho letto parti della RFC4253 come suggerito da Steffen Ullrich. Di seguito è riportata una descrizione molto incompleta, ma quello che capisco è:

1. Client e server ottengono un numero di segreti condivisi come risultato dello scambio di chiavi.
2. Il server firma questi segreti condivisi utilizzando la sua chiave privata e lo invia al client.
3. Il client decrittografa usando la chiave pubblica del server. Se il risultato corrisponde a quanto descritto nella RFC4253, il server viene autenticato.

Per un attimo ho pensato: "Aspetta, perché abbiamo bisogno di un meccanismo di autenticazione esplicito? Poiché il client utilizza la chiave pubblica del server per crittografare il materiale inviato al server, se il server è falso, il server ha vinto" essere in grado di decifrare ciò che viene inviato dal client Poiché il server non capirebbe cosa ha detto il client, il server non sarà in grado di produrre una risposta significativa, quindi il client dovrebbe sapere che il server è falso dal momento il server invierà una risposta priva di significato. "

Bene, il paragrafo precedente è completamente errato. Poiché il client e il server utilizzano la crittografia a chiave simmetrica per comunicare dopo lo scambio di chiavi. Quindi, le chiavi asimmetriche del server (e potenzialmente del client) vengono utilizzate solo a scopo di autenticazione. Non per scopi di comunicazione.