Il known_hosts file consente al client di autenticare il server, per verificare che non si stia connettendo a un imitatore. Il authorized_keys consente al server di autenticare l'utente.
Autenticazione del 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 alla crittografia a chiave pubblica) al client di conoscere 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 cerca di spacciarsi per quello giusto. SSH fornisce solo un semplice meccanismo per verificare la legittimità del server:ricorda i server a cui ti sei già connesso, nel ~/.ssh/known_hosts file sulla macchina client (c'è anche un file a livello di sistema /etc/ssh/known_hosts ). La prima volta che ti connetti a un server, devi verificare in qualche altro modo che la chiave pubblica presentata dal server sia realmente la chiave pubblica del server a cui desideri connetterti. Se hai la chiave pubblica del server a cui ti stai per connettere, puoi aggiungerla a ~/.ssh/known_hosts sul client manualmente.
A proposito, known_hosts può contenere qualsiasi tipo di chiave pubblica supportata dall'implementazione SSH, non solo DSA (anche RSA ed ECDSA).
L'autenticazione del server deve essere eseguita prima di inviargli dati riservati. In particolare, se l'autenticazione dell'utente prevede una password, la password non deve essere inviata a un server non autenticato.
Autenticazione utente
Il server consente a un utente remoto di accedere solo se quell'utente può dimostrare di avere il diritto di accedere a quell'account. A seconda della configurazione del server e della scelta dell'utente, l'utente può presentare una delle diverse forme di credenziali (l'elenco seguente non è esaustivo).
- L'utente può presentare la password dell'account a cui sta tentando di accedere; il server quindi verifica 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 cercando di dimostrare la sua identità e il server lo sta verificando. Il tentativo di accesso viene accettato se l'utente dimostra di conoscere la chiave privata e la chiave pubblica è nell'elenco di autorizzazione dell'account (
~/.ssh/authorized_keyssul server). - Un altro tipo di metodo comporta la delega di parte del lavoro di autenticazione dell'utente al computer client. Ciò accade in ambienti controllati come le aziende, 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, il che potrebbe 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 si tenta di connettersi a SSH con il nome utente "bob" e una password, il programma del server SSH chiederà al sistema operativo "I Ho questo tizio di nome 'bob' che mi sta dicendo che la sua password è 'wonka'. Posso farlo entrare?" Se la risposta è sì, allora SSH ti consente di autenticarti e vai per la tua strada allegra.
Oltre alle password, SSH ti consentirà anche di utilizzare la cosiddetta crittografia a chiave pubblica per identificarti. L'algoritmo di crittografia specifico può variare, ma di solito è RSA o DSA o, più recentemente, ECDSA. In ogni caso quando imposti le tue chiavi, usando il ssh-keygen programma, si creano due file. Una che è la tua chiave privata e una che è la tua chiave pubblica. I nomi sono abbastanza autoesplicativi. In base alla progettazione, la chiave pubblica può essere sparsa come semi di tarassaco al vento senza comprometterti. La chiave privata deve essere sempre mantenuta con la massima riservatezza.
Quindi quello che fai è inserire la tua chiave pubblica in authorized_keys file. Quindi, quando tenti di connetterti a SSH con il nome utente "bob" e la tua chiave privata, verrà chiesto al sistema operativo "Ho questo ragazzo di nome 'bob', può essere qui?" Se la risposta è sì allora SSH ispezionerà la tua chiave privata e verificherà se la chiave pubblica nel authorized_keys file è la sua coppia. Se entrambe le risposte sono sì, sei autorizzato a entrare.
Host conosciuti
Proprio come il authorized_keys viene utilizzato per autenticare gli utenti known_hosts file 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 richiederà e la aggiungerà al known_hosts file. Se hai la chiave e corrisponde, ti connetti subito. Se le chiavi non corrispondono, ricevi un brutto avvertimento. È qui che le cose si fanno interessanti. Le 3 situazioni in cui si verifica tipicamente una mancata corrispondenza di chiavi sono:
- La chiave è cambiata sul server. Ciò potrebbe derivare dalla reinstallazione del sistema operativo o su alcuni sistemi operativi la chiave viene ricreata durante l'aggiornamento di SSH.
- Il nome host o l'indirizzo IP a cui ti stai connettendo apparteneva a un altro server. Potrebbe trattarsi di riassegnazione dell'indirizzo, DHCP o qualcosa di simile.
- Si sta verificando un dannoso attacco man-in-the-middle. Questa è la cosa più importante da cui 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.
Informazioni sui file protetti contenenti chiavi pubbliche
Per aiutarti a capire in che modo "known_hosts" e "authorized_keys" sono diversi, ecco un contesto che spiega come questi file si inseriscono in "ssh". Questa è una semplificazione eccessiva; ci sono molte più possibilità e complicazioni in "ssh" di quelle menzionate qui.
Le associazioni sono in fonti attendibili
Mentre è stato detto che i valori della chiave pubblica "possono essere tranquillamente sparsi come semi al vento", tieni presente che è il giardiniere, non il baccello del seme, che decide quali semi si stabiliscono nel giardino. Sebbene una chiave pubblica non sia segreta, è necessaria una feroce protezione per preservare l'associazione fidata della chiave con la cosa che la chiave sta autenticando. I luoghi incaricati di creare questa associazione includono elenchi di "host_noti", "chiavi_autorizzate" e "autorità di certificazione".
Le fonti attendibili utilizzate da "ssh"
Affinché una chiave pubblica sia rilevante per "ssh", la chiave deve essere registrata in anticipo e archiviata nel file sicuro appropriato. (Questa verità generale ha un'importante eccezione, che verrà discussa in seguito.) Il server e il client hanno ciascuno il proprio elenco di chiavi pubbliche memorizzato in modo sicuro; un login avrà successo solo se ciascuna parte è registrata con l'altra.
- "known_hosts" risiede sul client
- "authorized_keys" risiede sul server
Il file sicuro del client è chiamato "host_noti" e il file sicuro del server è chiamato "chiavi_autorizzate". Questi file sono simili in quanto ognuno ha un testo con una chiave pubblica per riga, ma presentano sottili differenze nel formato e nell'utilizzo.
Le coppie di chiavi vengono utilizzate per l'autenticazione
Una coppia di chiavi pubblica-privata viene utilizzata per eseguire la "crittografia asimmetrica". Il programma "ssh" può utilizzare la crittografia asimmetrica per l'autenticazione, in cui un'entità deve rispondere a una sfida per dimostrare la propria identità. La sfida viene creata codificando con una chiave e si risponde decodificando con l'altra chiave. (Si noti che la crittografia asimmetrica viene utilizzata solo durante la fase di accesso; quindi "ssh" (TSL/SSL) passa a un'altra forma di crittografia per gestire il flusso di dati.)
Una coppia di chiavi per il server, un'altra per il client
In "ssh", entrambe le parti (client e server) sono sospettose dell'altra; questo è un miglioramento rispetto al predecessore di "ssh", che era "telnet". Con "telnet", al client veniva richiesto di fornire una password, ma il server non veniva controllato. La mancanza di controllo ha consentito il verificarsi di attacchi "man-in-the-middle", con conseguenze catastrofiche per la sicurezza. Al contrario, nel processo "ssh", il client non fornisce alcuna informazione fino a quando il server non risponde prima a una sfida.
I passaggi dell'autenticazione "ssh"
Prima di condividere qualsiasi informazione di accesso, il client "ssh" elimina innanzitutto l'opportunità di un attacco man-in-the-middle sfidando il server a dimostrare "Sei davvero chi penso di essere?" Per affrontare questa sfida, il client deve conoscere la chiave pubblica associata al server di destinazione. Il client deve trovare il nome del server nel file "known_hosts"; la chiave pubblica associata si trova sulla stessa riga, dopo il nome del server. L'associazione tra nome-server e chiave-pubblica deve essere mantenuta inviolata; pertanto i permessi sul file "known_hosts" devono essere 600 -- nessun altro può scrivere (né leggere).
Una volta che il server si è autenticato, ha la possibilità di sfidare il client. L'autenticazione coinvolgerà una delle chiavi pubbliche trovate nelle "authorized_keys". (Quando nessuna di queste chiavi funziona, il processo "sshd" ricorre all'autenticazione in stile password.)
I formati dei file
Quindi per "ssh", come con qualsiasi processo di accesso, ci sono elenchi di "amici" e solo quelli nell'elenco possono tentare di superare una sfida. Per il client, il file "known_hosts" è un elenco di amici che possono fungere da server (host); questi sono elencati per nome. Per il server, l'equivalente elenco di amici è il file "authorized_keys"; ma non ci sono nomi in quel file, poiché le chiavi pubbliche stesse agiscono come identificatori. (Al server non importa da dove provenga il login, ma solo dove sta andando. Il client sta tentando di accedere a un particolare account, il nome dell'account è stato specificato come parametro quando è stato invocato "ssh". Ricorda che "authorized_keys " è specifico per quell'account, poiché il file si trova nella home directory di quell'account.)
Sebbene ci siano molte funzionalità che possono essere espresse in una voce di configurazione, l'utilizzo di base più comune ha i seguenti parametri. Si noti che i parametri sono separati da spazi.
Per "host_noti":
{server-id} ssh-rsa {public-key-string} {comment}
Per "authorized_keys":
ssh-rsa {public-key-string} {comment}
Nota che il token ssh-rsa indica che l'algoritmo utilizzato per la codifica è "rsa". Altri algoritmi validi includono "dsa" e "ecdsa". Pertanto, un token diverso potrebbe prendere il posto del ssh-rsa mostrato qui.
Lascia che "ssh" configuri automaticamente la voce "known_hosts"
In entrambi i casi, se la chiave pubblica non viene trovata all'interno di un file protetto, la crittografia asimmetrica non avviene. Come accennato in precedenza, c'è un'eccezione a questa regola. Un utente può scegliere consapevolmente di rischiare la possibilità di un attacco man-in-the-middle accedendo a un server che non è elencato nel file "known_hosts" dell'utente. Il programma "ssh" avverte l'utente, ma se l'utente sceglie di andare avanti, il client "ssh" lo consente "solo per questa volta". Per garantire che accada solo una volta, il processo "ssh" configura automaticamente il file "known_hosts" con le informazioni richieste chiedendo al server la chiave pubblica e quindi scrivendola nel file "known_hosts". Questa eccezione sovverte totalmente la sicurezza consentendo all'avversario di fornire l'associazione di un nome server con una chiave pubblica. Questo rischio per la sicurezza è consentito perché rende le cose molto più facili per così tante persone. Naturalmente, il metodo corretto e sicuro sarebbe stato che l'utente inserisse manualmente una riga con il nome del server e la chiave pubblica nel file "host_noti" prima di tentare di accedere al server. (Ma per situazioni a basso rischio, il lavoro extra potrebbe essere inutile.)
Le relazioni uno-a-molti
Una voce nel file "host_noti" del client ha il nome di un server e una chiave pubblica applicabile alla macchina server. Il server ha un'unica chiave privata che viene utilizzata per rispondere a tutte le sfide e la voce "host_noti" del client deve avere la chiave pubblica corrispondente. Pertanto, tutti i client che accedono a un determinato server avranno la stessa voce di chiave pubblica nel loro file "known_hosts". La relazione 1:N è che la chiave pubblica di un server può apparire in molti file "known_hosts" di molti client.
Una voce nel file "authorized_keys" identifica che un cliente amichevole è autorizzato ad accedere all'account. L'amico potrebbe utilizzare la stessa coppia di chiavi pubblica-privata per accedere a più server diversi. Ciò consente a una singola coppia di chiavi di autenticarsi su tutti i server mai contattati. Ciascuno degli account del server di destinazione avrebbe la stessa voce di chiave pubblica nei propri file "authorized_keys". La relazione 1:N è che la chiave pubblica di un client può apparire nei file "authorized_keys" per più account su più server.
A volte, gli utenti che lavorano da più computer client replicheranno la stessa coppia di chiavi; in genere questo viene fatto quando un utente lavora su un desktop e un laptop. Poiché le macchine client si autenticano con chiavi identiche, corrisponderanno alla stessa voce nelle "chiavi_autorizzate" del server.
Posizione delle chiavi private
Per il lato server, un processo di sistema, o demone, gestisce tutte le richieste di accesso "ssh" in entrata. Il demone si chiama "sshd". La posizione della chiave privata dipende dall'installazione SSL, ad esempio Apple la inserisce in /System/Library/OpenSSL , ma dopo aver installato la tua versione di OpenSSL, la posizione sarà /opt/local/etc/openssl .
Per il lato client, invochi "ssh" (o "scp") quando ne hai bisogno. La riga di comando includerà vari parametri, uno dei quali può facoltativamente specificare quale chiave privata utilizzare. Per impostazione predefinita, la coppia di chiavi lato client è spesso chiamata $HOME/.ssh/id_rsa e $HOME/.ssh/id_rsa.pub .
Riepilogo
In conclusione, sia "known_hosts" che "authorized_keys" contengono chiavi pubbliche, ma...
- host_noti:il client controlla se l'host è autentico
- authorized_keys -- l'host verifica se l'accesso al client è consentito