摘要：# 告别密码，SSH密钥登录：一个被低估的“安全门神” 我前两天帮一个朋友排查服务器被入侵的问题，登录日志一看，好家伙，攻击者用弱密码字典，对着他的22端口扫了整整三天三夜，最后还真让他蒙对了。朋友一脸委屈：“我密码设了8位，有字母有数字，还不够复杂吗？…

告别密码，SSH密钥登录：一个被低估的“安全门神”

我前两天帮一个朋友排查服务器被入侵的问题，登录日志一看，好家伙，攻击者用弱密码字典，对着他的22端口扫了整整三天三夜，最后还真让他蒙对了。朋友一脸委屈：“我密码设了8位，有字母有数字，还不够复杂吗？”

说白了，在现在的自动化攻击面前，任何你能记住的密码，都不够安全。 这就是为什么我今天想跟你认真聊聊SSH密钥登录——这个在运维圈里几乎人尽皆知，但很多中小公司、个人开发者却还在“裸奔”时，总想不起来用，或者用错了的方案。

SSH密钥 vs 密码：这不是升级，是降维打击

咱们先把最核心的区别说清楚。密码认证，就像你家门锁，钥匙（密码）可能被复制、被偷窥、被暴力试开。而SSH密钥登录，用的是非对称加密。

我给你打个接地气的比方：

• 密码登录：你告诉门卫一个暗号（密码），他核对上了就放行。暗号一旦泄露，谁都能进。
• 密钥登录：你手里有一把独一无二的、无法复制的私钥（自己保管，绝不外传），服务器上放着对应的公钥（可以公开）。每次登录，你用私钥对一个随机挑战码进行签名，服务器用公钥验证。签名对了，门就开了。

这中间，你的私钥压根不需要通过网络传输。 攻击者截获了登录过程的数据包也没用，他造不出那个签名。这从根本上堵死了密码嗅探、中间人攻击和暴力破解的路子。

很多刚接触的朋友会觉得：“听起来好复杂，配置麻烦吧？” 其实吧，初始设置可能比改一个复杂密码多花5分钟，但换来的是往后几年安心的睡眠。 这笔账，怎么算都值。

别踩坑：密钥管理里那些“一知半解”的雷

我知道，很多人搜个教程，跟着跑完 ssh-keygen 和 ssh-copy-id 两条命令，就觉得大功告成了。但问题往往出在后续的管理和习惯上。

1. 私钥不设密码，等于给保险箱配了把玩具锁 生成密钥时，它会问你是否设置密钥口令（passphrase）。图省事直接回车跳过的人，我见过太多了。这意味着，任何人拿到你电脑上的私钥文件（比如 id_rsa），就能直接登录你的所有服务器。私钥文件必须加密！ 设置一个强口令，这是守护你密钥的最后一道防线。别担心每次登录要输口令，ssh-agent代理能帮你安全地记住它一阵子。

2. 一把钥匙开所有门？心也太大了 有些团队为了方便，所有服务器共用同一对密钥。这风险太大了。一旦某台不太安全的开发机私钥泄露，攻击者就等于拿到了你整个服务器集群的“万能钥匙”。 正确的做法是： 分级管理。至少区分：个人电脑密钥、生产服务器密钥、核心数据库密钥。甚至可以为每台重要服务器单独生成密钥对。管理起来是多了点事，但真出了事，你才知道什么叫“隔离止损”。

3. 公钥乱丢，授权文件（authorized_keys）不设防 ssh-copy-id 确实方便，但你知道它把你的公钥加到服务器的哪个文件里了吗？对，就是 ~/.ssh/authorized_keys。这个文件的权限必须设置成 600（仅所有者可读写）， .ssh 目录权限必须是 700。权限设大了，其他用户就能偷看甚至篡改你的授权公钥，那防护就形同虚设了。（我见过不少运维老手都在这栽过跟头，真的。）

进阶玩法：给密钥戴上“紧箍咒”

如果你觉得上面的已经是基本操作，那下面这几个小众但实用的技巧，能让你的安全等级再往上窜一窜。

1. 在公钥里“约法三章” 你知道吗？你贴在服务器上的公钥，前面是可以加限制选项的。这不是什么黑科技，但用的人真不多。比如：

command="/usr/bin/backup_script",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC...

这行代码的意思是：用这个密钥登录，只能执行指定的备份脚本，不允许开启代理转发、端口转发、X11转发，也不分配伪终端。这特别适合给自动化脚本或备份任务用的密钥，把它的权限锁死在最小范围，就算泄露了也干不了坏事。

2. 证书登录（Certificate Authentication）：团队管理的“神器” 这才是今天我想重点说的、比单纯密钥更“优雅”的方案。它特别适合服务器数量多、人员流动快的团队。

• 痛点：员工离职，你得挨个去几十上百台服务器上，从他的 authorized_keys 文件里删掉对应的公钥。麻烦不说，还容易漏。
• 证书方案：你自建一个内部的“证书颁发机构（CA）”。员工入职，你用CA给他签发一张有时效的SSH证书（比如有效期一周或一个月）。员工用这张证书和对应的私钥登录。他离职了？简单，你什么都不用做，等证书过期就行。或者更狠一点，直接吊销证书。所有服务器只信任你的CA，而不用维护庞大的公钥列表。

这听起来有点复杂？ 其实部署起来，一套脚本的事。但它带来的管理效率和安全性的提升，是革命性的。很多云平台和大厂内部，早就这么干了。

说点大实话：方案是死的，人是活的

最后，我得泼点冷水。再好的方案，也架不住人出问题。

• 私钥文件用微信发来发去？
• 把包含私钥的代码误传到GitHub公共仓库？（每天都有成千上万把密钥在GitHub上“裸奔”，攻击者爬得不亦乐乎）
• 服务器 authorized_keys 文件几年不清理，里面一堆不知道是谁的、离职员工的、临时用的公钥？

技术方案解决了“能不能防”的问题，但安全意识决定了“会不会破”。 SSH密钥登录不是银弹，它是一道极其坚固的门，但钥匙还得靠你自己保管好。

如果你的源站服务器还在用密码登录，甚至用着默认端口和弱密码，那我劝你真的，别等了。今天下班前就把它改了。换成密钥登录，再把密码登录彻底关掉（PasswordAuthentication no）。这可能是你今年为服务器安全做的，性价比最高的一件事。

行了，不废话了，配置去吧。第一次成功用密钥登上去，那种“再也不用怕被爆破了”的踏实感，你会回来谢我的。