Назад | Перейти на главную страницу

Автоматически менять удаленного пользователя с помощью sshfs

У меня два удаленных сервера, фу и бар. На обоих серверах у меня есть пользователь мерзавец (с разными uid и gid). На обоих серверах установлены дистрибутивы Debian. Оба сервера имеют друг друга. корень Открытый ключ ssh в authorized_keys, поэтому все команды, связанные с ssh, уже работают как шарм.

мерзавец учетные записи были правильно настроены - оболочка по умолчанию установлена ​​в / usr / bin / git-shell, репозитории работают над фу (бар пока не настроен по делу).

Я пытаюсь создать «общий каталог» между фу и бар используя sshfs. На фу У меня есть каталог / home / git. Каталог принадлежит пользователю мерзавец (в данном случае uid / gid 1000). Допустим, я хочу смонтировать эту папку с помощью sshfs на бар в / mnt / foo-git.

В обычном случае я бы просто использовал sshfs git @ foo / mnt / foo-git (на бар), чтобы смонтировать каталог (или использовать fstab, что, кстати, я планирую сделать, как только система заработает). Однако git-shell эффективно не позволяет мне вызывать sftp-server и использовать sshfs самым простым способом.

Немного поигравшись, я решил использовать пользователя root для входа в систему (через ssh), изменить действующего пользователя с помощью su -l и запустить sftp-server. Для этого я создал простой скрипт (на фу) / sbin / git-sftp-server:

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

И использовал следующий вариант с sshfs (бар):

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

Кажется, что команда работает, однако на самом деле она не меняет разрешения сеанса. Когда я создаю файл на бар, на фу файл появляется с владельцем корень. Это становится серьезной проблемой, когда команды git не могут изменять содержимое репозиториев просто из-за базового управления доступом к файлам Linux.

Прямо сейчас я вижу два возможных направления:

  1. Попробуйте принудительно запустить сеанс sshfs с пользователем мерзавец. Это может потребовать от меня возиться с git-shell, но это может быть невозможно
  2. Найдите способ исправить su-ing с пользователем git из корневого сеанса

В любом случае, пока я не смог найти хороший способ решить проблему, но рассчитываю на ваш совет.

Редактировать: Хорошо, после прочтения комментария @AlexStragies (и тестирования нескольких других вещей) выясняется, что мое решение в некотором роде работает. Если я смонтирую файловую систему через sshfs или fstab с +/- следующими параметрами:

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

А затем su -l в git user с «нормальной» оболочкой и создайте файл, uid / gid файла правильно установлен на git @ foo. тем не мение, скажем, я создаю файл / home / git / cat с пользователем root @ foo и привилегиями 644. Пользователь git @ foo, очевидно, не может изменять файл (разрешение отклонено, однако я был удивлен, что он может удалить файл, но я думаю, что это возможно потому что у него есть разрешение на запись в папку). На бар машина, похоже, что файл принадлежит пользователю мерзавец, с правами доступа 644, хотя его настоящий владелец - root @ foo. Теперь оба пользователя мерзавец и корень at foo может изменять файл cat (изменения отражаются на машине фу) хотя файл по-прежнему принадлежит корень с разрешениями 644.

Это похоже либо на странный случай повышения привилегий, либо на не совсем работающий обходной путь. Итак, мой вопрос: какой? И если последнее, то что я могу сделать, чтобы должным образом уважать разрешения удаленного пользователя?