I have two remote servers, foo and bar. On both servers I have a user git (with different uid and gid). Both servers are running Debian distributions. Both servers have their each others' root ssh public key in authorized_keys, so all ssh-related commands already work like a charm.

git accounts have been properly configured - the default shell is set to /usr/bin/git-shell, the repositories are working on foo (bar is still unconfigured in the matter).

I'm trying to create a "shared directory" between foo and bar using sshfs. On foo I have a directory /home/git. The directory belongs to user git (uid/gid 1000 in this case). Let's say I want to mount this folder using sshfs on bar at /mnt/foo-git.

In normal case, I would just use sshfs git@foo /mnt/foo-git (on bar) to mount the directory (or use fstab, which by the way is what I plan to do once I get the system working). However, git-shell effectively prevents me from invoking sftp-server and using the sshfs in the simplest way.

After fiddling around a little, I decided to use the root user to log in (through ssh), change the effective user with su -l, and start sftp-server. To achieve this, I created a simple script (on foo) /sbin/git-sftp-server:

/bin/su -l git -s /bin/bash -c /usr/lib/openssh/sftp-server

And used the following option with sshfs (bar):

sshfs root@foo /mnt/foo-git -o sftp_server=/sbin/git-sftp-server

The command seems to work, however it does not really change the permissions of the session. When I create a file on bar, on foo the file appears with owner root. This becomes a serious problem, when git commands can't change the contents of the repositories, simply because of the basic Linux file access control.

Right now, I see two possible directions:

  1. Try to force sshfs session with user git. This may require me to fiddle around the git-shell, but might not be impossible
  2. Find a way to fix su-ing into user git from a root session

Either way, so far I couldn't find a good way to solve the problem, but I count on your advice.

Edit: OK, After reading @AlexStragies comment (and testing few other things) it turns out, that my solution is somewhat working. If I mount the filesystem through sshfs or fstab with +/- the following options:

root@foo:/home/git  /mnt/foo-git    fuse.sshfs  defaults,_netdev,uid=998,gid=998,IdentityFile=/root/.ssh/id_rsa,allow_other,sftp_server=/sbin/git-sftp-server" 0 0

And then su -l into git user with a "normal" shell and create a file, the uid/gid of the file is set properly to git@foo. However, let's say I create a file /home/git/cat with user root@foo and privileges 644. User git@foo obviously cannot modify the file (permission denied, however I was surprised he can remove the file, but I guess that's possible because he has write permission to the folder). On bar machine, the file appears to be owned by the user git, with permissions 644, although it's real owner is root@foo. Now, both users git and root at foo can modify the file cat (with the changes reflected on machine foo) although the file is still owned by root with permissions 644.

This seems like either a weird case of privilege escalation, or a not-really-working workaround. So, my question now is: which one? And if the latter, then what can I do to properly respect the remote user's permissions?

  • if you ssh-connect to bar as user git, specifying a different shell, say /bin/bash, can you then sshfs mount the desired folder from foo in a subdirectory of your home on bar? Or can user git@bar only run the git-shell? – Alex Stragies Aug 27 '15 at 20:22
  • @AlexStragies I will investigate that more thorougly tommorow, although I don't see how exactly this helps. user git@bar can run other commands if I first log-in as another user, and then su -l onto him. I see two problems with this approach. If I try to mount the directory as git@foo, I shall run into the same problems with git-shell restricting my commands. If I mount as root@foo, I need to authorize git@bar's keys for logging as root at foo, which might be a huge security risk... – Marandil Aug 27 '15 at 21:48
  • @AlexStragies somewhat good idea showed that the case was indeed working, but in an unexpected way. I made an edit to the question with an extensive explanation. – Marandil Aug 28 '15 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.