inoltro di ssh-agent e sudo ad un altro utente


153

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). 

Risposte:


182

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

1
Questa è la risposta corretta, dovrebbe essere contrassegnata.
Xealot,

41
Questo solo funziona, se user2sopra è root! Altrimenti, user2SSH_AUTH_SOCK sarà impostato correttamente, ma user2non sarà in grado di accedere ad es. / Tmp / ssh-GjglIJ9337 /. rootha quell'accesso. Quindi questo potrebbe risolvere parte del problema, ma non i PO: " e il socket è leggibile solo dal mio utente originale"
Peter V. Mørch,

6
Defaults>root env_keep+=SSH_AUTH_SOCKDovresti assicurarti di inoltrarlo solo quando esegui il root su root. Non vuoi farlo comunque ad altri utenti per motivi di sicurezza. Meglio eseguire un ssh-agent separato per gli altri e aggiungere le chiavi appropriate.
Paul Schyska,

1
sudo su -non funziona per me, presumibilmente non può preservare l'ambiente perché non è sudoal momento dell'avvio della shell. sudo susembra funzionare.
Alex Fortuna,

3
Non ho mai capito perché la gente lo usi sudo sucomunque. Se hai bisogno di una shell di root, questo è sudo -so cosa sudo -iserve.
Ej

68
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.


2
Come con il commento sopra, questo risolve la questione solo se stai diventando root, perché in quel caso root è in grado di aggirare le consuete autorizzazioni di accesso su $ SSH_AUTH_SOCK.
Doshea,

35

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 ;-)


6
Ricorda che quando si utilizza questo metodo, altre persone hanno effettuato l'accesso in quanto otheruserpossono utilizzare anche l'autenticazione ssh.
gitaarik,

Questo funziona per me, tranne per il fatto che ho dovuto cambiare "sudo su - altro utente" in "sudo su altro utente" (rimuovendo il simbolo -).
Charles Finkel,

1
Perché rwxe non rw(o raffatto)?
Anatoly Techtonik,

3
@anatolytechtonik From man 7 unix- su Linux per la connessione al socket sono necessarie autorizzazioni di lettura e scrittura per quel socket. Inoltre è necessario l'autorizzazione di ricerca (esecuzione) e scrittura nella directory in cui si crea il socket o l'autorizzazione di ricerca (esecuzione) solo quando ci si connette a questo socket. Quindi, nella risposta precedente, l'esecuzione dell'autorizzazione sul socket è ridondante.
mixel

invece di dover modificare / etc / sudoers puoi usaresudo -u otheruser --preserve-env=HOME -s
Sec

14

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".


6
Questo è estremamente rischioso. Dare ad ogni altro utente il permesso di usare il tuo agente SSH equivale a fornire loro tutte le tue credenziali (e se usi mai sudo o su, dando loro il potere di root su tutti gli altri utenti sul sistema, così come su tutti gli altri sistemi a cui sei iscritto!) . Questo non deve MAI MAI essere fatto!
Matija Nalis,

4
Non sono d'accordo con l'affermazione che "Questo non deve MAI MAI essere fatto!" Ci sono molti casi in cui questo rischio è accettabile. Ad esempio, un piccolo team in cui tutti hanno le stesse autorizzazioni e ti fidi di tutti gli altri utenti. Non dovrebbe mai essere fatto senza comprendere i rischi che comporta. Ma una volta compresi questi rischi, ci sono volte in cui il rischio è accettabile.
phylae

6

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.


Lo ha menzionato in fondo alla sua domanda e ha detto che sarebbe difficile da fare.
Fahad Sadah,

Questa è probabilmente la soluzione migliore ma diventa pelosa se $ USER è una persona reale (tm) - potrebbero cancellare la chiave della SA da authorized_keys o cambiare la loro password ...
voretaq7,

Puoi rimuovere il loro accesso in scrittura a authorized_keys (anche se se sono davvero determinati a negare l'accesso a Florian, possono eliminarlo e ricrearlo, trovandosi in una directory di loro proprietà)
Fahad Sadah,

4

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.


Questo non funziona se hai accesso solo a otheruservia sudoanziché a SSH (ad es. Vuoi roba SCP come www-data)
Gert van den Berg

3

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


Quale versione di sudo hai? Il mio (1.6.7p5, CentOS 4.8) non ha -i nella sua pagina man.
David Mackintosh,

Sudo version 1.6.9p17in esecuzione su Debian Lenny. Provare sudo -s?
Fahad Sadah,

6
Non funziona per me.

Su Ubuntu, usando Sudo 1.8.9p5, sudo -ssudo -ifunziona né per me ...
Jon L.

2

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).


1

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.


0

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.


1
Hmm, ma se lo faccio con ssh, il mio agente è comunque accessibile da quell'utente, o sbaglio?

Se si inserisce SSH nell'utente di destinazione con l'inoltro dell'agente, le richieste dell'agente rimbalzeranno sulla catena ovunque si trovi l'agente "reale". Quando si su o sudo lontano dall'utente originale, il socket dell'agente SSH non sarà (o non dovrebbe) essere accessibile - La directory in cui risiede è la modalità 700 e di proprietà dell'utente originale. (Evidente avvertimento: se stai passando al root e resetti l'ambiente SSH_AUTH_SOCK potrebbe funzionare, ma non farei affidamento su di esso)
voretaq7

1
Sul mio server (Ubuntu 12.04, versione ssh OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 marzo 2012), ssh ha -ae -Aargomenti. -afa esattamente l'opposto di quanto previsto, disabilita l'inoltro dell'agente! Quindi, nella versione recente (e forse tutta) di Ubuntu, usa -Aper abilitare l'inoltro dell'agente.
Knite,

@knite Hai ragione: è un errore di battitura (di 3 anni!) nella mia risposta. Risolto ora :-)
voretaq7
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.