sshd_config 加固：每一项都讲清楚

我是小够。上一篇清单里提到要改 sshd_config，评论区有人问"到底改哪几项"。今天就把这个文件掰开揉碎讲一遍。文件位置固定：/etc/ssh/sshd_config，改完记得 sudo systemctl restart sshd 生效。动手前先开两个 SSH 会话，万一改错了还有一个能救场——这是老司机的保命习惯。

PermitRootLogin no

禁止 root 直接远程登录。root 用户名全世界都知道，是爆破的首选目标。日常用普通用户 + sudo，安全性完全不是一个级别。这是优先级最高的一项。

PasswordAuthentication no

关掉密码登录，只允许密钥。注意顺序：先确认密钥能登录成功，再关密码，否则你会被自己锁在门外。云商家后台一般都有 VNC/控制台，万一锁死还能从控制台进去改回来，但最好别走到那一步。

Port 2222（示例）

把默认 22 端口换成 1024 以上的高位端口。实话实说：这挡不住定向攻击，但能过滤掉全网 90% 以上的自动化扫描，让你的日志干净很多。改完记得防火墙同步放行新端口、关闭 22。

MaxAuthTries 3

默认是 6，改成 3。含义是单次连接最多尝试 3 次认证，超了就断开。配合 fail2ban 效果更好。

LoginGraceTime 60

默认 120 秒，改成 60。指登录过程的最长耗时，超时没完成认证就断开。缩短它能减少慢速爆破占用的连接资源。

PermitEmptyPasswords no

禁止空密码登录。正常系统默认就是 no，但检查一遍不吃亏，万一哪个魔改镜像开了呢。

X11Forwarding no

用不到图形转发就关掉，少一个用不上的功能就少一个攻击面。纯命令行用户直接关。

AllowUsers xiaogou

白名单：只允许指定用户登录。用户越少，爆破的"靶子"越少。如果你只有一个运维用户，就只写他。

ClientAliveInterval 300 / ClientAliveCountMax 2

300 秒没动静发个心跳包，2 次没回应就断开。防止你人走了、会话还挂在那。

ChallengeResponseAuthentication no

除了密码，还有个"键盘交互认证"（老版本叫 ChallengeResponseAuthentication），也要关掉。不然你关了 PasswordAuthentication，攻击者还能走键盘交互通道试密码，等于门没锁死。两个一起关，密码登录才算真正关闭。

MaxStartups 10:30:60

控制未认证连接的并发数。10:30:60 的意思是：超过 10 个未认证连接后，开始按 30% 概率丢弃新连接；超过 60 个全丢。这是防"并发爆破"占满 sshd 的，对正常使用没影响——你同时开 10 个未登录的 SSH 会话的概率基本为零。

AllowGroups vs AllowUsers

前面讲了 AllowUsers 白名单，还有个 AllowGroups 按组控制。如果你给不同用途建了不同用户（运维组、审计组），按组控制更省心：

AllowGroups ssh-users

然后 usermod -aG ssh-users 用户名 把人加进组。用户多了之后，按组管比一个个列用户名清爽得多。

改错了怎么救

就算按流程走，也可能手滑。三个救命办法，按顺序试：

1. 没关旧会话：直接在旧会话里改回来，重启 sshd。这就是为什么强调"先开两个会话"。
2. 商家控制台/VNC：绝大多数 VPS 商家都在后台提供控制台，不走 SSH，直接操作，等于物理机前坐着。
3. 救援模式：极少数商家提供，把系统盘挂到另一台机器上改文件。不到万不得已用不上。

另外，改之前备份原文件是个好习惯：sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak，回滚一条 cp 命令的事。

改完的检查流程：sudo sshd -t 先验证语法没错，再重启服务，最后新开一个终端测试登录，确认没问题再关掉旧会话。sshd 配错了是最常见的"把自己锁门外"事故，按这个流程走基本不会翻车。

小够的观点：sshd_config 没有"最安全"的配置，只有"适合你的"配置。个人博客和跑业务的服务器，要求本来就不一样。上面的清单是"够用且安全"的版本，照着做不会错；等你更熟了，再按自己的场景微调。