2

Working on a remote server (A) I want to use my local SSH-Keys to access a repository on another server (B) that is not controlled by me.

Generally this works like a charm.

I log in as myUsername on the remote server (A) and can access the repositories on B just fine.

The problem is, that there are some tasks (composer update) that need to be executed by another user on (A).

This user is not an admin and the folders where the scripts are executed are his and should only be writable by him and not an entire group, so I can't just chmod all the folders to 777, 775 or something ;)

The problem is, that when I want to execute the script with: sudo -u another_user composer update sure enough there are no keys found, because they don't get forwarded for this user.

Also the "another_user"'s shell is set to bin/false to complicate things even further!!!

Is there a solution to this?

To sum it all up: I want to access another remote server through my own remote server with my local ssh-keys through sudo -u another_user ...

Would be great if someone with more experience could enlighten me!

edit: I also tried this already: http://mybrainhurts.com/blog/2012/05/git-sudo-local-ssh-keys.html But I guess it won't work because the other user has no shell :(

Improve this question

3 Answers 3

Reset to default
7

The only way to do this is via a very dirty hack. I do not recommend it.

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

The reason for this is that your SSH keys are accessed via a named socket. That named socket is in a directory owned by you, and cannot be accessed by anyone else. The only way to give the other user access is by changing permissions on the socket.
The above does this via extended filesystem attributes. If your /tmp filesystem does not support ACLs, then the only way to do it is to chmod o+rwx, and that is horribly insecure.

The better solution is fixing whatever is preventing you from running that command as your own user.

Improve this answer
5
  • Well, there is no real fix for that, because the only two ways to do that would be: a) change the owner of the folder to my own user, who is an admin, which is kind of dangerous and stupid. b) change the permissions of the entire directory including subdirectores and files to 775 or something :/
    – Nalrakesh
    May 23, 2014 at 7:04
  • Wouldn't this work great if I just did setfacl and afterwards use "setfacl -R "${SSH_AUTH_SOCK%/*}" ? Would you still consider this a dirty hack?
    – Nalrakesh
    May 23, 2014 at 7:21
  • Generally this works like a charm, thank you so much! Still plase see one comment above and answer me, if you can. Much appreciated, thanks!
    – Nalrakesh
    May 23, 2014 at 7:52
  • To sum up what I'd do now: setfacl -R -m u:rocket:rwx "${SSH_AUTH_SOCK%/*}" sudo -u rocket SSH_AUTH_SOCK="$SSH_AUTH_SOCK" composer update setfacl -b "${SSH_AUTH_SOCK%/*}" Should be save, right?
    – Nalrakesh
    May 23, 2014 at 8:03
  • Yes, you could remove the permissions afterwards, though it would be setfacl -b. I'd still consider it an un-optimial solution though. I'd still consider fixing the root of the issue, but without more information, I can't present a solution. If you're interested, I'd present all the information about what you're doing in another question and see what people come up with.
    – phemmer
    May 23, 2014 at 12:28
1

You may want to use su username (super user), it will run as that user vs sudo. This helps a bit: (not sure about if there is another one on unixstackexchange) https://askubuntu.com/questions/376199/sudo-su-vs-sudo-i-vs-sudo-bin-bash-when-does-it-matter-which-is-used

Improve this answer
4
  • That way I need to know the users password :/ also not sure if the ssh keys will be forwarded then. But the main problem here is that the other user has no shell-access on his own. It's set to bin/false :(
    – Nalrakesh
    May 22, 2014 at 22:39
  • @Nalrakesh Ah so it would. Unless you made a different user/group that had rights to everything, and just logged in with them. Or set rights to the file for only certain group full, add full rights to the files for that group, and add that user needed in question to the new group (if that makes sense)
    – No Time
    May 22, 2014 at 22:48
  • It does make sense, but setting the web-accessible directory to 775 seems kind of risky. :/
    – Nalrakesh
    May 23, 2014 at 7:05
  • Is there some sort of Access Control List on this? I guess I was assuming you had LDAP or some other permission handling protocol/software
    – No Time
    May 23, 2014 at 15:14
0

On a, try ssh other_user@localhost. In theory that should forward your ssh-agent connection again, allowing other_user to use it. However this will still not work with /bin/false as other_user's shell.

I don't think there is way without root privileges to bypass that a restricted shell (nor should there).

From man su:

If the target user has a restricted shell (i.e. the shell field of this user's entry in /etc/passwd is not listed in /etc/shells), then the --shell option or the $SHELL environment variable won't be taken into account, unless su is called by root.

Improve this answer
2
  • My first user has root privileges of course, but he is not the owner of the folder where the scripts should be called. The directory is web-accessible and used by a webserver, hence I'd really like it to be writable only by a few users.
    – Nalrakesh
    May 23, 2014 at 7:02
  • Ah... well that complicates things. You can easily su --shell /bin/bash to bypass the shell restriction, but unfortunately this works not with ssh.
    – Fabian
    May 23, 2014 at 11:06

You must log in to answer this question.

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