我有大量~/.ssh/config类似这样的条目：
host foo
hostname 1.2.3.4
user bar
identityfile ~/.ssh/private.pem
这让我可以做到这一点：
ssh foo
登录。然后 SSH 检查我是否可以foo使用我的密钥进行访问~/.ssh/private.pem，并让我轻松登录。
但是，在某些系统上，我也有双因素身份验证，即密码。 我可以在我的config文件中指定密码吗？ 这实际上可行吗？还是您不能这样做？
非常感谢 ：）。
答案1
我的简短回答是：我还不能通过 OpenSSH 来确定。
我的长答案是：
这是一个非常好的问题，在我看来很少有人考虑过，更不用说这是一个困难且有时敏感的话题。到目前为止，这两个答案都很好。当然，您可以在 Expect 脚本中“硬编码”您的密码。此外，关于解锁私钥的答案也是有效的。就回答这个问题而言，我认为 Nikolaidis 的答案最接近。
底线是，在使用内置机制进行 ssh 身份验证期间，没有方法以非交互方式在命令行上指定或提交您的密码（我发现的）。
这可能是 RFC 的问题，也可能是实现的问题 - 我不确定。我猜这是实现限制，因为我怀疑任何 RFC 都会指定在过程中必须“如何”处理密码 - 但我可能错了。私钥在某种程度上只是一个非常非常长的密码，它们通常以未加密的形式存储，并且没有与此相关的实现限制。
但要小心。
现在我意识到非对称加密（公钥/私钥）不仅仅是登录远程系统，验证身份的意义也远不止于此。我指的是用户对两种验证身份的方法的感知和使用差异（更多内容请参阅 Daffy 的回答）。
事情是这样的（我的看法）：
如果你正在执行双因素身份验证，那么通常背后有一个原因：有人真的想确保A：由人工进行身份验证，乙：该人确实就是他/她所说的那个人。这可能有充分的理由。
这可能是由于遵守现行法律（萨班斯-奥克斯利法案），在这种情况下，如果有人确定您以造成不当暴露或违反公司政策的方式绕过身份验证 - 例如在审计期间 - 您可能会陷入棘手的境地和/或被解雇。
我的观点是，确保你了解自己在做什么，并记录自己在做什么，以及记录上级的适当批准。但到了那个时候，为什么要绕过这些事情，而只是弄清楚它是否是适合这种情况的适当授权。
在很多情况下，人们都理解并期望远程系统需要代表“用户”与另一个远程系统对话 - 例如传输文件、监控系统、执行备份等。在这些情况下，可以使用公钥/私钥设置单因素身份验证，同样重要的是，其中一些非交互式身份验证机制涉及敏感文件（备份）。
关键（无意双关）是确保在适当的情况下采用适当的身份验证机制。人们需要完成工作，而这需要与强大的安全性相平衡。这就是为什么自密码时代以来，人们发明了/已经发明了身份验证机制 - Kerberos、智能卡、眼球扫描仪等等。每种机制都有优点和缺点。没有一种是完美的（完美是一个主观概念）。
希望有所帮助。
答案2
嗯，我不太确定配置，但你总是可以使用 expect 来包装。比如expect -c 'spawn ssh [email protected] ; expect password ; send "passphrase\n" ; interact'
这样，您就可以通过证书和密码进行身份验证！
答案3
您无法将其添加到配置文件中（即使可以，以明文形式输入密码也不是一个好主意）。正如暗示的那样，您可以使用“expect”，但我不确定您是否遇到了您认为的问题。我遇到的最后一个试图解决这个问题的人没有意识到这种身份验证是如何工作的。
您可能 100% 正确（私钥 + 服务器密码），但您可能只是为了在本地计算机上解锁私钥而输入密码。生成密钥时，它会提示您输入密码。大多数人认为这是对远程服务器进行身份验证，但事实并非如此。它要求您输入您选择的密码来锁定即将创建的密钥。尝试重新创建密钥并将密码留空。这应该可以消除提示您输入的密码。
托马斯