Posso "nascondere" la chiave privata, pur continuando a consentirne l'utilizzo?

Ti stai concentrando sulla protezione delle chiavi sul lato client. Ti consiglio di dare un'occhiata sul lato server.

Sul server, puoi limitare ciò che la chiave è autorizzata a fare e da quali server può essere utilizzato, modificando il file authorized_keys per l'account di destinazione. Ecco un esempio di una chiave con limiti:

from="their.workstation.only.example.com" no-port-forwarding ssh-dss AAA....

Se lo desideri, puoi utilizzare gli indirizzi IP invece di un FQDN.

Per impedire agli utenti di manomettere il file authorized_keys, è possibile spostarlo in una posizione in cui non dispongono dell'autorizzazione alla scrittura. Funzionerà comunque finché avrà l'autorizzazione leggi . Questo può essere fatto modificando sshd_config e cambiando

AuthorizedKeysFile .ssh/authorized_key

ad esempio

AuthorizedKeysFile /usr/local/authorized_keys/%u

Il %u viene sostituito dal nome utente, quindi quando qualcuno si connette a ssh con lo username foo , ssh cercherà il file di chiavi in /usr/local/authorized_keys/foo . Finché foo ha accesso in lettura a quel file, la connessione funzionerà.

Modifica: invece di spostare la chiave, puoi semplicemente impostare il file su immutabile, ad esempio:

sudo chattr +i /home/user/.ssh/authorized_keys

Una volta impostato il limite di IP sorgente e protetto il file chiave da manomissioni, non importa se la chiave privata viene trapelata - non sarà ancora utilizzabile da nessun altro sistema.

Ci sono molte altre cose che puoi fare per limitare gli utenti quando si connettono con le chiavi - vedi la pagina man per sshd . Ci sono anche state alcune domande a questo riguardo su Serverfault, ad esempio accesso SSH limitato per log retrieval .

Suggerirei smart card e token sicuri *. Questi hanno una memoria che non può essere letta, può essere utilizzata solo dal criptoprocessore sicuro. Questo significa che nessuno che ha pieno accesso al token può leggere la chiave privata. L'unica cosa che l'utente può fare è inviare una stringa per essere firmata o decrittografata e ottenere il risultato.

La smart card / token sicuro può anche generare la coppia di chiavi sulla carta, assicurando che la chiave non sia mai stata, e possa essere al di fuori della carta / gettone. La chiave pubblica può quindi essere estratta per poi essere inserita nelle chiavi autorizzate.

* I token USB sicuri sono in effetti una smart card e un lettore di smart card, combinati nello stesso chip con lo stesso livello di sicurezza.

Suggerirei una smart card e un lettore di smart card, se più utenti autorizzati utilizzeranno lo stesso terminale per connettersi al server SSH con la propria identità.

Se ogni utente autorizzato ha un proprio terminale, o vengono usate identità di gruppo, allora suggerirei di usare un token PKI, che può essere posizionato in modo permanente, e anche bloccato con un lucchetto, all'interno del computer, e quindi connesso al computer utilizzando un cavo USB interno.

Non è possibile rimuoverlo ma è possibile crittografarlo, senza utilizzare l'hashing MD5 standard:

cp /userdir/.ssh/id_rsa /userdir/.ssh/id_rsa.old
openssl pkcs8 -topk8 -v2 des3 -in /userdir/.ssh/id_rsa.old -out /userdir/.ssh/id_rsa
chmod 600 /userdir/.ssh/id_rsa

Se lo fai, openssl ti chiederà una passphrase tre volte (per sbloccare la chiave privata esistente e altre due volte una passphrase per la nuova chiave). Questo è il metodo manuale oppure puoi utilizzare keycrypt

Qui c'è un problema piuttosto fondamentale: non puoi permettere loro di leggere la chiave in una circostanza e quindi impedire che facciano qualcosa che non vuoi che facciano.

Anche crittografando la chiave ... se hanno la password da decifrare, allora possono fare quello che vogliono. E se non lo fanno, non possono usarlo affatto.

Di fronte a questo problema, suggerirei di utilizzare uno specifico "account di privilegi" per ogni utente - assegnare i keypairs e utilizzare sudo per consentire l'esecuzione di comandi specifici come "utente privilegiato". Per esempio. %codice%. Per i punti bonus, puoi anche applicare una percentuale dissh $hostname per quell'account utente che non saranno in grado di modificare.