Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've got a web server with a dedicated unprivileged user who runs the apache instance on the box. The php code for the app the web server runs is in a private github repo that I occasionally need to git pull to update.

I wish to pull using my personal credentials (my local id_rsa key), but for security reasons, I've set the box up so that I can only access the box via a second, non-root account with sudo access, and then sudo -iu username into the web server user.

I've tried enabling ssh-agent forwarding, and even had sudo keep the SSH_AUTH_SOCK env variable, but the auth sock file has the wrong permissions (700 for the user I ssh'd into).

I've verified that the key is actually added to the agent, and that it is accessible from the first user. I tried to ssh-add -L from the web server user and got a response saying it cannot connect to the ssh-agent. I suspect this is because the permissions are wrong.

Is there a way to change the permissions in an automated fashion?

Or am I going about this the wrong way?

share|improve this question
3  
Why don't you setup your key for the other account, and just ssh directly to that account? –  Zoredache Nov 4 '11 at 23:58
    
Adding more steps does not by itself make your system more secure. In this case, you added the opportunity for misconfiguring the sudoers file to be overly permissive, and have not made it any harder to get access to the real account (you'd still need the correct private key). In fact, the only reason I can think of for your setup would be to make sure the role account doesn't have ssh-agent access... –  Gabe May 2 '13 at 16:57

1 Answer 1

I had the same problem - on a Gentoo box - where I can login as a normal user only but needed to use agent forwarding for the root account. From man su:

‘-m’

‘-p’

‘--preserve-environment’ Do not change the environment variables HOME, USER, LOGNAME, or SHELL. Run the shell given in the environment variable SHELL instead of the shell from user's passwd entry, unless the user running su is not the super-user and user's shell is restricted. A restricted shell is one that is not listed in the file /etc/shells, or in a compiled-in list if that file does not exist. Parts of what this option does can be overridden by --login and --shell.

So

su -m -

preserved the $SSH_AUTH_SOCK environment variable and gave me the desired result.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.