安全与隐私stribika.github.io
加固 SSH 安全
Secure Secure Shell
2015 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2015 年的博文详细讲解了如何加固 OpenSSH：升级密钥格式、禁用弱算法（如 RC4、1024 位 RSA/DH）、改用 Curve25519/Ed25519 等现代算法，并给出了具体的 sshd 配置建议。文章在 2018 年再次登上 HN 首页，引发了关于 NIST 曲线是否可信、该不该硬编码算法配置的激烈争论。
为什么经久不衰：它是 SSH 加固领域被反复引用的经典指南，即使部分观点有争议，其中关于算法选择和密钥格式的建议至今仍有参考价值。
HN 评论精选
密码学专家认为文章部分威胁评估过于悲观，实际风险远低于文中暗示
NSA 或许能从 1024 位 RSA/DH/DSA 握手中恢复密钥，但要大规模做到这一点几乎不可能，那属于“外星科技”级别的能力。RC4 确实已被彻底攻破，应当禁用，但实际攻击需要同一明文重复数百万次，这对 HTTPS/TLS 是真实威胁，对 SSH 则不然。没有严肃的密码学家认为 NIST 曲线有后门；能避开就避开，但理由是它们本身质量差，而非后门。MD5 在 HMAC 构造中尚可存活。
tptacek查看英文原文
It's possible that NSA can recover keys from 1024-bit RSA/DH/DSA handshakes, but it's extraordinarily unlikely that they can do so scalably; that would be an ability that currently qualifies as space-alien technology. RC4 is terribly broken and should be disabled. But the practical attack on RC4 requires many repetitions of the same plaintext --- "many" in the millions. This is a real threat to HTTPS/TLS, but not as much to RC4. Even hypothetical improvements to Fluhrer/McGrew would still require lots of repetitions. Disable RC4, but if you're playing along at home, this probably isn't it. No serious cryptographer seems to believe that the NIST curves are backdoored. Avoid them if you can; they suck for other reasons. MD5 is survivable in the HMAC construction.
过度加固会导致兼容性问题，不同 SSH 实现间几乎没有共同的安全算法
看了一圈其他 SSH 实现支持的密钥交换和 HMAC 算法，很多实现都会被这种加固后的服务器拒之门外，各实现共同支持的算法交集几乎只剩已知不安全的那些。有没有一份对比表格，列出各 SSH 客户端/服务器支持哪些算法？这样才能知道禁用某个协议会把谁挡在门外。
BlackFingolfin查看英文原文
Looking at which key exchange protocols, HMACs etc. various other SSH implementations out there support, it seems that many of them would be barred from accessing a server hardened like that :/. In fact, it almost seems like the intersection of mutually supported protocols is empty resp. only contains known-to-be-unsafe ones... :(. Which makes me wonder: Is there anywhere a comprehensive comparison with tables that show which SSH clients (and servers) support which algorithms for key exchange, HMAC, etc.? That would help determining whom one is going to shut out by disabling which protocol, and thus help in making an informed decision on that. Of course, to be really useful, such a table would also need to take into account which version of each listed software added support for which protocol -- as it is, the OpenSSH shipped in e.g. Mac OS X 10.8 (5.9p1) does not support curve25519-sha256@libssh.org which the OP recommends... Sources: http://www.libssh2.org/ http://api.libssh.org/stable/ https://support.ssh.com/manuals/server-admin/44/Ciphers_and_MACs.html http://www.lysator.liu.se/~nisse/lsh/lsh.html
OpenSSH 配置文件不支持禁用认证方式是个本可避免的缺陷
有点意外的是，SSH 的认证方式竟然无法通过 sshd_config 轻松禁用，而其他几乎所有安全算法都可以随意调整。我本以为文章写错了，但查了 man page 后确认确实没有这个配置项。这不是协议缺陷——SSH RFC 允许服务器声明支持的算法，OpenSSH 完全可以加一个配置选项。
jonawesomegreen查看英文原文
I'm a little surprised that SSH authentication methods can't be easily disabled using the sshd_config file. Almost all the other security algorithms can be easily tweaked. I thought this article had just made a mistake, but I read over the man page and it appears there is indeed no way to modify this using the config file. This isn't a protocol weakness. Reading over the SSH RFCs, the server is allowed to specify which algorithms it supports, so this could easily be a OpenSSH configuration option.
文章对 NIST 曲线的安全指控缺乏依据，更新软件比硬编码配置更有效
“NIST 曲线通过时序侧信道和非法曲线输入泄露秘密”——这是 FUD。如果你真发现了任何非法曲线攻击或 OpenSSH P-256 签名代码中的时序攻击，要么公开它要么闭嘴。X25519 和 Ed25519 确实更好，NIST 曲线实现也确实更难写对，但它们比新曲线早了很多年。NIST 阴谋论不是在 ssh 配置里硬编码算法套件的好理由，去更新你的软件就行了。
lvh查看英文原文
> ECDH curve choice: This eliminates 9-11 because NIST curves suck. They leak secrets through timing side channels and off-curve inputs. Also, NIST is considered harmful and cannot be trusted. This is FUD. If you have an off-curve attack of any kind, or a timing attack in OpenSSH's P-256 signing code, publish it or keep it to yourself. I appreciate that the article linked to a source, but the source talks about cache timing attacks in a different type of curve. Yes, X25519 is a better curve. Yes Ed25519 is a better signature algorithm. Yes, it's harder to get NIST curve implementations right. They also predate better curves by quite a few years. Technology improves. NIST FUD is not a good reason to hardcode ciphersuites in your ssh config. Go update your software and you'll be fine.
历次讨论
同类还值得读
非法素数
Illegal prime
维基百科条目，介绍“非法素数”：某些素数之所以被称为“非法”，是因为它们经特定编码后，恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码，有人把…
安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选关于 /dev/urandom 的常见误区
Myths about /dev/urandom
（Thomas Hühn 撰写，2014 年首发并持续更新）逐条反驳关于 /dev/urandom 的常见误解：它与 /dev/random 使用的是同一个 CSPRNG，一旦完…
安全与隐私上首页 5 次 · 2014–20202uo.de编辑精选AES 高级加密标准火柴人图解
A Stick Figure Guide to the Advanced Encryption Standard (AES)
一篇用火柴人漫画形式讲解 AES（高级加密标准）算法的经典科普文章。
安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选指纹是用户名，不是密码
Fingerprints are Usernames, not Passwords
作者（eCryptfs 维护者、Ubuntu 安全工程师）认为指纹等生物特征是公开、不可更改的标识，应视作用户名而非密码，不能当作秘密凭据用于认证。
安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.comHTTPS 连接的最初几毫秒（2009）
The First Few Milliseconds of an HTTPS Connection (2009)
逐毫秒拆解一次 HTTPS 连接建立时发生了什么，重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制，面向不熟悉该领域的读者。
安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选