☰

如何进一步保护 SSHauthorized_keys 中使用的这两个脚本的安全？

tag-icon • tag-icon shell-script ssh security
如何进一步保护 SSHauthorized_keys 中使用的这两个脚本的安全？

itunes.sh：

#!/bin/sh

set -f
set -- $SSH_ORIGINAL_COMMAND

case "$1" in
  /home/dimm0k/progs/scripts/*)
    ;;
  *)
    exit 1
esac

command="${1#/home/dimm0k/progs/scripts/}"
shift
case "$command" in
  */*)
    # Simplest is to reject anything with a slash...
    ;;
  .*)
    # ...and anything starting with dot.
    # If you need to whitelist subdirectories of /home/dimm0k/progs/scripts
    # then you need much more sophisticated pathname parsing and care.
    ;;
  *)
    ;;
esac

exec "/home/dimm0k/progs/scripts/$command" "$@"

rsync.sh：

#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
  *\&*)
    echo "Rejected 1"
    ;;
  *\;*)
    echo "Rejected 2"
    ;;
    rsync*)
    $SSH_ORIGINAL_COMMAND
    ;;
  *true*)
    echo $SSH_ORIGINAL_COMMAND
    ;;
  *)
    echo "Rejected 3"
    ;;
esac

答案1

您的问题并没有多大意义，因为您尚未定义任何安全目标。 “这是安全的”毫无意义：针对什么安全？安全目标类似于“不知道私钥的对手无法访问系统上的任何文件”（您的方案显然满足了这一点）或“除了该密钥之外无法访问系统的对手只能访问下面的文件/home/dimm0k而不能运行任意命令”（您的方案不满足）。

话虽如此，这里有一些您似乎没有想到的事情。

  • 在itunes.sh脚本中，您有注释声称某些内容被拒绝，但您的case语句均不包含任何代码，因此整个命令case是无操作，并且对命令的唯一过滤是它必须以 开头/home/dimm0k/progs/scripts/。
  • 在rsync.sh脚本中，您允许任何以 开头的命令rsync，而不仅仅是rsync其本身。
  • 在rsync.sh剧本中，拒绝&又;是离奇的。该字符串不是由 shell 计算的，因此如果您考虑shell 语法中&和的含义，它们是无关紧要的。;如果该字符串由 shell 执行，则许多其他字符将是相关的，特别是`$|<>.
  • 在任一脚本中，您都允许调用者将任意选项传递给最终执行的命令。对于itunes.sh，这允许什么取决于您在 中拥有什么/home/dimm0k/progs/scripts/，但这可能不好。使用rsync.sh，这允许执行任意命令，例如通过传递-e选项。
  • 您不采取任何措施来限制用户可以访问哪些文件。特别是，如果用户可以写入~/.ssh/authorized_keys其中的任何文件，/home/dimm0k/progs/scripts/那么他们可以利用命令覆盖它，然后再次登录以执行他们上传的内容。

总而言之，这些脚本并没有真正执行我所看到的任何安全措施。出于安全目的，请将它们视为允许用户运行任意命令。从功能上讲，命令修改很奇怪，并且当您的脚本被合作用户使用时，可能会导致进一步的逃逸错误。

如果您打算对用户施加一些限制，那么您就远远没有做任何有用的事情。忘记自己动手并使用强大的工具，例如RSSH或者斯波利。还要调查 chrooting。如果可能，请使用具有最小权限的专用帐户。为了更好的隔离，允许用户仅在容器或虚拟机内登录。

相关内容