以下发生在 Ubuntu 18 上。
我需要自动化偏僻的gpg-agent
使用存储在我的文件中的密码短语播种当地的使用 SSH 的机器。
密码需要以这样的方式处理,以便其他爱管闲事的用户不能轻易查看它——主要是在远程服务器上,但它在本地机器上也应该是安全的。
问题是一个普遍问题,而不是 GPG 特定的问题 - 如何使用 安全地将字符串传递到远程服务器上运行的程序中ssh
?
我知道将密码放在命令行上意味着ps -ef
在本地 ( ssh
) 和远程计算机 ( bash -c
) 上使用都是可见的。所以我必须避免这种情况。
我还知道将密码存储在环境变量中意味着进程的初始环境可以被视为cat /proc/<pid>/environ
并且gdb
可以用于查看当前状态。因此,如果转发本地环境变量,则可以在本地计算机或远程计算机上看到详细信息。所以这并不理想,特别是因为我无法严格控制其他人对远程计算机上 SSH 用户帐户的访问。
经过一些阅读和实验后,我得出了以下结论——它确实有效!您可以假设seed.txt
缺少chmod 400
在本地服务器上具有 root 访问权限的人,该文件是安全的(或者至少与我的 SSH 密钥一样安全)。
注意 -seed.txt
不存在于远程服务器上,仅存在于本地服务器上,因此必须将其内容发送到远程服务器。
SSH 连接使用密钥,因此不需要密码。
#!/bin/bash
ssh -T my-server <<EOSSH > /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
我没有直接使用环境变量,所以这里不应该有任何问题。我有点担心SSH环境变量会暴露一些东西吗?
我的问题是 - 我的方法是否明智/简单/安全(假设根访问权限未受到损害),是否存在任何明显的问题,如果是,建议的解决方法是什么?
我设法开始工作的唯一其他选项是使用,expect
但考虑到两者ssh
,并且gpg-preset-passphrase
似乎很乐意接受输入作为标准输入而不是交互方式,使用似乎有点过分了expect
?
更新
下面是一些非常有用的答案,谢谢!我想得越多,我就会稍微重新思考这个问题——也许我必须接受,如果其他用户确定的话,在单个 Linux 帐户内与该帐户的其他用户隔离的东西总是无法实现的?这似乎通常是正确的逻辑前提,但如果我想为(该帐户的)其他用户启动(每个帐户)gpg-agent,而他们无法访问凭据来自己进行实际的启动(gpg-我认为代理始终是每个用户?),我必须从帐户本身内部执行此操作,对吗?如果同一帐户的用户无法达到我正在做的事情的峰值,我该如何做到这一点......简短的答案似乎是 - 你可以让他们很难达到峰值,但可能永远不可能?据我所知,gpg-agent
从另一个帐户播种以供另一个帐户的用户使用是不可能的吗?
答案1
printf
可能不是内置的,具体取决于sh
远程系统。bash
在dash
Linux 上将其作为内置程序运行 ( echo 'printf --version' | ssh host
),sh
而在 OpenBSD 上则不然。更大的担忧是“我无法严格控制其他人对远程机器上的 SSH 用户帐户的访问”;这些用户(具有足够的技能)可以在没有 root 访问权限的情况下做一些顽皮的事情:
- 如果有并且他们知道您的公钥,他们可以通过文件
command="..."
中的条目运行其他内容~/.ssh/authorized_keys
bash
printf
即使使用-and-cat
-形式也会读取 shell rc 文件,ssh host < seed.txt command
因此它们可以export LD_PRELOAD=/something/naughty.so
并且该库可能会在其他地方复制标准输入或在尝试执行某些内容时执行有趣的操作gpg-preset-passphrase