Utilizzo delle coppie di chiavi SSH

Comprendere il modo in cui le chiavi pubbliche e private consentono l'autenticazione SSH sicura e senza password.

Per utilizzare l'autenticazione delle chiavi, è innanzitutto necessario disporre di una coppia di chiavi: una chiave pubblica e una chiave privata corrispondente. È possibile utilizzare una coppia di chiavi esistente o generarne una nuova. In genere, è possibile generare una coppia di chiavi SSH una sola volta e modificare la coppia di chiavi solo se potrebbe essere stata compromessa o se si utilizza una chiave per accedere a sistemi con standard di cifratura diversi. Non tutte le coppie di chiavi sono compatibili con OpenSSH e potrebbe essere necessario convertire le chiavi come richiesto. Ad esempio, le chiavi generate con il client SSH PuTTY non sono direttamente compatibili con OpenSSH e potrebbero dover essere convertite prima dell'uso. Se non si è sicuri del formato della chiave, consultare la documentazione del software del client.

Dopo aver ottenuto una coppia di chiavi, copiare la chiave pubblica su qualsiasi server a cui si desidera connettersi. Quindi, per connettersi al server, fornire la chiave privata corrispondente. È possibile memorizzare la chiave privata su un singolo client utilizzato per accedere ai server. Per motivi di sicurezza, evitare di copiare la chiave privata in più posizioni.

Quando si generano coppie di chiavi, è possibile configurarle per avere o meno una password. Le coppie di chiavi che non hanno passphrase possono aiutare con l'automazione scripted in quanto possono accedere istantaneamente ai sistemi remoti in modo da non dover inserire la passphrase ogni volta che ci si connette. Tuttavia, l'uso di una chiave senza passphrase può essere una pratica di sicurezza scadente. In alternativa, è possibile utilizzare Agente SSH per ricordare una passphrase chiave per l'intera sessione di login.

Prendere in considerazione l'utilizzo di SSH Agent Forwarding per connettersi tra sistemi sicuri oppure utilizzare l'opzione del comando ProxyJump, in cui potrebbe essere necessario connettersi a un altro sistema tramite un host bastion non attendibile o fortemente condiviso.

Creare nuove coppie di chiavi SSH con ssh-keygen e scegliere algoritmi e posizioni.

Utilizzare il comando ssh-keygen per generare una coppia di chiavi di autenticazione pubblica e privata. Le chiavi di autenticazione consentono di connettersi a un sistema remoto senza dover fornire una password a ogni connessione. Ogni utente deve generare la propria coppia di chiavi.

ssh-keygen

ls -l $HOME/.ssh

...
-rw-------. 1 guest guest 1743 Apr 13 12:07 id_sshkey
-rw-r--r--. 1 guest guest  397 Apr 13 12:07 id_sshkey.pub
...

Configurare l'autenticazione basata su chiavi in modo che le connessioni automatiche possano procedere senza una passphrase.

È possibile creare una coppia di chiavi che non richieda una passphrase, utile per gli ambienti con script in cui uno strumento potrebbe richiedere l'accesso SSH a un sistema remoto ma non richiedere una passphrase.

Per uso generale, e come procedura migliore, impostare una passphrase sulla chiave privata e quindi utilizzare l'agente SSH per ricordare le passphrase della chiave per l'intera sessione di login. Per ulteriori informazioni, vedere Utilizzo dell'agente chiave SSH per ricordare le passphrase.

Tuttavia, l'utilizzo dell'agente SSH non è sempre pratico e per alcuni servizi caricati al momento del boot potrebbe essere necessario creare una chiave che non utilizzi una passphrase.

Per utilizzare le utility OpenSSH per accedere a un sistema remoto senza fornire una password ogni volta che si esegue la connessione, effettuare le operazioni riportate di seguito.

1. Utilizzare ssh-keygen per generare una coppia di chiavi pubblica e privata, ad esempio:

   ssh-keygen

   L'output del comando è simile all'output di esempio seguente.

   ...
   Enter file in which to save the key (/home/user/.ssh/id_sshkey): <Enter>
   Created directory '/home/user/.ssh'.
   Enter passphrase (empty for no passphrase): <Enter>
   Enter same passphrase again: <Enter>
   ...

   Premere Enter per ogni prompt della passphrase.

2. Copiare la chiave pubblica nel server remoto. Vedere Copiare la chiave pubblica sul server remoto.

3. Se i nomi utente sono diversi sul client e sui server, creare una voce per il file $HOME/.ssh/config per questa connessione. Vedere Impostazione delle opzioni di configurazione del client SSH per un host.

4. Verificare che le autorizzazioni per i file di configurazione $HOME/.ssh siano corrette sul lato server e client. Per ulteriori informazioni, vedere Convalida delle autorizzazioni di configurazione.

5. Per accedere al sistema remoto senza fornire una password, utilizzare ssh per accedere al sistema remoto e verificare che il file $HOME/.ssh/authorized_keys contenga solo le chiavi dei sistemi da cui ci si aspetta di connettersi, ad esempio:

   ssh remote_user@host

Se il nome del file chiave non è standard, è possibile specificare il file chiave da utilizzare utilizzando l'opzione -i quando si esegue la connessione:

ssh -i $HOME/.ssh/my_private_key remote_user@host

Per ulteriori informazioni, vedere le pagine del manuale ssh-copy-id(1), ssh-keygen(1) e ssh_config(5).

Aggiungere la chiave pubblica agli host remoti utilizzando ssh-copy-id o aggiornamenti manuali.

Aggiungere la chiave pubblica al file server remoto all'indirizzo $HOME/.ssh/authorized_keys. Sono disponibili vari approcci per l'impostazione del contenuto di questo file. È possibile eseguire ssh-copy-id o configurare manualmente il file, come mostrato nelle sezioni seguenti.

Memorizzare le chiavi SSH autorizzate nei servizi di identità centralizzati gestiti da SSSD.

Se è necessario gestire più utenti su sistemi diversi, è possibile centralizzare lo storage delle chiavi autorizzate. La gestione di una singola risorsa centrale per le chiavi_autorizzate semplifica l'esecuzione di attività di amministrazione, ad esempio la revoca di vecchie chiavi o l'aggiunta di nuove chiavi per set di server.

Un approccio comune prevede la configurazione del server SSH per utilizzare il daemon dei servizi di sicurezza del sistema per accedere alle chiavi memorizzate in una posizione centrale, ad esempio un servizio LDAP o Identity Management (IPA). Per configurare l'autenticazione utente per questi servizi, vedere uno dei collegamenti riportati di seguito.

• Oracle Linux 8: impostazione degli utenti e dell'autenticazione del sistema

• Oracle Linux 9: impostazione degli utenti e dell'autenticazione del sistema

• Oracle Linux 10: impostazione degli utenti e dell'autenticazione del sistema

OpenSSH fornisce uno strumento per utilizzare SSSD per mantenere e aggiornare automaticamente una cache separata di chiavi pubbliche durante l'autenticazione degli utenti. Il comando sss_ssh_authorizedkeys è responsabile del recupero della chiave pubblica di un utente dalle voci utente in un dominio IPA (Identity Management). Una volta recuperata la chiave, essa viene memorizzata nel file $HOME/.ssh/sss_authorized_keys, nel formato standard delle chiavi autorizzate.

Per configurare il server SSH in modo che utilizzi SSSD per recuperare le chiavi pubbliche per gli utenti, modificare /etc/ssh/sshd_config e verificare che siano presenti le voci seguenti:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

Dopo aver modificato la configurazione del server, riavviare il servizio:

sudo systemctl restart sshd

SSSD deve essere già configurato e in esecuzione e le chiavi devono essere memorizzate in modo appropriato in modo che SSH possa utilizzare il servizio.

Per ulteriori informazioni, consultare la pagina del manuale sss_ssh_authorizedkeys(1).

Gestire le impronte digitali della chiave host in $HOME/.ssh/known_hosts per verificare l'identità del server.

Ogni volta che ci si connette a un host remoto, il server SSH sull'host remoto fornisce una chiave pubblica. È possibile utilizzare questa chiave per verificare che in futuro si stia effettuando la connessione allo stesso host per evitare attacchi MITM (man-in-the-middle). Sul lato server, questa chiave pubblica viene memorizzata come parte della coppia HostKey. Nel sistema client, il database known_hosts memorizza la chiave pubblica per l'host nel file $HOME/.ssh/known_hosts.

Impronte digitali chiave host SSH da sistemi remoti

Quando ci si connette a un sistema remoto e il database known_hosts non contiene una chiave, il client chiede di accettare l'impronta digitale della chiave. Ad esempio:

The authenticity of host 'server1.example.com (198.51.100.172)' can't be established.
ED25519 key fingerprint is SHA256:i45KP8BeY5c6nO87hjUrqo1fXsGgQkCpA5dHchXBWbk.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Se si accetta l'impronta digitale, il file $HOME/.ssh/known_hosts memorizza la chiave pubblica nel sistema client e non viene più richiesta ogni volta che ci si connette.

Lista delle impronte digitali della chiave in known_hosts locali

È possibile elencare le impronte digitali per le chiavi memorizzate nel database known_hosts eseguendo:

ssh-keygen -l -f $HOME/.ssh/known_hosts

Controllo chiave host rigoroso

Se l'opzione StrictHostKeyChecking del client OpenSSH è impostata per impostazione predefinita e la chiave pubblica restituita dal server viene modificata, non è possibile connettersi al server remoto e viene visualizzata un'avvertenza:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ED25519 host key for server1.example.com has changed,
and the key for the corresponding IP address 198.51.100.172
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/user/.ssh/known_hosts:20
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:qMBpuwP/LXLV8F5awaYtbXHO8v7LrqyY2BwVZk7tDxY.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:125
ED25519 host key for server1.example.com has changed and you have requested strict checking.
Host key verification failed.

Le chiavi host non cambiano, quindi quando viene visualizzato questo avviso, potrebbe non essere possibile connettersi allo stesso sistema a cui si è connessi in precedenza. Tuttavia, la chiave può essere diversa per un motivo legittimo, ad esempio se il sistema remoto viene reinstallato, le chiavi del server OpenSSH vengono rigenerate o la voce del nome di dominio o l'indirizzo IP viene riassegnato a un nuovo sistema. In questi casi, è possibile rimuovere qualsiasi record esistente del sistema nel database known_hosts.

Rimozione di una chiave esistente

Se si è certi di poter considerare attendibile una nuova chiave fornita da un server remoto, è possibile rimuovere una chiave esistente dal database known_hosts eseguendo:

ssh-keygen -R server1.example.com

Disabilitazione di StrictHostKeyCheck

Negli ambienti di test, in cui i server vengono costantemente reinstallati o sostituiti, è possibile disabilitare StrictHostKeyChecking per determinati host. È possibile disabilitare il controllo della chiave host quando ci si connette a un sistema remoto come indicato di seguito.

ssh -o StrictHostKeyChecking=no user@server1.example.com

Se è necessario disabilitare costantemente il controllo rigoroso dell'host, considerare la possibilità di aggiungere questa opzione a una voce host nella configurazione del client. Per ulteriori informazioni, vedere Impostazione delle opzioni di configurazione del client SSH per un host.

La funzione di controllo rigoroso delle chiavi host è abilitata per impostazione predefinita per evitare attacchi MITM (man-in-the-middle), pertanto la disabilitazione di tale funzionalità non è considerata una buona procedura di sicurezza e non è consigliata nei sistemi di produzione.

Applicare le procedure ottimali per proteggere, memorizzare e utilizzare le coppie di chiavi SSH.

Seguire queste linee guida in modo da poter gestire e utilizzare coppie di chiavi SSH per connettersi in modo sicuro agli host remoti sulla rete.

• Impostare una passphrase sicura quando si genera la coppia di chiavi SSH.

  Per ulteriori informazioni, vedere Generazione di coppie di chiavi mediante il comando ssh-keygen.

• Verificare l'agente della chiave SSH per evitare di dover digitare la passphrase a ogni login.

  Per ulteriori informazioni, vedere Uso dell'agente chiave SSH per ricordare le passphrase.

• Limitare l'accesso per qualsiasi coppia di chiavi SSH che non dispone di una passphrase e viene utilizzata solo per gli scopi di script.

  Per ulteriori informazioni, vedere Limitazione dell'accesso tramite chiave SSH a comandi specifici.

• Non condividere la chiave privata con nessun altro. Ogni membro del team deve avere la propria coppia di chiavi SSH in modo che l'amministratore del sistema possa controllare l'accesso alle risorse di rete.

• Non copiare la chiave privata o inoltrare l'agente SSH ad altri computer, server remoti o istanze cloud.

  Per ulteriori informazioni, vedere Copia delle chiavi pubbliche nei server remoti.

• Non memorizzare una copia della chiave privata in un bastion o in un host jump.

  Per ulteriori informazioni, vedere Utilizzo di ProxyJump per l'accesso tramite un host Jump.