1995年诞生的SSH协议，至今仍是远程登录的默认选项。全球数百万服务器靠它守护，但一个基础配置错误就能让加密隧道形同虚设——你输入的密码可能正被实时窃听。
这不是危言耸听。作者坦承自己早年也用过不安全的SSH方式，直到理解主机密钥验证（host key verification）的真正含义。多数人连接服务器时只核对IP或域名，却忽略了SSH安全的核心逻辑：网络路径不可信，密码学才是唯一担保。
域名和IP，为什么靠不住？
当你执行ssh server.example.com，系统先做DNS查询把域名转成IP。这个环节有多层基础设施参与，每层都可能被操控。
DNS劫持（DNS poisoning）是最直接的攻击方式。攻击者污染解析结果，让合法域名指向恶意IP。你看到的连接提示一切正常，实际登录的是伪造服务器。如果客户端只验证域名匹配，攻击者就能拿到你的明文密码。
公网环境尤其危险。咖啡馆WiFi、机场热点、甚至家庭路由器被入侵后，都可能成为中间人攻击（Man-in-the-Middle，MITM）的跳板。作者将在第二部分用实验演示：攻击者如何捕获凭证、实时监控用户操作。
主机密钥验证：SSH的"指纹"机制
SSH解决信任问题的方案是主机密钥（host key）。每台服务器生成唯一的密钥对，首次连接时客户端记录其公钥指纹。后续连接比对指纹是否一致，不一致则发出警告。
这个设计类似你记住朋友的声音或笔迹。第一次当面交换"识别特征"，之后远程交流时核对特征是否匹配。特征变了，要么朋友换了人，要么有人在冒充。
但现实中大量用户看到警告直接输入yes跳过。自动化脚本更是用StrictHostKeyChecking=no关闭验证，把SSH降级为"加密传输的明文密码"。
作者指出，主机密钥验证的可靠性取决于首次记录的准确性。如果第一次连接就被中间人截获，客户端会永久记住伪造密钥，后续所有连接都在攻击者控制之下。
验证密钥的三种姿势
如何确保首次记录的密钥属于真实服务器？
方案一是带外验证（out-of-band）。通过独立渠道获取指纹，比如服务商控制面板、纸质文档、或已验证安全的其他服务器。AWS EC2实例启动时会把指纹写入系统日志，就是这个思路。
方案二是证书体系（SSH certificates）。企业环境用内部CA签发主机证书，客户端只信任CA公钥，无需记录每台服务器的指纹。OpenSSH的ssh-keygen -s CA -I identity -h server_key.pub命令链支持这套流程。
方案三是硬件锚定。云厂商的实例元数据服务、TPM芯片存储的密钥，都能提供不可伪造的身份证明。这类方案成本更高，但对抗国家级攻击者时是必要选项。
个人用户和小团队往往卡在第一步：根本不知道要去验证指纹。默认配置下SSH客户端只显示一行 Base64 字符串，复制到剪贴板都费劲，更别说跨渠道比对了。
配置陷阱：你以为的安全可能是幻觉
常见误区是把PasswordAuthentication no当成安全终点。禁用密码、只用密钥登录确实能防暴力破解，但解决不了主机身份验证问题。攻击者照样可以伪造服务器，收集你的私钥签名或转发代理请求。
另一个隐患是HashKnownHosts no。旧版本SSH默认把已知主机明文存储在~/.ssh/known_hosts，攻击者读取后能枚举你连接过的所有服务器。现代OpenSSH已改为哈希存储，但升级后旧记录不会自动转换。
作者提到的第三部分将聚焦加固实践。核心原则是把安全决策从"用户每次判断"转移到"基础设施默认保护"——毕竟人总会犯错，系统设计要假设用户会点错。
一个值得玩味的细节：OpenSSH客户端在主机密钥变更时，会提示IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!（有人可能在搞鬼！）。这个1999年写定的警告语，至今仍是无数运维人员职业生涯中第一次真正停下来思考SSH安全性的时刻。
你的known_hosts文件里有多少条记录是从未验证过来源的？下次看到那行全大写的警告，你会选择调查还是直接删掉旧密钥继续？
热门跟贴