it-swarm.dev

Qual è la differenza tra file authorized_keys e known_hosts per SSH?

Sto imparando le basi del protocollo SSH. Sono confuso tra i contenuti dei seguenti 2 file:

  1. ~/.ssh/authorized_keys: Contiene un elenco di chiavi pubbliche autorizzate per i server. Quando il client si connette a un server, il server autentica il client controllando la sua chiave pubblica firmata memorizzata in questo file

  2. ~/.ssh/known_hosts: Contiene le chiavi host DSA dei server SSH a cui l'utente accede. Questo file è molto importante per garantire che il client SSH stia collegando il server SSH corretto.

Non sono sicuro di cosa significhi. Per favore aiuto.

190
Ankit

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

Autenticazione del server

Una delle prime cose che si verificano 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 il chiave privata associata. Questo autentica il server: se questa parte del protocollo ha esito positivo, 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 ~/.ssh/known_hosts file sul computer client (esiste anche un file a livello di sistema /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 in realtà la chiave pubblica del server a cui si desidera connettersi. Se disponi della chiave pubblica del server a cui ti connetti, 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 inviare 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 a un utente remoto di accedere solo se tale 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 diverse 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 tale 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 di autorizzazioni dell'account (~/.ssh/authorized_keys sul server).
  • Un altro tipo di metodo prevede 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 il computer 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 è molto 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 "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.

Oltre alle password, SSH ti permetterà anche di usare ciò che viene chiamato 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 programma ssh-keygen , crei due file. Uno che è la tua chiave privata e uno che è la tua chiave pubblica. I nomi sono abbastanza autoesplicativi. In base alla progettazione, la chiave pubblica può essere sparpagliata come semi di tarassaco nel vento senza comprometterti. La chiave privata deve essere sempre mantenuta nella massima riservatezza.

Quindi quello che fai è inserire la tua chiave pubblica nel file authorized_keys. Quindi quando provi a connetterti a SSH con il nome utente 'bob' e la tua chiave privata, ti verrà chiesto al sistema operativo "Ho 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 a entrare.

Host noti

Proprio come 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 le chiavi non corrispondono, riceverai un avvertimento sgradevole. Questo è dove le cose si fanno interessanti. Le 3 situazioni in cui si verifica in genere una mancata corrispondenza dei tasti sono:

  1. La chiave è cambiata sul server. Ciò potrebbe essere dovuto alla reinstallazione di OS o su alcuni sistemi operativi la chiave viene ricreata durante l'aggiornamento di SSH.
  2. Il nome host o l'indirizzo IP a cui ci si connette veniva utilizzato per appartenere a un altro server. Potrebbe essere la riassegnazione dell'indirizzo, DHCP o qualcosa di simile.
  3. Si sta verificando un attacco 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.

37
Scott Pack

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 adattano a "ssh". Questa è una semplificazione eccessiva; ci sono molte più capacità e complicazioni di "ssh" di quelle menzionate qui.

Le associazioni sono in fonti attendibili

Mentre è stato detto che i valori della chiave pubblica "possono essere tranquillamente sparpagliati come semi nel vento", tieni presente che è il giardiniere, non il baccello, a decidere quali semi si stabiliscono nel giardino. Sebbene una chiave pubblica non sia segreta, è necessaria una protezione feroce per preservare l'associazione fidata della chiave con ciò che la chiave sta autenticando. I luoghi incaricati di creare questa associazione includono elenchi "known_hosts", "authorized_keys" 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 più avanti.) Il server e il client hanno ciascuno il proprio elenco di chiavi pubbliche memorizzate in modo sicuro; un accesso avrà esito positivo solo se ciascuna parte è registrata con l'altra.

  • "known_hosts" risiede sul client
  • "authorized_keys" risiede sul server

Il file sicuro del client si chiama "known_hosts" e il file sicuro del server si chiama "authorized_keys". Questi file sono simili in quanto ognuno ha un testo con una chiave pubblica per riga, ma presenta sottili differenze nel formato e nell'uso.

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 si crea 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 server, un'altra per 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", il client doveva fornire una password, ma il server non era stato verificato. La mancanza di controlli ha permesso che si verificassero attacchi "man-in-the-middle", con conseguenze catastrofiche per la sicurezza. Al contrario, nel processo "ssh", il client non restituisce informazioni 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 fare 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 le autorizzazioni per il file "known_hosts" devono essere 600 - nessun altro può scrivere (né leggere).

Una volta autenticato il server, ha la possibilità di sfidare il client. L'autenticazione coinvolgerà una delle chiavi pubbliche che si trovano in "authorized_keys". (Quando nessuna di queste chiavi funziona, il processo "sshd" ricade sull'autenticazione in stile password.)

I formati di file

Quindi per "ssh", come per qualsiasi processo di accesso, ci sono elenchi di "amici", e solo quelli nella lista 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'elenco equivalente di amici è il file "authorized_keys"; ma non ci sono nomi in quel file, poiché le stesse chiavi pubbliche si comportano come identificatori. (Al server non importa da dove provenga il login, ma solo da dove sta andando. Il client sta tentando di accedere a un determinato account, il nome dell'account è stato specificato come parametro quando è stato invocato "ssh". Ricorda che "authorized_keys "il file è specifico per quell'account, poiché il file si trova nella home directory di quell'account.)

Sebbene ci siano molte capacità 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 "known_hosts":

{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" ed "ecdsa". Pertanto, un token diverso potrebbe sostituire ssh-rsa mostrato qui.

Consenti a "ssh" di configurare automaticamente la voce "known_hosts"

In entrambi i casi, se la chiave pubblica non viene trovata in un file sicuro, la crittografia assimetrica non viene eseguita. Come accennato in precedenza, esiste un'eccezione a questa regola. A un utente è consentito 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" avvisa l'utente, ma se l'utente sceglie di andare avanti, il client "ssh" gli consente "solo una volta". Per garantire che ciò avvenga una sola volta, il processo "ssh" configura automaticamente il file "known_hosts" con le informazioni richieste chiedendo al server la chiave pubblica e quindi scrivendole 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. Ovviamente, il metodo corretto e sicuro sarebbe stato quello di inserire manualmente una riga con nome server e chiave pubblica nel file "known_hosts" 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 "known_hosts" del client ha il nome di un server e una chiave pubblica applicabile al computer server. Il server ha una singola chiave privata utilizzata per rispondere a tutte le sfide e la voce "known_hosts" del client deve avere la chiave pubblica corrispondente. Pertanto, tutti i client che accedono a un determinato server avranno la stessa 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" del client.

Una voce nel file "authorized_keys" identifica che un cliente amico può 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 dovrebbe avere la stessa 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ù macchine client replicheranno la stessa coppia di chiavi; in genere ciò avviene quando un utente lavora su un desktop e un laptop. Poiché i computer client eseguono l'autenticazione con chiavi identiche, corrisponderanno alla stessa voce in "authorized_keys" del server.

Posizione delle chiavi private

Per il lato server, un processo di sistema o un demone, gestisce tutte le richieste di accesso "ssh" in arrivo. Il demone si chiama "sshd". Il percorso della chiave privata dipende dall'installazione SSL, ad esempio Apple lo mette in /System/Library/OpenSSL, ma dopo aver installato la tua versione di OpenSSL, il percorso sarà /opt/local/etc/openssl.

Per il lato client, invoca "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 viene spesso chiamata $HOME/.ssh/id_rsa e $HOME/.ssh/id_rsa.pub.

Sommario

La linea di fondo è che sia "known_hosts" che "authorized_keys" contengono chiavi pubbliche, ma ...

  • known_hosts: il client verifica se l'host è autentico
  • authorized_keys: l'host verifica se l'accesso client è consentito
1
IAM_AL_X