#1 楼
简而言之：是更多详细信息...
如果连接到我的机器，则不知道我是否正在运行普通的
ssh服务器，已被修改以写出将要通过的密码。 是的，是的。永远不要将您的密码发送到不受信任的服务器。该计算机的所有者可以很容易地将其配置为记录所有尝试输入的密码。 />
评论
正确。默认情况下，标准sshd不记录密码。 （如果您输入密码作为登录名，则将其记录下来，但这是另一个问题）。标准的sshd是安全工具，因此不会记录这样的凭据:-)
–斯蒂芬·哈里斯（Stephen Harris）
16 Sep 15'0:06
使用公钥/私钥对的另一个原因...
– Gerrit
16/09/15'8:33
我一直在想我的密码使用了一段时间，最近我才发现，尝试登录到错误的服务器将是向恶意服务器管理员透露我的密码的好方法。
–vfclists
16 Sep 15'在8:39
@vfclists登录到错误的服务器也是您的sshd客户端为每个服务器存储指纹的原因。首次连接时，您会接受该指纹，然后如果指纹不匹配，则会收到一个巨大的警告，应予以注意。
– hometoast
16 Sep 15'在10:43
更好的建议：永远不要对ssh使用密码验证。该协议具有pubkey auth的理由非常充分。用它！
–R .. GitHub停止帮助ICE
16 Sep 15 '16：52
#2 楼
是。建立加密连接后发送密码，但是远程服务器以纯文本格式获取密码。使用SSH密钥。
如果您的计算机无法接受密钥，那么一种解决方案是创建一个安全存储密码的工具，然后使用
sshpass始终根据服务器发送正确的密码您正在连接。完全傻了。在过去十年左右的时间里，Linux和BSD系统中使用了两种不同的密码哈希（存储）格式（crypt（3）），这些格式都不需要客户端的支持。 尽管这也部分是由于历史原因（即一直如此）。有更好的质询响应身份验证协议，即使密码也可以使用。例如，SRP，在身份验证过程中为双方提供了共享的机密。它已为某些SSH服务器实现，但是OpenSSH的修补程序适用于（非常旧）版本。
评论
用于密码认证的质询-响应协议的问题在于其中一些要求服务器以纯文本格式存储密码。如果质询响应协议确实允许服务器存储哈希密码，那么它很可能需要非常特定的哈希算法。
–卡巴斯德
16 Sep 15 '22：30在
密码通常以“明文”发送（即实际上不是明文发送的，而是仅具有底层SSH | TLS |所提供的保护）。如果系统要求将密码散列到客户端并发送散列，则服务器将无法获得实际密码，而是将访问权限授予任何可以提供密码散列的人，从而使散列密码等效。
–黑光闪耀
16-09-16在20:43
@BlacklightShining确实存在零知识密码证明，但在SSH中未使用，因为没有办法为它们使用标准密码数据库，也没有使用基于密钥的身份验证的真正意义。
–Random832
16/09/17'3:26
在哪里可以看到用于身份验证的密码？它们不在/var/log/auth.log中，那么在哪里？
–アレックス
16-09-17在6:37
OpenSSH将不会记录密码，否则将失败。 （我对其他SSH服务器不是很熟悉。）在几乎所有合法的安装中，故意提供密码所固有的风险将抵消它可能提供的任何价值，其中某些可能是由输入错字的合法用户提供的。或尝试使用其他明文形式的错误但正确的密码。但是，如果您有充分的理由这样做，则修补OpenSSH很容易。
–musicinmybrain
16年9月18日在20:36
#3 楼
为了建立斯蒂芬·哈里斯（Stephen Harris）的答案，这是我构建的实时视图，该视图显示了通过ssh（某种蜜罐）连接到盒子时，经过修改的PAM身份验证脚本将能够捕获的内容。我使用了PAM库lib-storepw的修改版本。https://livesshattack.net
https://livesshattack.net/about
评论
万一链接不可用，则主要是链接的答案会被皱眉（听起来您个人还是维护此站点）。您应该描述一下如何使用针对读者的身份验证脚本来管理此操作。
–世纪
16 Sep 17'3:49
它不再工作了，我发送了一个很大的字符串作为密码，我想可能已经破解了，对不起：-/
–scottydelta
16-09-18在9:10
@scottydelta尽管我没有研究过，但是对PAM模块或SSH守护程序本身可以接受的身份验证密码大小可能存在缓冲区限制。该站点仍可以按我的预期工作，尽管确实可以处理sshd或PAM模块接受的缓冲区限制。
– William S.
16 Sep 19 '15：28
出于兴趣，修改后的lib-storepw的源可供其他人使用吗？
–蒂姆·弗莱彻（Tim Fletcher）
16-09-20在9:10
#4 楼
SSH是一种需要相互信任的协议。这就是为什么OpenSSH客户端维护一个known_hosts文件以实现其对首次使用方案的信任的原因。当您尝试登录SSH服务器时，无论谁提供了软件或提供了哪些数据配置为登录，则您正在参与某些身份验证过程。使用密码验证时，您正在将密码传输到该服务器。这就是为什么推荐使用非对称加密（公共密钥，证书）的原因之一-公共密钥加密极大地降低了泄露凭据的风险。 （尽管如果使用ssh-agent转发或类似的方案，可能无法保护您免受MitM攻击。）
评论
SSH不需要相互信任，或者至少不需要对称信任。重要的是要精确：known_hosts是关于真实性，而不是信任。如您所指出的，将公钥放置在信任度较低的主机上是安全的。的确，假设您不重复使用该密码，那么使用密码登录也是“安全的”。 （当然，它仅与信任服务器的程度一样安全。）即使基于主机的ssh登录也依赖于非对称信任。
– markhahn
16-09-23在15:41
评论
SSH密码身份验证是否为服务器提供密码？在ssh客户端中，您首先对服务器进行身份验证，然后说“我相信我可以告诉我该服务器的密码”。下次，请密切注意您首先看到的消息：“无法确定X的真实性。RSA密钥指纹是Y您确定Z吗？（是/否）”每次自动回答是。
可以在OpenSSH中默认将PasswordAuthentication设置为no，并且仅在受信任的服务器上启用（如果需要）。结合严格的主机密钥检查，这应该可以在很大程度上保护您免于暴露密码，但这当然是为了方便。
@kubanczyk，如果您想通过SSH连接到“ internal-www.my-company.com”，但无意中输入“ ssh www.my-company.com”，则该提示将无法保护您-两台服务器可能都是在您信任的列表中，只是其中一个由您管理，另一个由第三方管理。
@ hobbs，ChallengeResponseAuthentication也不行，我想