inoltro di ssh-agent e sudo ad un altro utente

Se ho un server A sul quale posso accedere con la mia chiave SSH e ho la possibilità di "sudo su - altro utente", perdo l'inoltro della chiave, perché le variabili env vengono rimosse e il socket è leggibile solo dal mio utente originale. Esiste un modo per collegare il forwarding della chiave attraverso "sudo su - otheruser", in modo da poter fare cose su un server B con la mia chiave inoltrata (git clone e rsync nel mio caso)?

L'unico modo in cui riesco a pensare è l'aggiunta della mia chiave a authorized_keys di otheruser e "ssh otheruser @ localhost", ma è ingombrante da fare per ogni combinazione di utente e server che posso avere.

In breve:

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

Come hai detto, le variabili di ambiente vengono rimosse da sudo, per motivi di sicurezza.

Ma per fortuna sudoè abbastanza configurabile: puoi dirlo con precisione quali variabili d'ambiente vuoi conservare grazie env_keepall'opzione di configurazione in /etc/sudoers.

Per l'inoltro dell'agente, è necessario mantenere la SSH_AUTH_SOCKvariabile di ambiente. Per fare ciò, è sufficiente modificare il /etc/sudoersfile di configurazione (sempre utilizzando visudo) e impostare l' env_keepopzione per gli utenti appropriati. Se vuoi che questa opzione sia impostata per tutti gli utenti, usa la Defaultslinea in questo modo:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers per ulteriori dettagli.

Ora dovresti essere in grado di fare qualcosa del genere (a condizione user1che la chiave pubblica sia presente ~/.ssh/authorized_keysin user1@serverAe user2@serverB, e serverAil /etc/sudoersfile sia installato come indicato sopra):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

sudo -E -s

• -E preserverà l'ambiente
• -s esegue un comando, il valore predefinito è una shell

Questo ti darà una shell di root con le chiavi originali ancora caricate.

Consentire ad altri utenti di accedere al $SSH_AUTH_SOCKfile e alla relativa directory, ad esempio mediante ACL corretto, prima di passare a essi. L'esempio presuppone che Defaults:user env_keep += SSH_AUTH_SOCKnel /etc/sudoerscomputer host:

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

Più sicuro e funziona anche per utenti non root ;-)

Ho scoperto che anche questo funziona.

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Come altri hanno notato, questo non funzionerà se l'utente a cui stai passando non ha i permessi di lettura su $ SSH_AUTH_SOCK (che è praticamente qualsiasi utente oltre a root). Puoi aggirare questo problema impostando $ SSH_AUTH_SOCK e la directory in cui si trova ha le autorizzazioni 777.

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Questo è piuttosto rischioso però. Fondamentalmente stai dando ad ogni altro utente il permesso di usare il tuo SSH Agent (fino a quando non ti disconnetti). Potresti anche essere in grado di impostare il gruppo e modificare le autorizzazioni su 770, il che potrebbe essere più sicuro. Tuttavia, quando ho provato a cambiare il gruppo, ho ricevuto "Operazione non consentita".

Se sei autorizzato a farlo sudo su - $USER, probabilmente avresti una buona argomentazione per essere autorizzato a fare un ssh -AY $USER@localhostinvece, con la tua chiave pubblica valida nella home directory di $ USER. Quindi il tuo inoltro di autenticazione verrebbe effettuato con te.

Puoi sempre usare ssh su localhost con l'inoltro dell'agente invece di usare sudo:

ssh -A otheruser@localhost

Lo svantaggio è che è necessario accedere nuovamente, ma se lo si utilizza in una schermata / scheda tmux, questo è solo uno sforzo una volta, tuttavia, se ci si disconnette dal server, il socket verrà (ovviamente) nuovamente rotto . Quindi non è l'ideale se non riesci a tenere aperta la tua sessione schermo / tmux in ogni momento (tuttavia, puoi aggiornare manualmente la tua SSH_AUTH_SOCKenv var se sei forte).

Si noti inoltre che quando si utilizza l'inoltro ssh, root può sempre accedere al socket e utilizzare l'autenticazione ssh (purché si acceda con l'inoltro ssh). Quindi assicurati di poterti fidare di root.

Non usare sudo su - USER, ma piuttosto sudo -i -u USER. Per me va bene!

Combinando le informazioni delle altre risposte, ho trovato questo:

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

Mi piace perché non ho bisogno di modificare il sudoersfile.

Testato su Ubuntu 14.04 (ha dovuto installare il aclpacchetto).

Penso che ci sia un problema con l' -opzione (trattino) dopo sunel tuo comando:

sudo su - otheruser

Se leggi la pagina man di su , potresti scoprire che l'opzione -, -l, --loginavvia l'ambiente shell come shell di login. Questo sarà l'ambiente otheruserindipendentemente dalle variabili env in cui si esegue su.

In poche parole, il trattino minerà qualsiasi cosa tu abbia passato sudo.

Invece, dovresti provare questo comando:

sudo -E su otheruser

Come sottolineato da @ joao-costa, -Everranno preservate tutte le variabili nell'ambiente in cui è stata eseguita sudo. Quindi, senza il trattino, suutilizzerà direttamente quell'ambiente.

Sfortunatamente quando fai un sopralluogo ad un altro utente (o addirittura usi il sudo) perderai la possibilità di usare le tue chiavi inoltrate. Questa è una funzione di sicurezza: non vuoi che utenti casuali si colleghino al tuo ssh-agent e usino le tue chiavi :)

Il metodo "ssh -Ay $ {USER} @localhost" è un po 'ingombrante (e come notato nel mio commento sulla risposta di David incline alla rottura), ma è probabilmente il meglio che puoi fare.