为什么说口令登录是远程主机的“阿喀琉斯之踵”
用密钥对替代口令登录远程主机，是目前消除SSH暴力破解风险最彻底的方法，推荐的操作路径是：生成密钥对、上传公钥、禁用口令认证，三步完成，耗时不超过十分钟，收益是永久告别弱口令焦虑。
说起远程管理Linux服务器，大多数朋友第一反应就是ssh root@服务器IP，然后输密码，这个习惯在早期挺方便，但在当今的互联网环境下，纯口令认证就像把家门钥匙挂在门口脚垫下面只要公网上的扫描器转悠到你家门口,顺手就能摸一摸。
口令登录的三个致命伤
- 暴力破解无休止：只要服务器暴露在公网，22端口就无时无刻不在承受自动化脚本的试探，据统计，一台公网IP的服务器每天收到数百次陌生SSH连接请求相当常见，多数是循环尝试
root/admin/test这类用户名搭配简单密码。 - 撞库风险防不住：很多人习惯把同一套口令用在多个平台，一旦某个网站泄露了密码库，攻击者就会拿着这些“密码字典”来试你的服务器,这叫撞库攻击。
- 中间人难察觉：在没有证书校验的纯口令场景下，如果DNS被劫持或ARP欺骗，客户端可能把密码送进攻击者伪造的“服务器”手里。
行业共识认为，纯口令认证在公网环境下已经不再适合作为唯一的身份验证手段，而密钥对认证恰好从机制上绕开了人性弱点你不需要“任何复杂密码,只需要保管好一个私钥文件。
SSH密钥登录和密码登录哪个安全？先算清这笔账
在讨论配置之前,有必要把这两种认证方式的底层逻辑摆出来。
| 对比维度 | 口令登录 | 密钥对登录 |
|---|---|---|
| 认证要素 | 你记住的东西 | 你拥有的东西（私钥文件） |
| 暴力破解难度 | 取决于密码强度，普通的8位密码在算力强大的集群面前并不牢靠 | 理论上需要穷举256位以上的私钥空间，当前算力完全无能为力 |
| 泄露风险 | 口令可被复制、可被社会工程学套取 | 私钥不出本地，公钥泄露不影响安全 |
| 便捷性 | 每台机器一个密码，多了记不住 | 一把私钥通配多台服务器，公钥随便分发 |
| 审计能力 | 无法区分“哪个谁”用了root密码 | 每个管理员各有密钥，日志能精确追踪到个人 |
很多人在“安全”和“方便”之间纠结，其实密钥对登录的真正便利之处在于：你可以把同一把公钥部署到几十台服务器上，然后用唯一的私钥从容地逐个登录，相比切换每台机器去敲不同密码，这省下的时间非常可观，至于Windows用户担心操作门槛,稍后会细说。
密钥对登录远程主机的完整配置流程
整个配置过程可以拆成四个环节：生成、部署、加固、验证，每一步都有可复核的结果，不必担心“配完连不上”的狼狈。
生成密钥对：选对算法和参数
在本地电脑（客户端）上生成密钥对，推荐优先使用ed25519算法，它比传统的RSA-2048更短、更快，也足够安全，如果你的系统比较老，只能用RSA，那么务必把位数拉高到4096位。
$ ssh-keygen -t ed25519 -C "my-aliyun-server" -f ~/.ssh/id_ed25519执行后会有两个提示：
- 设置私钥口令：如果输入了一个口令，那么每次使用私钥时都要再验证一次，等于多了一道双因子认证，建议设置,成本低且收益明显。
- 确认保存路径：默认存放于
~/.ssh/目录下，生成两个文件：id_ed25519是私钥，id_ed25519.pub是公钥，两者务必分清，私钥一旦外泄,后果等同账户失守。
部署公钥到目标服务器
公钥可以理解成一把“锁”，装到服务器上，只有你的私钥这把“钥匙”能打开,上传公钥有两条路：
一键部署（推荐）,本地执行：
$ ssh-copy-id -i ~/.ssh/id_ed25519.pub root@服务器IP脚本会自动把公钥追加到服务器~/.ssh/authorized_keys文件中,顺便把目录权限修正到合理范围。
手动部署（更透明），适合没有ssh-copy-id的场景（比如Windows PowerShell）：
$ ssh root@服务器IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh"
$ cat ~/.ssh/id_ed25519.pub | ssh root@服务器IP "cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"这段操作的本质是：把公钥内容追加到目标用户的authorized_keys，同时设置正确的权限。.ssh目录是700权限，authorized_keys文件是600权限
，这是SSH认证成功的前提,很多奇怪的登录失败都由权限位错乱导致。
加固sshd配置：只允许密钥登录
公钥部署完毕后，先在另一个终端保持一个已登录的SSH会话，然后再修改配置文件，这一步纯粹是为了兜底万一改错了,不至于被锁在门外狼狈不堪。
编辑/etc/ssh/sshd_config,确保以下三行有效：
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no把PasswordAuthentication改成no，是最后一步封死口令登录的开关，同时建议改掉默认端口，比如Port 2222，虽然密钥认证本身已经足够安全,但换个端口能显著减少日志中被刷屏的扫描噪音。
保存后重启服务：
$ sudo systemctl restart sshd验证方式： 新开一个终端，用ssh root@服务器IP直接连接，没有提示输入密码且能顺利进入shell，说明密钥认证生效，如果还能敲密码登录，多半是sshd_config的语法有问题，可以用sshd -t检查。
Windows客户端怎么配置SSH密钥登录？
不少使用Windows桌面的同学觉得“密钥对”这东西是Linux老炮的玩具，其实今天的Windows 10和Windows 11已经内置了OpenSSH客户端,操作路径与Linux完全一致。
在PowerShell中生成密钥
打开PowerShell,执行：
ssh-keygen -t ed25519生成的公钥默认在C:Users你的用户名.sshid_ed25519.pub，用记事本打开这个文件,复制全部内容。
粘贴到服务器
你已经用口令登录到了服务器上,执行：
mkdir -p ~/.ssh && chmod 700 ~/.ssh然后用nano ~/.ssh/authorized_keys打开文件，粘贴刚才复制的公钥内容，保存退出，再执行chmod 600 ~/.ssh/authorized_keys，以后从Windows连接,只需：
ssh -i C:Users你的用户名.sshid_ed25519 root@服务器IP如果不写-i，OpenSSH会自动读取默认路径下的密钥,所以这一步也可以省略。
老牌工具PuTTY用户怎么办
PuTTY使用的是自己的密钥格式.ppk，需要先用PuTTYgen把OpenSSH公钥格式转换过去，或者直接用PuTTYgen生成全新的密钥对，在PuTTY的Connection > SSH > Auth中加载私钥文件，接着在Session里填好服务器IP和端口，保存会话,以后双击即可免密登录。
配置完成后，如何验证你的主机真的安全了？
配置完毕不能光靠“感觉”,下面几个检查项能让你确认服务器确实是密钥认证状态。
- 检查sshd配置是否生效：执行
sudo sshd -T | grep authentication，输出中应该看到passwordauthentication no，这才是sshd实际加载的运行时配置,光看配置文件可能会有错觉。 - 检查最近登录记录：运行
sudo tail -n 50 /var/log/auth.log，如果能看到Accepted publickey for root的记录，说明公钥认证成功；若还有Failed password的记录，请检查防火墙是否封禁了旧端口,以及是否还有别的服务停留在22端口。 - 测试暴力破解的抵御能力：随便换一台电脑，尝试用
ssh -o PreferredAuthentications=password root@服务器IP连接，系统会直接拒绝密码方式并断开，而不是提示错误密码,这就说明认证链路已经堵死。
如果追求更极致的防护，可以叠加fail2ban来监控多次认证失败的IP并自动拉黑，给密钥认证再加上一道保险网，不过在你已经关闭密码认证的情况下,这层防护基本是防患于未然的备份方案。
Q&A：密钥对登录远程主机的常见问题
问：密钥对登录远程主机配置失败，最常见的原因是什么？
答：多数情况是权限问题。.ssh目录必须为700权限，authorized_keys文件必须为600权限。/etc/ssh/sshd_config中如果你设置了AuthorizedKeysFile路径，要确保该路径与实际公钥存放位置一致，还有少数情况与SELinux相关，检查/var/log/audit/audit.log里是否出现denied的上下文记录，执行restorecon -Rv ~/.ssh可解决多数SELinux拦截问题。
问：我有多台服务器，可以使用同一把公钥登录它们吗？
答：可以，并且这是相当普遍的运维习惯，同一把私钥作为你的唯一身份凭证，公钥可以分发到任意数量的服务器上而无泄露风险，需要区分权限时，建议为不同管理员生成各自的密钥对，将各自的公钥部署到不同用户的authorized_keys中，服务器日志便能精确追踪每个操作者，在大规模的云服务器场景下，不少团队会使用密钥对作为标准准入方案，配合配置管理工具批量分发公钥,整体成本远低于维护一套口令系统。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/659884.html
