如果我们发送哈希怎么办？

如果散列是身份验证参数，而不是密码，那么散列就是身份验证参数。

为了更深入地解释该重言式：密码经过哈希处理，因此如果密码的数据存储受到破坏，则没有功能性身份验证凭据。出于这个原因，它是发送到服务器执行计算哈希工作的服务器的密码。发送密码的哈希与使用没有哈希的密码生成器完全相同。

如果有人控制了服务器，您的密码是否会泄露？

他们仍然可以窃取密码，方法是强制身份验证存储生成原始密码，或者更有效地通过更改服务器的守护程序代码来记录您的密码尝试。

有人可以澄清这是否正确吗？

是的，服务器以纯文本形式知道密码是正确的。RFC 4252，第 8 节指定了 SSH 的“密码验证”，它写道（自由引用）：

请注意，[...] 明文密码在数据包 [...] 中传输。

我也想提供一个答案，不是针对问题本身，而是针对

你能设计一个不向服务器发送密码或等于密码的值的协议吗？

答案是肯定的。

您应该确保您的协议执行以下操作：

1. （实现的更多部分）用户必须有一些方法来确认他们没有将密码告诉服务器。如果服务器可以绕过它并显示可以获取其内容的文本条目，那么最智能的协议将毫无意义。如果您的应用程序只是一个裸远程终端，并且在这种“远程终端模式”期间已经进行了身份验证，或者如果服务器可以“假接受”连接而无需输入密码，然后显示自己的连接，那么这将是一个问题。另一个例子是带有 html 表单的网站。http digest auth "dialog window popups" 的设计考虑了这个问题。
2. 您应该使用SCRAM或SRP之类的质询响应协议。如果您的密码注册的设计方式是您不向服务器提供密钥（或者您在注册时信任服务器，就像在您的示例中一样），那么它们都不会为它们可以使用的服务器提供值使用相同的密码登录其他服务器。对于 SCRAM，您的盐必须在每台服务器上都是唯一的，SRP 让您免于承担这一责任。
3. 您应该将加密与加密层和质询响应层之间的通道绑定一起使用。这将使受感染的服务器无法在连接的身份验证部分中扮演目标服务器的“中间人”，然后再做他们的坏事。SRP 作为密钥交换协议本质上支持这一点，官方 SCRAM RFC 也支持通道绑定。

但是，这主要是理论上的讨论。您应该尽可能使用 ssh 密钥，因为它们提供了更好的蛮力保护。

有人可以澄清这是否正确吗？

那是一个相对的问题。我的意思是这取决于邪恶的人对服务器的控制性质。如果他足够熟练地修改/捕获 SSH 守护程序（位于服务器端），他可以获得您的密码。但这在现实中不太实用，因为有最简单的方法可以通过暴力破解密码来为顽固的黑客获取密码。

但是使用 SSH 连接到服务器的最安全方法仍然是使用使用公钥/私钥对进行身份验证而不是密码，因为暴力破解它们是根本不可能的。