Sto abbozzando un modo per rafforzare e automatizzare l'accesso al server usando ssh-keygen con certificati dove certificati, validi per es. 1 settimana, vengono generati su un server affidabile e possono essere utilizzati sia per creare l'utente-server che per l'accesso. Lo schema potrebbe essere facilmente esteso per supportare diversi ruoli, come implementazione, backup, sudo, ecc.
La mia domanda è: vorresti dire che il metodo proposto di seguito è sicuro e affidabile?
In breve, i passaggi sarebbero:
- L'utente accede alla pagina Web
- L'utente fornisce la chiave pubblica SSH
- Il server genera due certificati, uno per la radice per creare l'utente e l'altro per l'accesso
- L'utente scarica i certificati generati nella cartella principale sul computer client
- La prima volta che si accede al server, l'utente utilizza il certificato di creazione dell'utente. In seguito alla connessione (come utente root), il server creerà l'utente e quindi si disconnetterà.
- Nell'uso normale, verrà utilizzato il certificato di accesso. Questo certificato dovrà essere aggiornato una volta alla settimana.
- Se un utente sospetta la perdita del certificato, l'utente stesso o un amministratore può aggiornare l'elenco di revoche delle chiavi dal server di rilascio
I passi più significativi coinvolti sarebbero:
- Crea una chiave di firma dell'utente memorizzata su un server sicuro. Il server potrebbe essere protetto da oauth2_proxy per l'autenticazione e consentire la crittografia per SSL. Utilizzando oauth2_proxy, l'identità dell'utente diventa nota e autenticata. L'autorizzazione potrebbe essere associata all'appartenenza al gruppo controllata da oauth2_proxy.
- Tutti i server devono essere accodati per accettare gli utenti mediante la firma della chiave del passaggio 1. (Impostare TrustedUserCAKeys in / etc / ssh / sshd_config) È possibile rimuovere l'accesso basato su password e sincronizzare continuamente l'elenco di revoche delle chiavi.
- Quando un utente richiede un certificato create-user, l'utente fornirà la sua chiave pubblica e il server creerà il certificato e lo fornirà all'utente. L'identità viene salvata per fornire funzionalità di revoca delle chiavi, se necessario.
ssh-keygen -s ca-private-keyfile -I 'create user username valid NN' -V +30d -n root -O clear -O force-command='useradd username' user-provided-public-key
- Quando un utente richiede un certificato di accesso, l'utente fornirà la sua chiave pubblica e il server creerà il certificato e lo fornirà all'utente. (Ancora una volta, salvando l'identità per la possibile revoca delle chiavi)
ssh-keygen -s ca-private-keyfile -I 'user@org valid nn' -V +7d -n username user-provided-public-key
Note:
- Sarebbe possibile e consigliato aggiungere un passaggio di verifica a due fattori almeno alla procedura di generazione della firma.
- L'utente dovrebbe, per comodità, avere due coppie di chiavi SSH per consentire a ssh di distinguere tra i certificati desiderati.
- Sarebbe facile rilasciare più tipi di accesso cambiando il comando di forza, come ottenere l'accesso sudo: -n root -O comando forzato 'adduser username sudo' con l'ulteriore vantaggio di utenti che scelgono quando richiamare i loro diritti e su quali host.
- Per fornire un accesso più granulare, i certificati possono essere emessi con limiti ai nomi host o chiavi di firma differenti: è possibile installare paris su diverse classi di host.
- Per fornire protezione contro un utente malintenzionato che legge i file sul server di emissione (ad esempio, per ottenere l'accesso al backup), la coppia di chiavi SSH potrebbe essere crittografata sul server. Gli utenti che devono emettere certificati devono conoscere la passphrase e fornirla su ogni richiesta di firma.
Ho trovato una configurazione simile in cui i colleghi firmano ogni altra richiesta di firma: link ma preferirei una configurazione come sopra.