Coffee Wu1. SSH配置这件事，为什么值得单独写一整篇
1.1 先说说SSH在服务器日常里的位置
如果你是从前面几篇一路"修炼"过来的，应该已经体会到了：服务器这东西，买来之后就是一个黑盒子，你在命令行里敲下的每一条指令，绝大多数都要经过SSH这条通道。不管你是CentOS、Ubuntu还是Rocky Linux，只要你是通过命令行操作远端服务器，SSH就是你日常接触最多的协议，没有之一。
这一篇之所以叫"配置和保护SSH"，是因为我发现很多人在部署环境的时候，装完Nginx、MySQL、中间件，却常常忽略掉自己脚下这根最关键的管道。你在服务器上跑得再花哨的服务，本质都是先把SSH这条入口守住。配置SSH，解决的是"怎么连得顺手"的问题；保护SSH，解决的是"怎么不被外部爆破和打穿"的问题。二者缺一不可。
1.2 默认状态下的SSH，暴露面比你想象中大
新装的服务器，如果你不去动任何配置，默认是22端口、密码认证、root可登录。很多人觉得"我的密码够复杂就行"，但你可以试想一下：一台拥有公网IP的机器，从开机那一刻起，就会有来自全世界的扫描流量在试探它，日志里那些不断尝试登录的IP就是证据。默认的密码登录方式，本质上就是把一个写满用户名的门牌号贴在了公网上——root是一个确定的用户名，SSH端口是确定的22，剩下的就是对你的密码进行穷举。
这就像你在一个鱼龙混杂的小区里买了一套房，交付时开发商给你配了一把普通的A级锁，虽然能用，但左邻右舍都知道你家大门是这种锁。而配置SSH密钥认证和调整登录限制，就是把门锁换成指纹锁。这不是危言耸听，而是每一个长期维护服务器的人都会经历的阶段。
注意：在做任何SSH加固之前，请先确认自己有控制台VNC或救援模式作为最后兜底手段。云服务商的控制台一般都提供网页版VNC或终端入口，这是你改崩溃了sshd配置之后唯一的救命稻草。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从密码到密钥：认证方式的核心区别
2.1 密码认证为什么不够用
密码认证的工作方式很简单：客户端把用户名和密码提交给服务端，服务端去验证。问题在于，密码本身是"可猜测的"，而且它可以通过无数次的尝试来暴力破解。哪怕你设置了密码错误延迟，也只能降低爆破速度，不能根除爆破行为。更麻烦的是，一套稍微复杂的密码，在多个环境之间容易重复使用，一旦某个网站的数据库泄露，攻击者会拿着这组用户名密码去批量尝试你的服务器。
只要你的服务器还开放着密码认证，你的授权文件、密钥、账号体系就暴露在持续的攻击面之下。即便业务上需要第三方临时访问，正规做法也是生成一次性的密钥，而不是把密码发给对方。
2.2 密钥认证的原理，一句话就能讲明白
密钥认证用的是非对称加密。简单理解就是：服务器上存放一把"锁"（公钥），你的电脑上保管一把"钥匙"（私钥）。当你想登录时，服务器会验证你确实持有那把跟公钥配对的私钥。整个过程不需要在网络中传输密码，私钥也永远不出现在服务器上。
这里有个生活化类比：你去健身房办卡，办了之后前台电脑里记录了你的指纹特征（公钥），你每次进门按一下指纹（私钥的持有证明），系统验证通过就放行。密码相当于你每次进门都报一次身份证号，而公钥/私钥跟你本人是绑定的。
2.3 为什么推荐优先使用Ed25519算法
生成密钥的时候，主流的算法有RSA和Ed25519两种。RSA是过去的通用标准，密钥长度至少要3072位或4096位才算安全。Ed25519是更新的椭圆曲线签名算法，密钥长度短、速度快、安全性高。
我在项目实践中全部使用Ed25519来生成密钥，生成的公钥以ssh-ed25519开头。老的Windows客户端或某些特殊环境如果兼容性差，再用RSA 4096兜底。以2026年的使用环境来说，绝大多数SSH客户端都支持Ed25519，不必为兼容性担心。
3. 常规加固第一轮：先改四个关键参数，把门锁上
3.1 打开sshd_config前的准备工作
SSH服务端的配置文件，不同发行版有细微差别。常见路径是/etc/ssh/sshd_config。改配置之前建议先把原文件留个备份：
bash复制sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
这条命令会生成带日期的备份文件，后面万一改坏了可以随时回滚。修改配置的工具用vim、nano都可以。改完配置之后有一个固定动作：先检查语法，再重启服务，顺序不能反。
bash复制sudo sshd -t
sudo systemctl restart sshd
sshd -t只会做语法检查，不会重启服务，如果写错了配置，它会直接给出哪一行有问题的提示，而不是让你在断线之后才意识到服务起不来。