根据ssh_config(5)的说法,HostKeyAlgorithms“指定了客户端希望按照偏好顺序使用的主机密钥算法.默认情况是:
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
ssh-ed25519-cert-v01@openssh.com,
rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa这列出了Ed25519键之前的ECDSA键,并且更喜欢在nistp384上和nistp521上有曲线的ECDSA键。
我的印象是,Ed25519通常优于ECDSA密钥,而n曲线较高的密钥(至少在这三种密钥中)更安全。
那么,为什么OpenSSH会按照这个顺序列出算法呢?
另外,我正在开发一个使用SSH作为传输的Android应用程序。它还需要一个首选主机密钥算法的列表。在应用程序中复制OpenSSH的列表是个好主意吗?还是我更喜欢ed25519而不是ecdsa,nistp521超过-384,超过-256,而不是rsa键?
发布于 2020-10-01 00:08:19
如果我没记错的话,那只是一个性能问题。请记住,HostKeyAlgorithms确定用于向客户端验证服务器的方法,它不生成会话密钥。
ECDSA算法比RSA算法速度快,小密钥大小比大密钥大小快,当缺省值为5.7时,变化量g特别引用的性能原因见第一个特征项。
由于兼容性原因,NIST密钥可能比ED25519更受欢迎,在发现服务器不支持基于Curve25519的密钥之后,我不得不生成NIST密钥,因此这是完全合理的。基于Curve25519的密钥可能是更安全,除非您要求NIST,否则他们会说它们是同等安全的。
由于这些只是默认选项,您当然可以自由地更改它们或强制执行特定的算法,因此我强制使用3072位RSA作为我的默认主机密钥方法。请记住,这是一个选择选项,如果列表中的键类型不存在,则不会使用它。如果您的配置中只有RSA密钥,所有EC选项都将被跳过,您可以随意删除它们。
如果您正在使用SSH进行传输,并且您可以控制应用程序和服务器,您只需生成您想要的1主机键并完成它,并忽略配置选项,因为它们并不重要。
发布于 2020-10-02 17:45:16
所以我开始好奇事情到底有多快。显然,您可以使用$ openssl speed查看某些操作的速度。但是,我不确定当连接到SSH服务器时,这会如何转化为实际的性能问题。
作为Diffie-Hellman密钥交换的一部分,SSH服务器计算某个哈希,然后使用其私有主机密钥对其签名。然后,客户端计算相同的散列并验证服务器签名。因此,看看这两种操作的速度有多慢是很有用的。签名操作可能更重要,因为服务器往往比客户端具有更多的SSH连接。
签名/验证操作通常涉及另一个散列操作;它将是主机密钥验证算法的一部分。例如,ssh-rsa将使用sha1,ecdsa-sha2-nistp521将使用sha512。我不确定下面的数字是否包括哈希时间。在这两种情况下,对于数据> 16字节,sha256和sha512的执行情况似乎是相当的。
我在三个设备上测试了这个:
这是图表,线性和对数。Y轴是sign/s (实心,圆)和verify/s (点,三角形)。蓝色是X220,橙色是小米,红色是覆盆子皮。


这里我要说的是,ECDSA nistp256比其他ECDSA密钥的签名速度要快得多。在Raspberry pi上,使用nistp384和521将导致每秒最多55.1或23.7签名操作--对我来说,这些操作看起来很糟糕。
Ed25519比ECDSA慢一些,特别是在签名方面,但没有太多。
而且,令人惊讶的是,在Intel上,nistp521比nistp384表现得更好。
发布于 2023-03-26 13:35:11
putty 0.75和winscp @ windows server 2008不支持ECDSA方法:(

https://crypto.stackexchange.com/questions/84271
复制相似问题