Regarding my previous question and a possible solution I was advised to ask for another solution in a new question.

(Here is the old thread: SSH Agent-Forwarding works, but what about sudo -u username no shell/ permissions? composer)

So, for the sake of simplicity let's assume I only have two users on my server (apart from root).

One user (let's call him Nal) is a part-time admin, meaning he is in the sudoers list.

The other user is used for sftp (as in, ftp over ssh ;)) and managing one site on the webserver located at /srv/web (let's call this user Web).

Web has no other work to do than managing this site, so he has no Shell-access (set to bin/false) and no special privileges.

Now the directory in /srv/web/websiteA is owned by Web and in there I have a Laravel (PHP Framework) installation that also leverages Composer (PHP dependency manager, basically replaced PEAR).

I have some packages in semi-development that are not ready for the masses, hence laying in a private Repository. To access this repository and clone the contents via git (all done automatically with composer!) "Web" needs an SSH-Key.

Instead of managing the same set of SSH-Keys on my local machine and the server, I just pass them through by SSH-Agent-Forwarding.

This works great for "Nal". He has access to my private repositories. But when I want to do a composer update in /srv/web/websiteA I have to do it with "Web" and he has no shell-access and no ssh-keys, so the update fails.

My current workaround is this:

Logged in as Nal I do:

cd /srv/web/websiteA

setfacl -R -m u:Web:rwx "${SSH_AUTH_SOCK%/*}"
sudo -u Web SSH_AUTH_SOCK="$SSH_AUTH_SOCK" composer update
setfacl -b "${SSH_AUTH_SOCK%/*}"

So I set the permission of the Socket where the SSH-Keys are given over to Nal so that Web can access them, then I do my update and then I revoke the permissions again.

This is working, but probably not the best solution.

I don't want to set the permissions of /srv/web/websiteA to 775 or something like that (and add Nal to the www-data group) so I ask here:

Is there any better solution you can come up with?

1 Answer 1


Well, as a suggestion - why not make a copy of your private key and put it on the server in the Web user's ~/.ssh directory, and use the -p option to ssh-keygen to remove the passphrase from the Web's copy of the private key.

You lose a bit of security, since anyone who got their hands on the key file could use it without also needing to know the passphrase, but it ought to be usable to fetch the git repos without needing agent forwarding or anything like that set up.

  • Because: 1) I have to manage the SSH-Keys twice then, which I wanted to avoid from the beginning and 2) because I lose security and then I can stick to the ACL-solution as well, because in my eyes it's more secure because the socket is just given to one more user and just for the update-process itself.
    – Nalrakesh
    Commented May 25, 2014 at 21:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .