Ci sono alcune brevi discussioni sulla ssh-agent -tfunzione esistente in [1], e c'è stato un post nel 2001 su debian-devel [2] che desiderava una funzione di timeout di inattività. C'è una discussione simile qui su SE [3] per spettacolo.
Devo chiedermi come il resto del pianeta sta proteggendo le chiavi SSH - mi sto perdendo qualcosa di ovvio perché questo sia un punto doloroso per me, e apparentemente nessun altro? In particolare sto pensando a interazioni ssh con script, come ad esempio con ansible. Sembra che oggi le tue scelte siano:
- Impostare la durata della chiave nell'agente su un periodo di tempo preoccupantemente lungo, ad es. 1h o qualunque sia il massimo tempo di esecuzione dei tuoi script (può dubitare che molte persone consentano al loro timeout di re-auth sudo di allungarsi così a lungo!) - ma
seahorse/ agnome-keyring-daemonmalapena supportano così tanto [4] - Fai da babysitter ai tuoi script di vecchia data e continua a reinserire la tua passphrase ogni 5/10/15 minuti: ora puoi essere facilmente visto entrare nella passphrase 20 volte al giorno
- Attacca la tua soluzione di birra fatta in casa per imitare questa caratteristica mancante, forse in combinazione con la shell
TMOUTshell var (grazie a Freenode #openssh IRC per quel suggerimento) - Non è stata impostata alcuna durata della chiave, ovvero l'agente mantiene la chiave caricata per sempre o fino a quando non si annulla / riavvia
Se stai usando brevi timeout dell'agente ssh, passphrase forti e file di chiavi diversi per ogni tipo di ruolo che autentichi come: questo porta a una giornata molto frustrante!
Ho sperimentato gpgkey2ssh e smart card, ma questo non risolve davvero questo particolare problema: voglio ancora la funzionalità ssh-agent e non voglio dover ripetere l'autorizzazione ogni 5 minuti solo per impedire che le mie chiavi private vengano esposte in memoria mentre il mio computer è inattivo.
Sto sbagliando?
[1] Configurazione del timeout predefinito per l'agente SSH
[2] https://lists.debian.org/debian-devel/2001/09/msg00851.html
[3] /server/518312/putty-pageant-forget-keys-after-period-of-inactivity
[4] https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/129231
ssh-agentdi sapere quando una sessione è inattiva, ma almeno avvia il timeout da quando si è verificata l'ultima operazione di firma, non solo quando è ssh-agentstata avviata. Inoltre, utilizzo già account utente e file di chiavi separati per ciascun ruolo di script, sudoers consente di eseguire solo 1 o 2 comandi, se necessario, e ho cercato lshelldi bloccare ulteriormente le cose. Ma tutto ciò che ancora non mi assolve dall'esigenza di proteggere i miei file di chiavi: solo perché sudo zfs sendè l'unico comando consentito per una determinata chiave, è un comando abbastanza potente per chiunque brandisca quella chiave!
ControlMaster/ ControlPath/ ControlPersist(vedi man ssh_config) per il tuo script. Almeno se si connette solo a un host.
ssh-agentle chiavi caricate fino al riavvio (che potrebbe essere settimane).
ssh-agentè agnostico rispetto al tipo di sessione di cui fa parte (ad es. Sessione tty, sessione X11 o qualcos'altro). L'unica cosa che vorrei dire se probabilmente i tuoi script automatici non dovrebbero dipendere dalla chiave caricata nel tuo agente. Ognuno di essi dovrebbe probabilmente avere la propria chiave privata, che è autorizzata tramite comandi forzati sui server appropriati per eseguire solo i comandi remoti specifici che ogni script deve eseguire. Ciò ovviamente ti permetterebbe di scappare da cronisti ecc ...