Coffee Wu1. 为什么我建议你把SSH密码登录换成密钥登录
做了这么多年服务器运维，我踩过最深的坑，就是图省事用密码登录线上机器。直到有一次登录日志里出现了一堆陌生IP的暴力破解记录，我才意识到问题有多严重。SSH默认跑在22端口，只要你的服务器暴露在公网，扫端口、跑字典、撞密码这种攻击几乎是24小时不间断的。密码再复杂，也架不住别人拿几百万条弱口令库去撞。
后来我把所有客户机和服务器之间的SSH登录方式全部切换成了密钥认证，效果立竿见影，日志里的Failed password记录基本归零。这篇文章就围绕“客户机与服务器SSH密钥登录”这个主题，把从原理到实操、从单机到批量、从常见坑到底层排障的完整经验写出来，希望能帮刚入门的运维少走弯路。
先解释一句，客户机就是我们平时操作的电脑，比如Windows笔记本、Linux工作站，服务器就是远程的那台Linux主机。两者之间通过SSH（Secure Shell，安全外壳协议）建立加密通道，而密钥登录就是让客户机用一把“私钥”去证明自己的身份，服务器用对应的“公钥”来验明正身。整个过程不需要输入密码，而且比密码登录更安全。
这篇文章不仅讲配置步骤，还会把密钥认证的底层原理、权限设置为什么不能错、批量分发公钥怎么做、以及改了配置连不上怎么办这些细节全部摊开讲。不管你是刚接触Linux的小白，还是已经用过SSH但一直没搞懂密钥登录的老手，这篇文章都能给你实实在在的帮助。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 密钥登录的工作原理与方案选型
2.1 非对称加密：两把钥匙解决身份认证
要理解SSH密钥登录，绕不开一个概念：非对称加密。简单说就是同时生成两把钥匙，一把私钥，一把公钥。私钥必须自己保管好，绝对不能泄露；公钥可以随便分发，就像名片一样发给别人。
打个比方，公钥就是一把锁，私钥是开这把锁的唯一钥匙。服务器拿到你的公钥后，相当于在门上装了一把锁。你每次登录时，客户机用私钥去开锁，开锁成功，服务器就认你。这个过程中，私钥永远不需要通过网络传输，只在本机参与计算，所以即使网络被监听，别人也拿不到你的私钥。
具体到SSH协议里，验证过程大概是这样的：客户机发起SSH连接时，服务器会检查客户机提供的用户名对应的authorized_keys文件里有没有你那份公钥。如果公钥匹配，服务器会生成一串随机数，用公钥加密后发给客户机。客户机用私钥解密这串随机数，再加上约定的会话标识做哈希计算，把结果返回给服务器。服务器验证哈希结果正确，就确认客户机确实持有对应的私钥，认证通过，建立连接。
整个过程包含挑战（challenge）和响应（response）两个核心动作，所以这类认证方式也叫挑战-响应认证。好处不用多说：私钥不落地网络、密码不参与传输，暴力破解基本失效，除非你私钥本身泄露。
2.2 为什么不用密码登录：安全与效率的双重考量
很多人觉得密码登录用了这么多年也没出事，没必要折腾。但我见过太多真实案例，密码登录的危害通常不是技术层面被直接破解，而是管理层面出漏洞。
- 密码会泄露：明文写在文档里、聊天记录里、甚至贴在显示器上，这些我都见过。
- 密码难管理：几十台服务器，每台密码不一样，记不住就只能写下来，写了就泄露。所有机器用同一个密码，一台沦陷全盘皆输。
- 密码可被暴力破解：只要有足够的尝试次数，弱口令早晚会被撞出来。
- 密码无法撤销单台权限：一个人离职，你要改所有服务器的密码，否则他有备份照样能登。
密钥登录之后，这些问题基本都能解决。私钥是文件，可以加密存储，可以设置口令保护。权限控制直接调整authorized_keys文件内容即可，删掉某条公钥，立刻生效。批量操作时，配合ssh-agent做私钥转发，一次认证，多台机器随便跳。
2.3 方案选型：RSA还是Ed25519？
SSH支持的密钥算法有好几种，最常用的是RSA和Ed25519。RSA是老牌算法，兼容性最强，几乎所有SSH实现都支持。Ed25519是后起之秀，基于椭圆曲线，密钥更短、生成更快、安全性更高，现代Linux发行版默认的ssh-keygen就能直接生成。
我在实际项目里的选择是这样的：
- 老系统（CentOS 6、Ubuntu 14等）优先用RSA-2048或RSA-4096，太老的系统对Ed25519支持不好。
- 新系统（CentOS 7+、Ubuntu 18+、Debian 9+）直接用Ed25519，性能好，密钥文件短，管理方便。
- 如果是客户机是Windows，配合Xshell、SecureCRT或VSCode的Remote-SSH插件，Ed25519都能正常支持。
这里说一个细节，生成Ed25519密钥时，在服务器上只需要执行 ssh-keygen -t ed25519，一路回车即可。生成的私钥在~/.ssh/id_ed25519，公钥在~/.ssh/id_ed25519.pub。RSA同理，只是把-t参数换成rsa，加上-b 4096指定位数。
3. 配置前的必要准备
3.1 客户机与服务器环境盘点
动手配置前，先把两边的环境摸清楚。我做过一次统计，团队里一半人卡在配置步骤上，不是因为命令不会敲，而是基础环境没搞清楚。
客户机这边：
- Windows系统：常见的有Windows 10/11自带的OpenSSH客户端、Xshell、SecureCRT、MobaXterm、VSCode Remote-SSH。Windows 10 1809以后自带OpenSSH客户端，可以直接在PowerShell里执行ssh命令，这点很多人不知道。
- Linux/macOS系统：自带OpenSSH客户端，终端直接执行ssh命令即可。
服务器这边：
- 确认sshd服务是否正常运行，systemctl status sshd（CentOS/RHEL系）或systemctl status ssh（Debian/Ubuntu系）。
- 确认SSH端口，默认是22，如果改了要记住你自定义的端口，后面所有配置都要跟着改。
- 确认用户名，密钥是绑定到用户名的，不是绑定到IP的，同一个IP不同用户，密钥不能混用。
3.2 客户机与服务器的时钟同步问题
这个坑比较隐蔽：如果你用的是带验证时限的SSH密钥，比如证书登录，或者服务器上开启了严