Sto leggendo un articolo su Master Linux Now 2013 chiamato OpenSSH: Easy Logins e usa ssh-agent per consentirti di inserire una passphrase per la tua chiave una volta, e quindi puoi connetterti a una macchina remota liberamente senza digitarla di nuovo mentre ssh-agent è in esecuzione.
Il motivo per cui sono stato attratto dall'articolo in primo luogo, oltre a non dover riscrivere la mia password un milione di volte; era così che potevo eseguire backup automatici da / su macchine remote chiamando rsync da cron su una macchina remota al server su ssh;
Ho visto un altro articolo in cui qualcuno ha appena saltato la passphrase in modo che cron possa facilmente usare la chiave per accedere, non mi sembra giusto, ma in pratica va bene farlo? Voglio dire, se qualcuno entrasse in possesso di quel file chiave sarebbe in grado di devastare la macchina per il backup.
Mi sembra che sarebbe più sicuro assicurarsi che l'utente abbia effettuato l'accesso al riavvio e che inserisca la passphrase una volta, quando accedono per far funzionare l'agente e quindi aspettano semplicemente che il lavoro cron venga eseguito con lo schermo bloccato; ma probabilmente mi manca qualcosa qui, ad esempio su quali utenti o tipi di utenti vengono eseguiti i lavori cron.
Risposta accettata:
Limita i comandi che possono essere invocati dalla chiave
Se una chiave SSH verrà utilizzata da qualsiasi tipo di attività automatizzata o non presidiata, dovresti limitare i comandi che è in grado di eseguire su una macchina remota, indipendentemente dalla decisione che prendi su come e dove archiviare la chiave.
Usa qualcosa di simile in ~/.ssh/authorized_keys :
command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAABBBBBXXXXXX.....
In questo modo, almeno la chiave non dovrebbe essere in grado, come dici tu, di devastare. Può accedere solo a ciò a cui dovrebbe accedere, ecc... Molto probabilmente può comunque causare danni, ma dovrebbe avere un accesso inferiore al pieno al sistema remoto.
Puoi anche limitare gli indirizzi IP a cui è consentito connettersi utilizzando quella chiave e disabilitare una serie di altre funzionalità SSH come il port forwarding per le connessioni in cui viene utilizzata quella chiave:
from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....
Tutto quello che deve andare su una singola riga in ~/.ssh/authorized_keys .
Protezione della chiave
Dipende dal tuo modello di minaccia.
Se temi che la chiave venga rubata mentre è "a freddo", ad esempio, se il computer in cui è stata salvata viene rubato fisicamente, non vorrai salvarla senza una passphrase in quella posizione.
Potresti avviare manualmente una sorta di agente SSH in background dopo l'avvio del server, aggiungere la chiave a tale agente e registrare il $SSH_AUTH_SOCK dell'agente per un uso futuro da parte del lavoro cron, ma onestamente sembra più un problema di quanto non valga la pena. Potresti anche archiviare la chiave non crittografata in un tmpfs filesystem e fare in modo che il lavoro cron vi acceda da lì. In entrambi i casi la chiave risiede solo in memoria (se non si dispone di scambio o scambio crittografato). Ovviamente dovresti chown e chmod il file in modo che solo l'utente di destinazione possa accedervi.
Poi di nuovo, se sei preoccupato per questo, probabilmente hai già configurato questo computer con un filesystem di root crittografato e lo scambio (ad es. Luks), quindi potresti non doverlo preoccupare in quanto tale.
Se sei preoccupato che la chiave venga rubata mentre è "calda" (caricata in memoria), non c'è molto che puoi fare al riguardo. Se il lavoro cron può accedervi, può farlo anche qualcos'altro che è riuscito ad ottenere lo stesso accesso. È quello, o rinuncia alla comodità dell'esecuzione di lavori non presidiata.
In conclusione, dovresti considerare un server di backup come un sistema molto privilegiato poiché, per necessità, avrà accesso in sola lettura ai filesystem completi di tutti i computer di cui esegue il backup. Il tuo server di backup non dovrebbe essere accessibile da Internet, ad esempio.