ssh
следует rsh
традиции, используя программу оболочки пользователя из файла паролей для выполнения команд.
Это означает, что мы можем решить эту проблему без ssh
какого-либо вмешательства в конфигурацию.
Если вы не хотите, чтобы у пользователя был доступ к оболочке, просто замените оболочку этого пользователя сценарием. Если вы посмотрите /etc/passwd
внутрь, то увидите, что есть поле, которое назначает интерпретатор команд оболочки каждому пользователю. Сценарий используется как оболочка как для их интерактивного входа ssh user@host
в систему, так и для команд ssh user@host command arg ...
.
Вот пример. Я создал пользователя foo
, оболочка которого представляет собой скрипт. Сценарий печатает сообщение, my arguments are:
за которым следуют его аргументы (каждый в отдельной строке и в угловых скобках) и завершается. В журнале на всякий случай аргументов нет. Вот что происходит:
webserver:~
foo@localhost's password:
Linux webserver [ snip ]
[ snip ]
my arguments are:
Connection to localhost closed.
Если пользователь пытается запустить команду, это выглядит так:
webserver:~
foo@localhost's password:
my arguments are:
<-c>
<cat /etc/passwd>
Наша «оболочка» получает -c
вызов стиля со всей командой в качестве одного аргумента точно так же, как/bin/sh
ее получении.
Итак, как видите, сейчас мы можем разработать сценарий дальше, чтобы он распознавал случай, когда он был вызван с -c
аргументом, а затем анализировал строку (например, путем сопоставления с образцом). Те строки, которые разрешены, можно передать реальной оболочке путем рекурсивного вызова /bin/bash -c <string>
. В случае отклонения может быть напечатано сообщение об ошибке и завершено (включая случай, когда -c
он отсутствует).
Вы должны быть осторожны, когда пишете это. Я рекомендую писать только положительные совпадения, которые разрешают только очень определенные вещи, и запрещают все остальное.
Примечание: если это так root
, вы все равно можете войти в эту учетную запись, переопределив оболочку в su
команде, как это su -s /bin/bash foo
. (Замените оболочку по выбору.) Не-root не может этого сделать.
Вот пример сценария: разрешить пользователю использовать только ssh
для git
доступа к репозиториям в /git
.
#!/bin/sh
if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then
printf "interactive login not permitted\n"
exit 1
fi
set -- $2
if [ $# != 2 ] ; then
printf "wrong number of arguments\n"
exit 1
fi
case "$1" in
( git-upload-pack | git-receive-pack )
;;
( * )
printf "command not allowed\n"
exit 1
;;
esac
gitpath=$(readlink -f "$2")
case "$gitpath" in
( /git/* )
;;
( * )
printf "access denied outside of /git\n"
exit 1
;;
esac
if ! [ -e "$gitpath" ] ; then
printf "that git repo doesn't exist\n"
exit 1
fi
"$1" "$gitpath"
Конечно, мы доверяем , что эти программы Git git-upload-pack
и git-receive-pack
не имеют отверстий или аварийные люки , которые дают пользователям доступ к системе.
Это заложено в такой схеме ограничений. Пользователь аутентифицирован для выполнения кода в определенном домене безопасности, и мы вводим ограничение, чтобы ограничить этот домен субдоменом. Например, если вы разрешаете пользователю запускать vim
команду для определенного файла для его редактирования, пользователь может просто получить оболочку с расширением :!sh[Enter]
.