Le chiavi SSH

Una chiave SSH è una credenziale di accesso nel protocollo SSH. La sua funzione è simile a quella dei nomi utente e delle password, ma le chiavi sono utilizzate principalmente per i processi automatizzati e per implementare il single sign-on da parte degli amministratori di sistema e dei power user.

Le chiavi SSH sono credenziali di autenticazione

SSH (Secure Shell) è utilizzato per gestire reti, sistemi operativi e configurazioni. È anche all’interno di molti strumenti di trasferimento di file e strumenti di gestione della configurazione. Ogni grande azienda lo usa, in ogni data center.

Le chiaviSSH permettono l’automazione che rende possibili e convenienti i moderni servizi cloud e altri servizi dipendenti dal computer. Offrono convenienza e maggiore sicurezza quando sono gestite correttamente.

Funzionalmente le chiavi SSH assomigliano alle password. Concedono l’accesso e controllano chi può accedere a cosa. Nella gestione dell’identità e dell’accesso, hanno bisogno di politiche simili, approvvigionamento e terminazione come gli account utente e le password. Non si può avere riservatezza, integrità o qualsiasi garanzia di disponibilità continua dei sistemi senza controllare le chiavi SSH.

Tecnicamente le chiavi sono chiavi crittografiche che utilizzano un sistema di crittografia a chiave pubblica. Tuttavia, funzionalmente sono credenziali di autenticazione e devono essere gestite come tali.

Le chiavi autorizzate definiscono chi può accedere ad ogni sistema

Le chiavi autorizzate sono chiavi pubbliche che garantiscono l’accesso. Sono analoghe alle serrature che la chiave privata corrispondente può aprire.

Per maggiori informazioni, vedi la pagina dedicata alle chiavi autorizzate.

Le chiavi identificative identificano gli utenti e forniscono l’accesso

Le chiavi identificative sono chiavi private che un client SSH usa per autenticarsi quando accede a un server SSH. Sono analoghe alle chiavi fisiche che possono aprire una o più serrature.

Le chiavi autorizzate e le chiavi di identità sono chiamate insieme chiavi utente. Si riferiscono all’autenticazione dell’utente, al contrario delle chiavi host che sono usate per l’autenticazione dell’host.

Per maggiori informazioni, vedi la pagina dedicata alle chiavi di identità.

Autenticazione utente basata su certificato

I certificati PKI possono anche essere usati per l’autenticazione. In questo caso, l’utente ha ancora una chiave privata ma ha anche un certificato associato alla chiave. Questa tecnologia è supportata sia in Tectia SSH che in OpenSSH, con alcune differenze. Per maggiori informazioni, vedi la pagina dedicata all’autenticazione basata su certificato in SSH.

Chiavi di autenticazione dei dispositivi

Le chiavi host autenticano i server

Le chiavi host sono usate per autenticare gli host, cioè i computer. Il loro scopo è quello di prevenire gli attacchi man-in-the-middle. Vedere la pagina separata sulle chiavi host per maggiori informazioni.

L’autenticazione host basata sul certificato può essere un’alternativa molto attraente nelle grandi organizzazioni. Permette che le chiavi di autenticazione del dispositivo siano ruotate e gestite convenientemente e che ogni connessione sia protetta.

Chiavi host conosciute

Una delle caratteristiche uniche di SSH è che per default, si fida e ricorda la chiave dell’host quando si connette per la prima volta. Questo è stato un fattore di differenziazione chiave che ha permesso a SSH di essere distribuito dal basso, poiché non c’era un’infrastruttura di chiavi centralizzata per gli host nel 1995, e non c’è ancora oggi (2017), con l’eccezione dei certificati SSL per i server web. La risultante facilità di implementazione è stata una delle ragioni principali del successo di SSH.

Le chiavi host memorizzate sono chiamate chiavi host note e sono memorizzate in un file chiamato known_hosts in OpenSSH. Finché le chiavi host non cambiano, questo approccio è molto facile da usare e fornisce una sicurezza abbastanza buona. Tuttavia, in grandi organizzazioni e quando le chiavi cambiano, mantenere i file degli host conosciuti può diventare molto dispendioso in termini di tempo. L’uso di certificati per le chiavi host è raccomandato in quel caso. Tectia SSH supporta i certificati standard X.509 per gli host. OpenSSH ha il suo formato di certificato proprietario. Il vantaggio dei certificati standard è che possono essere emessi da qualsiasi autorità di certificazione (CA), mentre non esistono CA affidabili per le chiavi OpenSSH. Vedi la pagina dedicata ai certificati con SSH per maggiori informazioni.

Chiavi di sessione

Una chiave di sessione in SSH è una chiave di cifratura usata per cifrare la maggior parte dei dati in una connessione. La chiave di sessione è negoziata durante la connessione e poi usata con un algoritmo di crittografia simmetrica e un algoritmo di codice di autenticazione del messaggio per proteggere i dati. Per maggiori informazioni, vedi la pagina separata sulle chiavi di sessione.

Come configurare l’autenticazione basata sulla chiave

L’autenticazione basata sulla chiave in SSH è chiamata autenticazione a chiave pubblica. È facile da configurare per gli utenti finali nella configurazione predefinita. D’altra parte, le organizzazioni attente alla sicurezza hanno bisogno di stabilire politiche chiare per la fornitura e la cessazione dell’accesso basato su chiave.

Come impostare l’autenticazione a chiave pubblica per OpenSSH

Le chiavi SSH sono tipicamente configurate in un file authorized_keys nella .ssh sottodirectory della home directory dell’utente. Tipicamente un amministratore di sistema dovrebbe prima creare una chiave usando ssh-keygen e poi installarla come chiave autorizzata su un server usando lo strumento ssh-copy-id. Si veda anche la pagina dedicata alla configurazione delle chiavi autorizzate per OpenSSH.

Si raccomanda di usare le passphrase per tutte le chiavi di identità usate per l’accesso interattivo. In linea di principio raccomandiamo di usare le passphrase anche per l’accesso automatico, ma questo spesso non è pratico.

Memorizzare le chiavi in ssh-agent per il single sign-on

SSH è dotato di un programma chiamato ssh-agent, che può tenere in memoria le chiavi private decrittate dell’utente e usarle per autenticare i login. L’agente può anche essere usato per accedere alle chiavi su una smartcard o in un Hardware Security Module (HSM). Vedere la documentazione per ssh-agent su come configurarlo.

La connessione all’agente SSH può essere inoltrata a un server, in modo che il single sign-on funzioni anche da quel server in poi. Questa caratteristica dovrebbe essere usata con attenzione, in quanto permette ad un server compromesso di usare le credenziali dell’utente dall’agente originale. L’inoltro dell’agente può, tuttavia, essere una caratteristica di grande comodità per gli utenti potenti in ambienti meno critici per la sicurezza.

Per abilitare l’inoltro dell’agente, impostare AllowAgentForwarding a yes in /etc/ssh/sshd_config sul server e ForwardAgent a yes nel file di configurazione del client /etc/ssh/ssh_config.

Dimensioni delle chiavi raccomandate

Si raccomanda di selezionare le dimensioni delle chiavi secondo NIST SP 800-57. Le dimensioni predefinite delle chiavi usate dallo strumento ssh-keygen sono generalmente di forza accettabile. Infatti, poiché il protocollo non rivela mai le chiavi pubbliche che sono accettabili per l’autenticazione dell’utente, gli algoritmi utilizzati per le chiavi non sono così critici come lo sono, per esempio, nei certificati PKI.

Per le chiavi RSA, 2048 bit è probabilmente una buona scelta oggi (2017). Tuttavia, molti crittografi ora raccomandano di passare alle chiavi ECDSA e pensano che i progressi nella fattorizzazione di grandi numeri interi possano rendere le chiavi RSA vulnerabili nel prossimo/medio termine. Per ECDSA raccomandiamo di usare chiavi a 521 bit (sic!), anche se chiavi a 384 o anche 256 bit probabilmente sarebbero sicure. Non c’è alcun vantaggio pratico nell’usare chiavi più piccole.

Posizione della chiave d’identità

Le chiavi d’identità sono solitamente memorizzate nella directory .ssh di un utente, per esempio, .ssh/ssh_id_rsa. Il nome predefinito del file della chiave d’identità inizia con id_<algorithm>. Tuttavia, è possibile specificare qualsiasi nome di file e qualsiasi posizione quando si crea una chiave privata, e fornire il nome del percorso con l’opzione -i al client SSH. Per esempio, ssh -i /home/ylo/secure/my-key [email protected] userebbe una chiave privata dal file my-key per l’autenticazione.

La posizione predefinita della chiave di identità può anche essere configurata in /etc/ssh/ssh_config o nel file .ssh/config dell’utente usando l’opzione IdentityFile.

Localizzazione delle chiavi autorizzate

Quando un utente cerca di accedere usando l’autenticazione basata sulle chiavi, il server OpenSSH cerca le chiavi autorizzate da una directory specificata nella configurazione del server usando l’opzione AuthorizedKeysFile. Il default è .ssh/authorized_keys nella home directory dell’utente.

Tuttavia, avere le chiavi autorizzate memorizzate nella home directory dell’utente significa che l’utente può aggiungere nuove chiavi che autorizzano i login al suo account. Questo è conveniente, ma l’utente può poi dare queste chiavi ad amici o colleghi, o anche venderle per Bitcoin (questo è realmente accaduto). Le chiavi SSH sono inoltre permanenti e rimangono valide fino a quando non vengono espressamente rimosse.

Se vengono aggiunte chiavi autorizzate per account di root o di servizio, rimangono facilmente valide anche dopo che la persona che le ha installate ha lasciato l’organizzazione. Sono anche un modo conveniente per gli hacker di stabilire una presenza permanente su un sistema se non c’è rilevamento e avvisi su nuove chiavi non autorizzate.

Per queste ragioni, la maggior parte delle grandi organizzazioni vogliono spostare le chiavi autorizzate in una posizione di proprietà di root e stabilire un processo controllato di approvvigionamento e terminazione per loro.

Spostando le chiavi SSH in una posizione di proprietà di root

In linea di principio, spostare le chiavi SSH in una posizione di proprietà di root è facile:

Creare una directory di proprietà di root adatta, per esempio, /etc/ssh/keys, sotto la quale sono memorizzate le chiavi autorizzate.
Crea una sottodirectory sotto questa directory per ogni utente, e sposta il file authorized_keys di ogni utente in /etc/ssh/keys/<user>/authorized_keys.
Infine, cambiate il set AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys in /etc/ssh/sshd_config.

In pratica, tuttavia, questo non è sempre così semplice, specialmente negli ambienti più grandi. I nomi utente possono provenire da directory (ad esempio, Active Directory o LDAP). Molte organizzazioni hanno diverse versioni di OpenSSH, inclusi sistemi molto vecchi o build SSH personalizzate che hanno percorsi integrati non standard. Si consiglia di utilizzare strumenti di gestione delle chiavi come Universal SSH Key Manager per nascondere questa complessità in ambienti più grandi. Questi strumenti possono anche implementare un flusso di lavoro di provisioning, terminazione e approvazione per le chiavi e avvisi su modifiche non autorizzate fatte da utenti root.

La limitazione di OpenSSH sul numero di chiavi private

Il server OpenSSH ha una caratteristica (io la chiamerei un bug) che conta il test se una particolare chiave può essere usata per l’autenticazione come un tentativo di autenticazione. Questo ha la conseguenza che se l’utente ha più di cinque chiavi in .ssh, solo alcune di esse funzionano. Questo spesso causa il fallimento dell’autenticazione basata sulle chiavi ed è spesso difficile da capire per gli utenti. Il modo per aggirare questo problema è specificare esplicitamente la chiave privata da usare usando l’opzione -i. Un’alternativa è quella di regolare la sessione MaxAuthTries sul server, ma questa non è una soluzione completa ed è indesiderabile aumentare il numero di tentativi di autenticazione con password.

Come sono fatte le chiavi SSH

Una chiave autorizzata può avere questo aspetto:

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar

Una chiave di identità può avere questo aspetto:

Come funziona l’autenticazione in SSH?

L’inizializzazione di una connessione in SSH consiste in:

Negoziare la versione del protocollo da usare
Negoziare gli algoritmi crittografici e le altre opzioni da usare
Negoziare una chiave di sessione monousoper criptare il resto della sessione
Autenticazione dell’host del server usando la sua chiave host
Autenticazione dell’utente usando una password, autenticazione a chiave pubblica o altri mezzi.

Dopo questo, i dati possono essere scambiati, inclusi i dati del terminale, la grafica e i file.

Chiave SSH - Autenticazione tramite chiavi SSH

Autenticazione a chiave pubblica

Il meccanismo di autenticazione basato sulla chiave in SSH è chiamato autenticazione a chiave pubblica. Essenzialmente, alcuni dati specifici della sessione sono firmati usando la chiave privata dell’identità. La firma viene poi inviata al server che controlla se la chiave usata per la firma è configurata come chiave autorizzata. Il server poi verifica la firma digitale usando la chiave pubblica nella chiave autorizzata. La chiave d’identità non viene mai inviata al server.

La cosa essenziale nell’autenticazione a chiave pubblica è che permette a un server di accedere a un altro server senza dover digitare una password. Questa potente caratteristica è il motivo per cui è così ampiamente utilizzata per i trasferimenti di file (utilizzando il protocollo SFTP) e la gestione della configurazione. È anche comunemente usato dagli amministratori di sistema per il single sign-on.

Quanto sono comuni le chiavi SSH e qual è il rischio

Le chiavi SSH risultano essere estremamente comuni e ampiamente utilizzate. Molte grandi organizzazioni le hanno accumulate per vent’anni senza alcun controllo. Una tipica impresa Fortune 500 ha diversi milioni di chiavi che garantiscono l’accesso ai loro server. Nel caso di un cliente, abbiamo esaminato 500 applicazioni e 15.000 server, e abbiamo trovato 3.000.000 di chiavi autorizzate e 750.000 coppie di chiavi uniche. Questa organizzazione aveva anche più di cinque milioni di accessi giornalieri utilizzando le chiavi. Le chiavi erano usate per eseguire transazioni finanziarie, aggiornare configurazioni, spostare dati di log, trasferimenti di file, accessi interattivi da parte degli amministratori di sistema e molti altri scopi.

Si sta scoprendo che la maggior parte delle grandi imprese ha centinaia di migliaia o addirittura milioni di chiavi. Queste chiavi rappresentano un accesso non contabilizzato e possono mettere a rischio l’intera azienda.

Come eliminare completamente le chiavi SSH

PrivX On-Demand Access Manager può essere utilizzato per eliminare completamente le chiavi SSH dai server e stabilire un controllo degli accessi basato su policy e la registrazione delle sessioni in tutta l’azienda. Inoltre, elimina la maggior parte degli oneri amministrativi legati alla gestione delle chiavi, pur fornendo i vantaggi dell’automazione e del single sign-on.