Qual è la differenza tra authorized_keys e known_hosts per SSH?

Il file known_hosts consente al client di autenticare il server, per verificare che non si connetta a un imitatore. Il file authorized_keys consente al server di autenticare l'utente.

Autenticazione server

Una delle prime cose che accade quando viene stabilita la connessione SSH è che il server invia la sua chiave pubblica al client e dimostra (grazie a crittografia a chiave pubblica ) al client che conosce la chiave privata associata. Questo autentica il server: se questa parte del protocollo ha successo, il client sa che il server è chi afferma di essere.

Il client può verificare che il server sia noto e non un server non autorizzato che tenta di passare come quello giusto. SSH fornisce solo un semplice meccanismo per verificare la legittimità del server: ricorda i server a cui sei già connesso, nel file ~/.ssh/known_hosts sul computer client (esiste anche un file system-% /etc/ssh/known_hosts ). La prima volta che ci si connette a un server, è necessario verificare con altri mezzi che la chiave pubblica presentata dal server sia realmente la chiave pubblica del server a cui si desidera connettersi. Se disponi della chiave pubblica del server a cui ti stai connettendo, puoi aggiungerla manualmente a ~/.ssh/known_hosts sul client.

A proposito, known_hosts può contenere qualsiasi tipo di chiave pubblica supportata dall'implementazione SSH, non solo DSA (anche RSA e ECDSA).

L'autenticazione del server deve essere eseguita prima di inviare ad essa dati riservati. In particolare, se l'autenticazione dell'utente comporta una password, la password non deve essere inviata a un server non autenticato.

Autenticazione utente

Il server consente solo a un utente remoto di accedere se quell'utente può dimostrare di avere il diritto di accedere a tale account. A seconda della configurazione del server e della scelta dell'utente, l'utente può presentare una delle varie forme di credenziali (l'elenco seguente non è esaustivo).

• L'utente può presentare la password per l'account a cui sta tentando di accedere; il server verifica quindi che la password sia corretta.
• L'utente può presentare una chiave pubblica e dimostrare di possedere la chiave privata associata a quella chiave pubblica. Questo è esattamente lo stesso metodo utilizzato per autenticare il server, ma ora l'utente sta provando a dimostrare la sua identità e il server lo sta verificando. Il tentativo di accesso è accettato se l'utente dimostra di conoscere la chiave privata e la chiave pubblica è nell'elenco delle autorizzazioni dell'account ( ~/.ssh/authorized_keys sul server).
• Un altro tipo di metodo implica la delega di parte del lavoro di autenticazione dell'utente al computer client. Ciò accade in ambienti controllati come le imprese, quando molte macchine condividono gli stessi account. Il server autentica la macchina client con lo stesso meccanismo utilizzato al contrario, quindi si affida al client per autenticare l'utente.

Questi due file sono entrambi usati da SSH ma per scopi completamente diversi, che potrebbero facilmente spiegare la tua confusione.

Chiavi autorizzate

Per impostazione predefinita SSH utilizza account utente e password gestiti dal sistema operativo host. (Beh, in realtà è gestito da PAM ma questa distinzione probabilmente non è troppo utile qui.) Ciò significa che quando tu tentare di connettersi a SSH con il nome utente "bob" e alcune password il programma server SSH chiederà al sistema operativo "Ho ricevuto questo ragazzo chiamato 'bob' che mi sta dicendo che la sua password è 'wonka'. Posso lasciarlo entrare?" Se la risposta è sì, allora SSH ti consente di autenticarti e ti metti in cammino.

Oltre alle password, SSH ti consente anche di utilizzare ciò che viene chiamato crittografia a chiave pubblica per identificarti. L'algoritmo di crittografia specifico può variare, ma in genere è RSA o DSA o, più recentemente ECDSA . In ogni caso quando imposti le tue chiavi, utilizzando il programma ssh-keygen , crei due file. Uno che è la tua chiave privata e quella che è la tua chiave pubblica. I nomi sono abbastanza auto-esplicativi. Di progettazione la chiave pubblica può essere disseminata come semi di tarassaco nel vento senza comprometterti. La chiave privata deve essere sempre mantenuta nella massima riservatezza.

Quindi quello che fai è posizionare la tua chiave pubblica nel file authorized_keys . Quindi quando tenti di connetterti a SSH con il nome utente "bob" e la tua chiave privata chiederà al sistema operativo "Ho ricevuto questo nome di ragazzo" bob ", può essere qui?" Se la risposta è sì, SSH controllerà la tua chiave privata e verificherà se la chiave pubblica nel file authorized_keys è la sua coppia. Se entrambe le risposte sono sì, allora sei autorizzato.

Host conosciuti

Molto simile al modo in cui il file authorized_keys viene utilizzato per autenticare gli utenti, il file known_hosts viene utilizzato per autenticare i server. Ogni volta che SSH è configurato su un nuovo server, genera sempre una chiave pubblica e privata per il server, proprio come hai fatto per il tuo utente. Ogni volta che ti connetti a un server SSH, ti mostra la sua chiave pubblica, insieme a una prova che possiede la chiave privata corrispondente. Se non hai la sua chiave pubblica, il tuo computer la chiederà e la aggiungerà nel file known_hosts . Se hai la chiave, e corrisponde, ti connetti subito. Se i tasti non corrispondono, otterrai un avvertimento molto brutto. Questo è dove le cose si fanno interessanti. Le 3 situazioni in cui si verifica tipicamente una mancata corrispondenza di chiave sono:

1. La chiave è cambiata sul server. Ciò potrebbe provenire dalla reinstallazione del sistema operativo o in alcuni sistemi operativi la chiave viene ricreata durante l'aggiornamento di SSH.
2. Il nome host o l'indirizzo IP a cui ci si sta connettendo appartengono a un altro server. Questa potrebbe essere la riassegnazione dell'indirizzo, DHCP o qualcosa di simile.
3. Il maligno attacco man-in-the-middle sta accadendo. Questa è la cosa più importante che il controllo delle chiavi sta cercando di proteggerti.

In entrambi i casi, known_hosts e authorized_keys , il programma SSH utilizza la crittografia a chiave pubblica per identificare il client o il server.

Non vero affatto.

Il file known_hosts contiene l'impronta digitale dell'host. Non è la chiave pubblica o privata dell'host remoto.

Viene generato dalla loro chiave - ma non è assolutamente la chiave stessa.

Se si SFTP a un indirizzo che potrebbe risolversi in diversi (diversi) host (bilanciamento del carico ecc.) è necessario aggiungere le impronte digitali da tutti i possibili punti finali, altrimenti funzionerà inizialmente e poi fallirà quando verrà indirizzato al secondo (o successivo) host.