ATTENZIONE : creatività in anticipo, che spesso è dannosa per la sicurezza (almeno senza una revisione approfondita).
Questo sembra un caso in cui un agente SSH potrebbe essere utile. Un agente SSH fornisce un'interfaccia socket su cui i client SSH possono chiedere all'agente di eseguire operazioni chiave per loro, il che abilita i seguenti usi comuni:
- Puoi fare in modo che l'agente con esecuzione prolungata decrittografi la tua chiave privata una volta, invece di fare decrittografare la chiave separatamente.
- Puoi far inoltrare il tuo client SSH alla connessione dell'agente, permettendoti di usare la tua chiave dall'host remoto senza effettivamente memorizzarla o altrimenti rivelarla.
Questo secondo caso, in particolare, suona molto simile al tuo caso d'uso, tranne che invece di concedere l'accesso su un host diverso, vuoi concedere l'accesso a più utenti sullo stesso host.
Sembrerebbe qualcosa del genere:
sshkeeper@bastion$ eval "$(ssh-agent -a /path/to/socket)"
sshkeeper@bastion$ echo $SSH_AUTH_SOCK
/path/to/socket
sshkeeper@bastion$ ssh-add
Enter passphrase for /home/sshkeeper/.ssh/id_rsa:
sshkeeper@bastion$ chmod 660 /path/to/socket
sshkeeper@bastion$ chgrp ssh-users /path/to/socket
La chiave non ha necessariamente bisogno di una passphrase; Ne ho incluso uno per illustrazione.
In ogni caso, ora chiunque abbia il permesso di leggere e scrivere sul socket può usare ...
jander@bastion$ export SSH_AUTH_SOCK=/path/to/socket
jander@bastion$ ssh private_server
Error reading response length from authentication socket.
Permission denied (publickey).
Spiacenti. È un po 'più complicato di così, perché ssh-agent è paranoico e controlla l'ID utente di chiunque si colleghi al socket. Quindi abbiamo bisogno di una soluzione alternativa. Proviamo ad usare socat come proxy:
sshkeeper@bastion$ eval "$(ssh-agent -a /home/sshkeeper/ssh_agent_socket)"
sshkeeper@bastion$ ssh-add
Enter passphrase for /home/sshkeeper/.ssh/id_rsa:
sshkeeper@bastion$ rm /path/to/socket
sshkeeper@bastion$ umask 117
sshkeeper@bastion$ socat UNIX-LISTEN:/path/to/socket,fork,group=ssh-users UNIX-CONNECT:/home/sshkeeper/ssh_agent_socket &
Ora è il processo socat di proprietà di sshkeeper che si connette all'agente e non al client SSH di proprietà jander, quindi l'agente non ha alcun reclamo:
jander@bastion$ export SSH_AUTH_SOCK=/path/to/socket
jander@bastion$ ssh private_server
jander@private_server$ █
Dovrai fare attenzione alle autorizzazioni del filesystem per accedere al socket, poiché è tutto ciò che serve per proteggerlo. Non dare a nessuno tranne sshkeeper accesso in scrittura lungo il percorso del socket. Attenzione anche che alcuni sistemi derivati da BSD ignorano le autorizzazioni sul file socket stesso; testalo accuratamente sul tuo sistema.
Infine, fai attenzione che si tratta di un uso non standard dell'agente SSH: in effetti ho dovuto aggirare una funzionalità di sicurezza per farlo funzionare. Credo che su un sistema Linux con permessi adeguati per il filesystem, possa essere almeno sicuro o più sicuro della soluzione sudo ... ma non dovresti credermi sulla parola. Assicurati di aver capito esattamente cosa sta succedendo qui prima di utilizzarlo.
UPDATE : ho dato un'occhiata a openssh ssh-agent source code per vedere cosa si può fare con un socket dell'agent, e posso vedere un paio di opportunità per un piccolo danno. Vale a dire, i tuoi utenti possono chiedere all'agente di aggiungere o rimuovere le chiavi.
Quindi una persona potrebbe dire all'agente di rilasciare la chiave, bloccando tutti gli altri dai server finché tu (o uno script) non aggiungerai nuovamente la chiave.
Una persona potrebbe anche aggiungere una chiave, dando a tutti gli altri l'accesso a server aggiuntivi. Tuttavia, questa persona potrebbe anche consegnare la chiave ad altre persone (senza utilizzare il server) o utilizzare il proprio agente condiviso, quindi questo punto è relativamente minore.