使用SSH安全地将本地文本文件中的字符串发送到远程命令

Question

以下情况发生在Ubuntu 18上。

我需要使用SSH自动使用存储在本地计算机上的文件中的密码来实现gpg-agent的远程播种。

密码需要以这样一种方式来处理，以便其他爱管闲事的用户不能很容易地查看它--主要是在远程服务器上，但是它也应该在本地框上是安全的。

问题是通用的，而不是特定于GPG的--如何使用ssh将字符串安全地传递到运行在远程服务器上的编程中？

我知道在命令行中使用ps -ef在本地(ssh)和远程计算机(bash -c)上都可以看到密码。所以我必须避免这样做。

我还知道，将密码存储在环境变量中意味着可以看到进程的初始env，因为可以使用cat /proc//environ和gdb来查看当前状态。因此，如果转发本地环境变量，则可以在本地计算机或远程计算机上看到详细信息。因此，这并不理想，特别是因为我不能严格控制其他人对远程计算机上SSH用户帐户的访问。

经过一段时间的阅读和实验，我想出了下面的内容--它确实有效！您可以假设seed.txt缺少本地服务器上的根访问权限，文件是安全的(或者至少与我的SSH密钥一样安全)。

注- seed.txt不存在于远程服务器上，只存在于本地服务器上，因此必须将其内容发送到远程服务器。

SSH连接使用密钥，因此不需要密码。

#!/bin/bash
ssh -T my-server < /dev/null
printf '%s\n' "$(cat seed.txt)" | /usr/lib/gnupg2/gpg-preset-passphrase -c 123456789
EOSSH

在本地机器上使用ps -ef只会产生ssh -T my-server，因为要远程执行的实际命令被传送到stdin，而不是使用ssh命令行。

同样，cat命令行只显示文件名。我相信，printf是一个内置的命令，因此不会出现在ps中。我相信printf是在远程机器上执行的？

在远程服务器上，ps将只显示/usr/lib/gnupg2/gpg-preset-passphrase -c 123456789，因为密码是使用stdin重新输入的。

我没有直接使用环境变量，所以这里不应该有任何问题。我有点担心SSH环境变量会暴露什么东西？

我的问题是--我的方法是否明智/简单/安全(假设根访问不受损害)，是否存在明显的问题，如果有，建议的解决办法是什么？

我唯一能做到的其他选择是使用expect，但考虑到ssh和gpg-preset-passphrase似乎都乐于接受输入为stdin，而不是交互的，那么使用expect似乎太过分了吗？

<#>更新

下面是一些非常有用的答案，谢谢！我越多地思考这个问题，我就会对这个问题再做一点小小的修改--也许我必须接受这个问题--如果确定了其他用户，那么这个帐户的其他用户在一个Linux帐户中设置的环栅栏就永远是无法实现的？这似乎通常是正确的逻辑前提，但如果我想为其他用户(该帐户)拆分一个(每个帐户)gpg代理，而不让他们访问凭据来完成实际的分拆(我认为gpg-agent总是针对每个用户？)，我必须在帐户内这样做，对吗？我如何做到这一点，而没有相同帐户的用户能够达到顶峰我正在做的事情.简单的回答似乎是--你可以让他们很难达到顶峰，但也许永远不可能？据我所见，从不同的帐户中播种一个gpg-agent，供其他帐户的用户使用是不可能的？

Answer 1

printf可能不是一个内置的，取决于远程系统上的sh。Linux上的bash和dash将其作为内置(echo 'printf --version' | ssh host)运行，而OpenBSD上的sh则不运行。更值得关注的是，“我无法严格控制其他人对远程计算机上SSH用户帐户的访问”；那些用户(拥有足够的技能)可以在没有根访问的情况下做一些顽皮的事情：

• 如果存在并且知道您的公钥，则可以通过command="..."文件中的一个~/.ssh/authorized_keys条目运行其他内容。
• bash确实读取shell rc文件，即使使用printf- and cat-free ssh host < seed.txt command表单也是如此，这样它们就可以执行export LD_PRELOAD=/something/naughty.so，并且当有东西试图执行gpg-preset-passphrase时，库可能复制其他地方的标准输入，或者做一些有趣的事情。