☰

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

tag-icon • tag-icon security ssh
使用authorized_keys文件中的“命令”选项保护没有密码的ssh密钥有多安全？

有时，使用带有空密码的 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_COMMANDssh 设置的环境变量。

（受限）密钥简介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

我唯一的问题是：能否确定这种受保护的密钥不能用于逃脱走出笼子？

提前致谢 ！

答案1

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

gitolite 被 kernel.org 用于访问控制他们的 git repo，所以我认为该方法应该非常可靠。1

答案2

这取决于包装脚本和允许的命令的安全性。

包装器脚本需要防止尝试运行多个命令（例如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但是应该在上述脚本中阻止这种情况。）

答案3

我不是 ssh 或安全专家，但除非 ssh 或您的“myssh”脚本中存在某种错误，否则我看不出有任何安全问题。但您知道那句老话，小心谨慎总比后悔好。如果适用，也许您还可以配置基于 ip 的过滤。

相关内容