36

Я хотел бы иметь возможность использовать ключ ssh для аутентификации, но все же ограничить команды, которые могут быть выполнены через туннель ssh.

С Subversion я добился этого с помощью файла .ssh/authorized_keys, например:

command="/usr/local/bin/svnserve -t --tunnel-user matt -r /path/to/repository",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAABIetc...

Я пробовал это с помощью "/usr/bin/git-shell" в команде, но я просто получаю старомодный fatal: What do you think I am? A shell? сообщение об ошибке.

6 ответов6

32

Я мог бы успешно использовать git-shell непосредственно в файле авторизованных ключах без использования дополнительного скрипта.

Ключ заключается в том, чтобы добавить \" вокруг переменной env.

Протестировано в rhel6 openssh-server-5.3p1-70.el6.x86_64:

no-port-forwarding,no-agent-forwarding,command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-dss AAAA...
30

Следующее работает для меня.

В ~/.ssh/authorized_keys:

command="./gitserve",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss AAAAB…

В скрипте ~/gitserve :

#!/bin/sh
exec git-shell -c "$SSH_ORIGINAL_COMMAND"

Обратите внимание, что если вы поместите gitserve где-то, кроме домашнего каталога, вам нужно будет настроить параметр command="./gitserve" в authorized_keys ключе .

5

Решение Grawity можно легко модифицировать для работы, заменив линию

        exec $SSH_ORIGINAL_COMMAND

с линией

        git-shell -c "$SSH_ORIGINAL_COMMAND"

Кавычки решают проблемы, о которых говорилось выше, и замена exec на git-shell кажется более безопасной.

4

git-shell предназначен для использования в качестве оболочки входа в систему, чтобы он получал -c "originalcommand" качестве аргументов. Этого не происходит с "принудительными командами" в OpenSSH; вместо этого принудительная команда передается в настроенную оболочку.

Что вы можете сделать, это написать скрипт, который проверяет $SSH_ORIGINAL_COMMAND и выполняет его. Пример в bash:

#!/bin/bash

SSH_ORIGINAL_COMMAND=${SSH_ORIGINAL_COMMAND/#git /git-}

case $SSH_ORIGINAL_COMMAND in
    "git-receive-pack"*|"git-upload-pack"*|"git-upload-archive"*)
        eval exec $SSH_ORIGINAL_COMMAND
        ;;
    *)
        echo "Go away." >&2
        exit 1
        ;;
esac
1

Для полноты, и поскольку в исходном вопросе не указано, что один и тот же аккаунт должен был использоваться для не-git вещей, очевидный ответ - использовать git-shell как он был спроектирован: установите его в качестве оболочки входа в систему ( то есть с usermod , в /etc/passwd) для этого пользователя ssh.

Если у вас есть одна учетная запись пользователя, которую вы хотите использовать двумя способами:

  • при подключении с ключом аутентификации используйте только для git
  • при подключении с аутентификацией по паролю или с использованием другого закрытого ключа предоставьте полную оболочку

... тогда применяются другие ответы в этой теме. Но если вы можете позволить себе выделить отдельного пользователя для git, то установка его оболочки на git-shell - это самый простой способ ограничить его, и он немного более безопасен, так как не требует дополнительных сценариев оболочки.

1

Я не смог заставить работать решение grawity по той же причине, о которой сообщил Нил Мэйхью (т.е. одинарные кавычки, отправленные клиентом git, вызвали недопустимый $SSH_ORIGINAL_COMMAND - я использую git v1.7.x)

Однако следующее решение, реализованное @moocode, просто работает:

https://moocode.com/posts/6-code-your-own-multi-user-private-git-server-in-5-minutes

Руби FTW! :-)

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .