允许普通用户使用无法读取的私钥进行SSH

假设我有一台机器（这里称为客户机器），只允许一小部分人（称为支持人员）通过SSH（仅支持一个机器）一个帐户（支持访问帐户）进入。

支持人员只能使用密钥登录客户的计算机。此外，支持人员可以发展，因此不允许离开支持人员的任何人登录任何客户计算机。因此，禁止员工阅读用于登录客户机器的私钥。另外，禁止authorized_keys在客户计算机上修改文件。

为了实现该配置，我想到了使用支持人员登录（使用LDAP身份验证，但这是另一个问题）并且包含私钥的SSH代理的想法。

问题是：如何允许支持人员在无法读取SSH私钥的情况下使用它？

我相信我必须使一个守护程序在代理计算机上以root用户身份运行，该守护程序将接受用户的请求并为他们打开SSH会话，但是我不知道该怎么做。有任何想法吗？

我建议几个选择。

1. 保护ssh密钥，并要求在sudo支持团队方面使用。您可以使用包装器透明地执行此操作。打电话给包装器说，/usr/local/bin/ssh-support并使其包含如下内容（未经测试）：

   #!/bin/bash
   export PATH=/usr/local/bin:/usr/bin:/bin
   export IFS=$' \t\n'
   export SUSER=ssupport
   
   # Restart if not running under sudo
   test "X$1" != 'X-S' && exec sudo -u "$SUSER" /usr/local/bin/ssh-support -S "$@"
   shift
   export SHOME="$(getent passwd "$SUSER" | cut -d: -f6)"
   
   # Extract single argument as hostname LABEL and validate that we have
   # an RSA private key for it. The target username, real hostname, port,
   # etc. can be defined in ~/.ssh/config for the user $SUSER (ssupport)
   label="$1"
   idfile="$SUSER/.ssh/id_rsa_for_$label"
   cgfile="$SUSER/.ssh/config"
   
   ok=true
   [[ "$label" =~ '/' ]] && { echo "Invalid label: $label" >&2; ok=; }
   [[ ! -s "$idfile" ]] && { echo "Missing identity file: $idfile" >&2; ok=; }
   [[ ! -s "$cgfile" ]] && { echo "Missing configuration file: $cgfile" >&2; ok=; }
   
   if test -n "$ok"
   then
       logger -t ssh-support "$SUDO_USER requested ssh to $label"
       exec ssh -i "$idfile" -F "$cgfile" "$label"
   fi
   exit 1
   

   这将需要在sudoers文件中输入一个条目，以允许support组中的用户使用该工具。此命令允许他们以用户身份运行该ssh-support工具ssupport-必须创建该用户。它不授予任何root特权。

   %support ALL = (ssupport) /usr/local/bin/ssh-support

   如果您对支持用户不需要提供自己的密码来运行该工具（如sudo脚本本身内的调用所要求的）感到满意，则可以修改sudoers定义，因此：

   %support ALL = (ssupport) NOPASSWD: /usr/local/bin/ssh-support

   假设您PATH包含/usr/local/bin/，则可以通过调用它ssh-support clientname。同时假设你已经创建的ssupport用户作为/home/ssupport您将创建/home/ssupport/.ssh/id_rsa_clientname并/home/ssupport/.ssh/id_rsa_clientname.pub作为证书对，并在主机条目/home/ssupport/.ssh/config为clientname所定义的用户，主机，端口等为目标机器。您可能会明确禁用X11转发，端口转发等。和往常一样，该/home/ssupport/.ssh目录需要使用权限保护0700。

2. 为每个支持人员提供他们自己的本地用户帐户，并让每个人使用自己的专用ssh密钥来访问客户端的服务器。当某人离开支持小组时，您将从客户的服务器中删除其ssh密钥。这意味着您不再需要担心阻止您的员工知道私密ssh密钥。

您真正想做的是使用SSH CA和每个支持人员使用的签名密钥（它们应该有自己的ssh密钥，例如通行证），并配置客户端的服务器以TrustedUserCAKeys /etc/ssh/users_ca.pub在/ etc / ssh / sshd_config中使用。这样，服务器将接受由CA密钥签名的任何密钥（您可以访问），并且您甚至可以不动用authorized_keys即可撤销不再受支持的人员的密钥。

快速搜索“ ssh ca”指向此教程：https : //www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with -ubuntu（向下滚动至“如何配置用户密钥”）-尽管本教程提到了Ubuntu，它与发行版无关，但是您需要支持SSH CA的OpenSSH的全新版本

关于该主题的另一个不错的博客条目是https://ef.gy/hardening-ssh（向下滚动到“ SSH证书”）。

请特别注意，您可以在有限的时间内对密钥进行签名，因此密钥将自动失效！

对于通过sudo或setuid-executable（针对某个特殊用途的非root帐户）调用的ssh的包装脚本，有几个不同的答案。正如nkms所说，将所有args传递给ssh可使用户使用我们要保护的ssh密钥执行任意操作。有些人提出的另一种极端情况是仅允许主机名。

OP说管理员需要能够上传内容。

您可能有两个不同的fixed-args-ssh包装器。一个用于登录shell，另一个用于scp。除了主机名（和要上传的文件名）外，没有用户提供的args。

或者是一个包装器脚本，该包装器脚本使用getopt自身来解析非常有限的选项，并将其插入到大多数固定的ssh命令中。忽略（或错误）无法识别的选项将是解决之道。

不要尝试过滤掉“危险的” ssh选项，只需编写一个包装程序就可以完成两件事：交互式登录或上载文件（本地和远程文件名）。我想您仍然需要在那里进行消毒。

实际上，这仍然容易出错。您必须找到一种方法来阻止用户将持有ssh键的文件作为本地文件提供。因此，您仍在尝试考虑需要禁止的所有内容，而不是从不允许任何内容开始。这将是确保文件名不包含任何@或的开始:。

如果设置SSH代理服务器，则可以安排职员用户的shell（在中/etc/passwd）未设置为bash之类的shell，而是设置为不允许shell访问的简单脚本。相反，它将要求输入目标主机名（read target），然后输入exec ssh "support@$target"。

请注意，使用这样的代理可能会使使用工具（例如，scp向客户计算机传输文件或从客户计算机传输文件）变得困难。这可能是一个问题或优势！

您的支持人员始终仅通过该代理计算机进行连接，并且仅通过该代理计算机进行连接，因此客户端可以使用HostbasedAuthentication简单地对代理计算机进行身份验证。

假设代理服务器是supporters.pc您提供的支持customer.pc

customer.pc将有Hostbase验证是在/etc/ssh/ssd_config，supporters.pc中列出/etc/ssh/shosts.equiv，并在其公共密钥/etc/ssh/ssh_known_hosts。

当您的支持人员登录到support@supporters.pc并执行时ssh customer.pc，它将生成ssh-keysign（8）（需要设置为setuid），该文件将使用您无法读取的文件和向supporters.pc提供证明连接确实来自supporters.pc。由于customer.pc信任supporters.pc，因此您的工作人员将作为支持登录。

使用包装器二进制文件

对于此特定用例（请参阅下面的重要说明），一种可能性是创建一个support-ssh专门用于这些传出SSH连接的用户（例如），然后安装一个小型包装器execs /usr/bin/ssh。

• 不要复制+ chmod ssh二进制文件本身，因为您将不记得每次应用安全更新时都要重新复制它。
• 并且不要使用root特权更高的用户，因为我相信显而易见的原因。

这是功能上等效的替代方法，用于通过以下折衷sudo来将特权提升到support-ssh帐户的特权：

• 比sudo，它更小，更精简，因此出现配置错误的风险比您预期的要小。
• 正确编码是您的责任-仅当您非常小心并且（理想情况下）具有安全性至关重要的编码经验时，才可以这样做。
• 可以对其进行定制，使其比sudo（例如，但编写的代码越多，就需要对安全性进行审核的代码越多）就越具体。

包装程序二进制文件应设置HOME为support-ssh用户的主目录，以便ssh可以选择适当的ssh_config私钥。但是，不应允许调用用户阅读~support-ssh/.ssh/其内容。

包装程序可以很简单：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    setenv("HOME", "/home/support-ssh", 1);
    /* allow only a single, non-option argument */
    if (argc!=2 || *argv[1]=='-') {
        fprintf(stderr, "Usage: %s <hostname>", argv[0]);
        exit(EXIT_FAILURE);
    }
    execv("/usr/bin/ssh", argv);
    return EXIT_FAILURE;
}

您可能希望限制更多，并检查参数argv[1]是否在一组允许的主机名中。或更严格的限制，并允许（一部分）选项参数。你可能想完全取代环境变量（但保留重要的，如TERM，LC_*等）; 请注意，LD_LIBRARY_PATH并且LD_PRELOAD特别危险。

scp如果需要，可以提供类似的包装程序。

适用说明

该答案解决了该问题的具体情况，即合同规定用户必须遵守程序，并且有违反该程序的制裁措施（例如解雇）。它假定您要防止员工随便复制私钥，而不是阻止坚定的攻击者获得未经授权的访问。

我认为，安全既可以通过技术防御也可以通过非技术防御来实现，并且这里或通过使用这种方法实现的平衡sudo适合当前的情况。