Autenticazione basata su chiave SSH: known_hosts vs authorized_keys

Ho letto sull'impostazione delle chiavi ssh in Linux e ho alcune domande. Correggimi se sbaglio…

Diciamo che l'host tr-lgto vuole connettersi all'host tr-mdm usando ssh. Se vogliamo essere sicuri che sia il vero tr-mdm, generiamo una coppia di chiavi su tr-mdm e aggiungiamo la chiave pubblica su known_hostssu tr-lgto. Se tr-mdm vuole verificare che sia il vero tr-lgto, allora tr-lgto deve generare una coppia di chiavi e aggiungere la chiave pubblica authorized_keyssu tr-mdm.

Domanda 1 : Non esiste un campo utente nel file known_hosts, solo indirizzi IP e nomi host. tr-mdm potrebbe avere molti utenti, ognuno con la propria .sshcartella. Dovremmo aggiungere la chiave pubblica a ciascuno dei known_hostsfile?

Domanda 2 : ho scoperto che ssh-keyscan -t rsa tr-mdmrestituirà la chiave pubblica di tr-mdm. Come faccio a sapere a quale utente appartiene questa chiave? Inoltre, la chiave pubblica in /root/.ssh/è diversa da ciò che restituisce quel comando. Come può essere?

Stai mescolando l'autenticazione della macchina server alla macchina client e l'autenticazione dell'utente sulla macchina server.

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 che conosce la chiave privata associata. Questo autentica il server: se questa parte del protocollo ha esito positivo, il client sa che il server è chi pretende 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_hostsfile sul computer client (c'è 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 si dispone della chiave pubblica del server a cui si sta per connettersi, è possibile aggiungerla ~/.ssh/known_hostsmanualmente sul client.

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 propria identità e il server li sta verificando. Il tentativo di accesso viene accettato se l'utente dimostra di conoscere la chiave privata e la chiave pubblica si trova nell'elenco di autorizzazioni dell'account ( ~/.ssh/authorized_keyssul 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.

I miei amici mi hanno dato la risposta. Per impostazione predefinita, chiave identifica una macchina e non un utente. Quindi i tasti sono memorizzati in / etc / ssh /. Ecco perché ho ottenuto una chiave diversa da quella memorizzata in /root/.ssh