使用authorized_keys 文件中的“command”选项保护没有密码的ssh 密钥有多安全？

Question

有时使用带有空密码短语的 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

我唯一的问题是：可以确定这样一把受保护的钥匙不能从笼子里逃出来吗？

提前致谢 ！

Answer 1

实际上，gitolite 使用相同的方法来验证用户身份（根据使用的 SSH 密钥识别用户）并限制用户可以运行的内容（实际上仅限启动 gitolite 的命令）。

kernel.org 使用 gitolite 来控制其 git 存储库，所以我认为该方法应该非常可靠。1