免责声明：
在将其标记为重复之前仔细阅读这个问题将是非常好的。我读过许多其他问题（这里，在 superuser.com、serverfault.com 等），所有问题都涉及 SSH 找不到 /dev/tty，但没有一个与keychain，这实际上应该可以防止这个问题。
话虽如此：
我有一个 Linux (Debian Stretch) 路由器，它通过pppoe.我的提供商为我提供了一个不时变化的动态 IP 地址。每当发生这种情况时，路由器都应该通过 SSH 在另一台主机上运行脚本。
我已使用公钥身份验证在路由器和其他主机上正确设置 SSH。 SSH 密钥受密码保护。
keychain此外，我已经按照建议设置了这里。根据我对此页面（和其他页面）的理解，向任何 SSH 客户端keychain“提供”相同的过程；ssh-agent当我登录时，它会启动ssh-agent（如果还没有运行）并询问（或让 ssh 询问）密码；从那时起，SSH 密钥就位于ssh-agent内存中，并且可供其他进程随时使用。
这适用于以下例外情况：
我已将脚本放入/etc/ppp/ip-up.d;该脚本包含（除其他外）以下几行：
eval `/usr/bin/keychain --noask --agents ssh --eval id_rsa_ipupdate`
ssh -i /root/.ssh/id_rsa_ipupdate [email protected] '/path/to/remote/command'
尽管每次提供商分配新的 IP 地址时脚本本身都会按预期执行，但 SSH 命令会失败，即偏僻的主机没有被执行。我花了一段时间来调试这个，但是在将pppd其调试消息记录在一个单独的文件中之后，我终于找到了原因。 pppd 调试消息中的一些相关行：
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug2: input_userauth_pk_ok: fp SHA256:BZSkP9mMIB+cCi5WfgYnqT2QmskTgsKHsWuNXHxIQu0
debug3: sign_and_send_pubkey: RSA SHA256:BZSkP9mMIB+cCi5WfgYnqT2QmskTgsKHsWuNXHxIQu0
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug2: no passphrase given, try next key
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
因此 SSH 找不到 /dev/tty，这可能是正常的，因为pppd在这种情况下它是从内部执行的，因此无法从键盘读取密码。到目前为止，一切都很好。
但关键点是：ssh-agent尽管 SSH正在运行、由其管理keychain并且密钥随时可用，但为什么 SSH（显然）想要从键盘读取密码？
请注意上面脚本片段中的第一行。它应该确保SSH_AUTH_SOCK和SSH_AGENT_PID被正确设置和导出。
另请注意，当我从命令行运行该脚本时，该脚本可以完美运行（无需输入密码）。
为了让事情绝对清楚：我首先登录路由器。由于我已按照其主页上的建议进行设置keychain，因此在登录时会立即要求我输入密码。然后从命令行调用我的脚本时，它会按预期工作，而无需询问密码。但是当 调用该脚本时pppd，SSH 线路失败。
有人可以解释一下为什么 SSH 需要 /dev/tty 尽管它可以从 ssh-agent 加载密钥，以及如何解决这个问题？
PS 是的，我可以接受这样一个事实：路由器重新启动后脚本将不可避免地失败，直到我至少登录一次:-)
编辑1
我做了进一步的研究并注意到以下内容：
eval `/usr/bin/keychain --noask --agents ssh --eval id_rsa_ipupdate`
当由于公共 IP 地址的更改而ssh-agent执行脚本时，上面的脚本肯定会创建第二个进程。pppd这意味着keychain由于某些奇怪的原因找不到第一个（具有可用的 SSH 密钥）。
同样，只有当脚本由pppd;执行时才会发生这种情况。当我从命令行调用脚本时，一切都很好。
我现在正在考虑打开错误报告或类似的东西。顺便说一句，我的keychain版本是2.8.2.