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

Насколько безопасно защитить ключ ssh без парольной фразы с помощью параметра «command» в файле authorized_keys?

Бывают случаи, когда использование ключей ssh ​​с пустой кодовой фразой крайне желательно (резервные копии, ...). Хорошо известная проблема заключается в том, что такие ключи безопасны лишь постольку, поскольку они хранятся в ненадежных руках.

Тем не менее, в случае, если они будут скомпрометированы, эти ключи могут быть дополнительно защищены от причинения слишком большого вреда, добавив к ним некоторые параметры на сервере. authorized_keys файл, например:

command="/usr/bin/foo",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAA.....

Теоретически этот ключ можно было использовать только для запуска команды /usr/bin/foo на сервере. Тогда возникает новая проблема, поскольку для каждой команды потребуется специальный выделенный ключ.

По этой причине в Интернете можно найти более разработанный вариант (например, на том же сайте: sshd_config по сравнению с параметром команды authorized_keys), который заключается в установке общего ключа, ограниченного созданным локально скриптом, который будет использовать SSH_ORIGINAL_COMMAND переменная окружения, установленная ssh.

(Ограниченное) ключевое объявление в authorized_keys тогда будет выглядеть так:

command="/usr/local/bin/myssh",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAA.....

и myssh сценарий будет выглядеть так:

#!/bin/sh
msg="Command not allowed with this key"
case "$SSH_ORIGINAL_COMMAND" in
  *\&*)
      echo $msg
      ;;
  *\(*)
      echo $msg
      ;;
  *\{*)
      echo $msg
      ;;
  *\;*)
      echo $msg
      ;;
  *\<*)
      echo $msg
      ;;
  *\`*)
      echo $msg
      ;;
  *\|*)
      echo $msg
      ;;
  rsync\ --server*)
      # optionnally check for extra arguments
      # ....
      # then
      $SSH_ORIGINAL_COMMAND
      ;;
  some-local-script*)
      # optionnally check for extra arguments
      # ....
      # then
      $SSH_ORIGINAL_COMMAND
      ;;
  *)
      echo $msg
      ;;
esac

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

Заранее спасибо !

Фактически, gitolite использует тот же метод для аутентификации пользователя (идентифицирует базу пользователей по используемому ключу SSH) и ограничивает то, что пользователь может запускать (фактически только команда, запускающая gitolite).

gitolite используется kernel.org для управления доступом к своему репозиторию git, поэтому я думаю, что этот метод должен быть достаточно надежным.1

Это зависит от безопасности сценария-оболочки и разрешенных команд.

Сценарий-оболочка должен защищать от попыток выполнить несколько команд (например, allowed-command blah; other-command) или злоупотребление PATH различия. Я бы, вероятно, написал сценарий для вызова разрешенных команд с их полным путем и использовал exec чтобы предотвратить дальнейшую интерпретацию предоставленной клиентом команды:

set -- $SSH_ORIGINAL_COMMAND
case "$SSH_ORIGINAL_COMMAND" in
    rsync\ --server*)
        shift 2;
        exec /usr/bin/rsync --server "$@"
        ;;

Вам также необходимо убедиться, что у разрешенных команд нет механизма для выполнения других команд. Например, rsync -e "other-command" заставит rsync выполнить другую команду. (--server должен предотвратить это в приведенном выше сценарии.)

Я не являюсь экспертом по ssh или безопасности, но, исключая какую-либо ошибку в ssh или вашем скрипте myssh, я не вижу никаких проблем с безопасностью. Но вы знаете эту старую пословицу: лучше перестраховаться, чем сожалеть. Возможно, вы также могли бы настроить фильтрацию на основе IP, если применимо.