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 il server autentica lutente.

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 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 il client sa che il server è chi afferma di essere.

Il client può controllare che il server sia conosciuto e non un server canaglia cercando di spacciarsi per 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 sulla macchina client (cè anche un sistema -wide file /etc/ssh/known_hosts). La prima volta che ti connetti a un server, devi controllare con altri mezzi 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 stai per connetterti, puoi aggiungerla a ~/.ssh/known_hosts sul client manualmente.

A proposito, known_hosts può contenere qualsiasi tipo di chiave pubblica supportata dallimplementazione SSH, non solo DSA (anche RSA ed ECDSA).

Autenticazione del deve essere eseguito prima di inviargli dati riservati. In particolare, se lautenticazione dellutente implica una password, la password non deve essere inviata a un server non autenticato.

Autenticazione dellutente

Il server consente a un utente remoto di accedere solo se quellutente può dimostrare di avere il diritto di accedere a tale account. A seconda della configurazione del server e della scelta dellutente, lutente può presentare una delle diverse forme di credenziali (lelenco seguente non è esaustivo).

• Lutente può presentare la password per laccount a cui sta tentando di accedere; il server quindi verifica che la password sia corretta.
• Lutente 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 lutente sta cercando di dimostrare la sua identità e il server la sta verificando. Il tentativo di accesso viene accettato se lutente dimostra di conoscere la chiave privata e che la chiave pubblica si trova nellelenco di autorizzazioni dellaccount (~/.ssh/authorized_keys sul server).
• Un altro tipo di metodo prevede la delega di parte del lavoro di autenticazione dellutente alla macchina 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 che è usato al contrario, quindi si affida al client per autenticare lutente.

Commenti

• grazie è molto utile. è giusto dire che il file known_hosts è mantenuto sul client mentre il file authorized_key è mantenuto sul server
• @Ankit Sì, questo è il caso.
• Ho entrambi i file sul server e ssh per testarlo. Ma i 2 file hanno contenuti diversi. Quindi le chiavi sono diverse in questi file?
• @Timo Le chiavi sono completamente unr euforico. Una è la chiave di una macchina, laltra è la chiave di un utente.
• @Gilles Quindi una volta aggiunta la voce per la chiave pubblica di un server ‘ al file known_hosts nella macchina ‘ del client, qualsiasi successiva sessione ssh tra i due non ‘ richiedere al server di dimostrare di avere la chiave privata corretta?

Questi due file sono utilizzati entrambi 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, effettivamente gestito da PAM ma questa distinzione probabilmente non è molto utile qui.) Ciò significa che quando tenti di connetterti a SSH con il nome utente “bob” e un po di password il programma del server SSH chiederà al sistema operativo ” Ho trovato questo tipo di nome “bob” che mi dice che la sua password è “wonka”. Posso farlo entrare? ” Se la risposta è sì, SSH ti consente di autenticarti e vai per la tua strada.

Oltre alle password SSH ti consentirà anche di utilizzare quella “s chiamata crittografia a chiave pubblica per identificarti. Lalgoritmo di crittografia specifico può variare, ma di solito è RSA o DSA o, più recentemente, ECDSA . In ogni caso, quando imposti le chiavi, utilizzando ssh-keygen , crei due file. Uno che è la tua chiave privata e uno che è la tua chiave pubblica. I nomi sono abbastanza autonomi -spiegativo. In base alla progettazione, la chiave pubblica può essere sparpagliata come semi di tarassaco al vento senza comprometterti. La chiave privata dovrebbe essere sempre mantenuta con la massima riservatezza.

Quindi ciò che fai è posizionare il tuo pubblico digitare il file authorized_keys. Quindi, quando si tenta di connettersi a SSH con il nome utente “bob” e la tua chiave privata chiederà al sistema operativo ” Ho il nome di questo ragazzo “bob”, può essere qui? ” Se la risposta è sì, allora SSH ispezionerà la tua chiave privata e verificherà se la chiave pubblica nel file authorized_keys è la sua coppia. Se entrambe le risposte sono affermative, allora sei autorizzato ad entrare.

Host noti

In modo molto simile a come viene utilizzato il file authorized_keys per autenticare gli utenti il file known_hosts viene utilizzato per autenticare i server. Ogni volta che SSH viene 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 te la richiederà e la aggiungerà al file known_hosts. Se hai la chiave e corrisponde, ti connetti subito. Se le chiavi non corrispondono, viene visualizzato un brutto avvertimento. È qui che le cose si fanno interessanti. Le 3 situazioni in cui si verifica tipicamente una mancata corrispondenza della chiave sono:

1. La chiave è stata modificata sul server. Potrebbe essere dovuto alla reinstallazione del OS o su alcuni sistemi operativi la chiave viene ricreata durante laggiornamento di SSH.
2. Il nome host o lindirizzo IP che stai collegando apparteneva a un server diverso. Potrebbe trattarsi di riassegnazione dellindirizzo, DHCP o qualcosa di simile.
3. Malicious man- è in corso un attacco 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.

Commenti

• ” Ogni volta che ti connetti a un server SSH, presenta la sua chiave privata per provare la sua identità. ” Spero di no! Presumo che tu intendessi la sua chiave pubblica . Se un server mi presentasse, il client, con la sua chiave privata, (A) non ‘ funzionerebbe per me per lautenticazione e (B) è unindicazione che il server è così configurato male che dovrei smettere immediatamente di fare affari con esso. Le chiavi private dovrebbero essere accessibili sulla macchina di origine solo da utenti designati. Questo è ‘ un po il punto. 😉
• Questa risposta mi ha aiutato più di quella accettata (:
• Se eseguo ssh su un server locale (IP locale), e successivamente dallo stesso computer ma ora da remoto connettersi allo stesso server (IP pubblico) attiverà chiavi non corrispondenti? Come puoi mitigarlo?

Informazioni sui file protetti che contengono chiavi pubbliche

Per aiutarti a capire in che modo “known_hosts” e “authorized_keys” sono diversi, ecco un contesto che spiega come quei file si adattano a “ssh”. Questa è una semplificazione eccessiva ci sono molte più capacità e complicazioni in “ssh” di quelle menzionate qui.

Le associazioni sono in fonti attendibili

Anche se è stato detto che i valori di chiave pubblica “possono essere tranquillamente sparsi come semi al vento”, tieni presente che “è il Gardner, non il baccello del seme, che decide quali semi vengono piantati nel giardino. Sebbene una chiave pubblica non sia segreta, è necessaria una protezione feroce per preservare lassociazione fidata della chiave con loggetto che la chiave sta autenticando. I luoghi incaricato di fare in modo che questa associazione includa gli 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 protetto appropriato (questa verità generale ha unimportante eccezione, che verrà discussa in seguito). Il server e il client hanno ciascuno il proprio, archiviato in modo sicuro elenco di chiavi pubbliche; un accesso avrà successo solo se ogni lato è registrato con laltro.

• “known_hosts” risiede sul clie nt
• “authorized_keys” risiede sul server

Il file protetto del client si chiama “known_hosts”, e il file protetto del server è chiamato “authorized_keys” . Questi file sono simili in quanto ognuno ha testo con una chiave pubblica per riga, ma presentano sottili differenze di formato e utilizzo.

Le coppie di chiavi vengono utilizzate per lautenticazione

-la coppia di chiavi private viene utilizzata per eseguire la “crittografia asimmetrica”. Il programma “ssh” può utilizzare la crittografia asimmetrica per lautenticazione, in cui unentità deve rispondere a una sfida per dimostrare la propria identità. La sfida viene creata codificando con una chiave e risolta decodificando con laltra chiave. (Si noti che la crittografia asimmetrica viene utilizzata solo durante la fase di accesso; quindi “ssh” (TSL / SSL) passa a unaltra forma di crittografia per gestire il flusso di dati.)

Una coppia di chiavi per Server, unaltra per Client

In “ssh”, entrambe le parti (client e server) sospettano luna dellaltra; questo è un miglioramento rispetto al predecessore di “ssh”, che era “telnet”. Con “telnet”, il client doveva fornire una password, ma il server non è stato controllato. La mancanza di controlli ha consentito il verificarsi di attacchi “man-in-the-middle”, con conseguenze catastrofiche per la sicurezza. Al contrario, nel processo “ssh”, il client non restituisce alcuna informazione finché il server non risponde prima a una sfida.

I passaggi nellautenticazione “ssh”

Prima di condividere qualsiasi informazione di accesso, il client “ssh” elimina innanzitutto lopportunità di un attacco man-in-the-middle sfidando il server a dimostrare “Sei davvero quello che 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 è sulla stessa riga, dopo il nome del server. Lassociazione tra nome-server e chiave pubblica deve essere mantenuta inviolata; pertanto i permessi su il file “known_hosts” deve essere 600 – nessun altro può scrivere (né leggere).

Una volta che il server si è autenticato, ha la possibilità di sfidare il client. Lautenticazione coinvolgerà uno degli utenti pubblici- chiavi trovate in “authorized_keys”. (Quando nessuna di queste chiavi funziona, il processo “sshd” ricorre allautenticazione in stile password.)

I formati di file

Quindi per ” ssh “, come con qualsiasi processo di accesso, ci sono elenchi di” amici “e solo quelli nellelenco possono tentare di superare una sfida. Per il client, il file” known_hosts “è un elenco di amici che possono agire come server (host); questi sono elencati per nome. Per il server, lelenco equivalente di amici è il file “authorized_keys”; ma non ci sono nomi in quel file, poiché il publi Le chiavi c 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 dellaccount è stato specificato come parametro quando è stato invocato “ssh”. Ricorda che il Il file “authorized_keys” è specifico per quellaccount, poiché il file si trova nella directory home di quellaccount.)

Sebbene ci siano molte funzionalità che possono essere espresse in una voce di configurazione, lutilizzo di base più comune ha i seguenti parametri. Tieni presente 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} 

Tieni presente che il token ssh-rsa indica che lalgoritmo utilizzato per la codifica è “rsa”. Altri algoritmi validi includere “dsa” e “ecdsa”. Pertanto, un token diverso potrebbe sostituire il ssh-rsa mostrato qui.

Consenti a “ssh” di configurare automaticamente il Voce “known_hosts”

In entrambi i casi, se th La chiave pubblica non viene trovata allinterno di un file protetto, quindi la crittografia asimmetrica non viene eseguita. Come accennato in precedenza, esiste uneccezione 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 “s” known_hosts “dellutente. Il programma” ssh “avverte lutente, ma se lutente sceglie di andare avanti, il client “ssh” lo consente “solo 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 public-key, e poi scrivendolo nel file “known_hosts”. Questa eccezione sovverte totalmente la sicurezza consentendo allavversario di fornire lassociazione di un nome-server con una chiave pubblica. Questo rischio per la sicurezza è consentito perché rende le cose così tante più facile 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 “s” known_hosts “del client ha il nome di un server e una chiave pubblica applicabile alla macchina server. Il server ha una singola chiave privata che viene 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 voce nel loro file “known_hosts”. La relazione 1: N è che la chiave pubblica di un server può apparire nei file “known_hosts” di molti client.

Una voce nel file “authorized_keys” identifica che un cliente amichevole è autorizzato ad accedere allaccount. Lamico 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 server di destinazione avrebbe la stessa voce di chiave pubblica nei 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 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 nel server “s” authorized_keys “.

Posizione delle chiavi private

Per il lato server, un processo di sistema , o daemon, gestisce tutte le richieste di accesso “ssh” in arrivo. Il daemon si chiama “sshd”. La posizione della chiave privata dipende dallinstallazione SSL, ad esempio Apple la inserisce 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 tua riga di comando includerà vari parametri, uno dei quali può opzionalmente specificare quale chiave privata usare. Per impostazione predefinita, la coppia di chiavi lato client viene spesso chiamata $HOME/.ssh/id_rsa e $HOME/.ssh/id_rsa.pub.

Riepilogo

La conclusione è che sia “known_hosts” che “authorized_keys” contengono chiavi pubbliche, ma …

• known_hosts – il client controlla se lhost è autentico
• authorized_keys – lhost controlla se laccesso del client è consentito

Commenti

• I client SSH di solito non ‘ non ha chiavi. Le chiavi pubbliche elencate in authorized_keys identificano gli utenti, non le macchine.
• Grazie. Questa è una spiegazione molto chiara e facilmente comprensibile delle relazioni tra i file e le chiavi.

Per niente vero.

Il file known_hosts contiene limpronta digitale dellhost. Non è la chiave pubblica o privata dellhost remoto.

Viene generata dalla loro chiave, ma chiaramente NON è la chiave stessa.

Se esegui lSFTP su un indirizzo che potrebbe risolversi in diversi host (variabili) (bilanciamento del carico ecc.) È necessario aggiungere le impronte digitali da tutti i possibili punti finali, altrimenti funzionerà inizialmente e poi fallirà quando viene indirizzato al secondo (o successivo) host.

Commenti

• erm guarda il tuo file known_hosts e confrontalo con limpronta digitale di un host quando ti connetti … Questo dovrebbe chiarirlo un po . Inoltre, il tuo esempio sarebbe esattamente lo stesso, indipendentemente dal fatto che si tratti di impronte digitali o chiavi pubbliche nel file known_hosts.