腾讯云服务器 SSH 安全加固：从密码登录到密钥、fail2ban 与堡垒机

发布时间：2026-10-04 21:11:18

腾讯云服务器 SSH 安全加固：从密码登录到密钥、fail2ban 与堡垒机

正文

一台刚上线的客户机器，公网 IP 挂了不到一天，我登进去敲 lastb | head，失败登录记录已经刷满好几屏；再看 journalctl -u sshd，"Failed password for root" 一条接一条，来源 IP 换着花样往外冒。所以先给结论：腾讯云服务器 SSH 加固的第一步不是改端口，而是把"密码"这条通道直接关掉。 密码登录只要还在，22 端口就是一台二十四小时不停被猜的保险箱；换成密钥之后，绝大多数自动化爆破脚本当场失效。

这些年给中小客户做加固，我的顺序基本固定：先上密钥、再收安全组、然后禁用 root 直登、最后才谈 fail2ban 和堡垒机。顺序乱了容易把自己锁在门外，这个坑我实打实踩过，后面会细说。管理端口的暴露面、密钥怎么轮换、Windows 的 RDP 要不要一起管，其实是同一套逻辑，本文就按这条线走一遍。

22 端口为什么是全网最忙的靶子

公网上的 SSH 端口，是全互联网被扫描频率最高的服务之一。原因很朴素：SSH 是服务器的总闸门，一旦猜中就是最高权限，而扫描成本几乎为零。脚本小子批量扫全网 22 端口，拿到 banner 就开始撞密码字典，撞 root、撞 admin、撞各种常见弱口令。我经手过的一个客户，运维图省事把密码设成公司缩写加年份，结果机器被当成肉鸡去发垃圾流量，等云监控告警才发现。

关键在于，这种爆破是无差别的。你的业务做多大、有没有名气，跟会不会被打没有关系。我见过一个只有内部测试用途的小站，照样每天收到几千次失败登录。别抱"我们很小没人会盯上"的侥幸，攻击是自动化的，不挑对象。

爆破面里最危险的三样东西：一是弱口令，八位纯字母、姓名拼音、年份组合，字典里全都有；二是root 直登，撞中 root 就等于直接拿到最高权限，连提权步骤都省了；三是端口全开，安全组默认放行 0.0.0.0/0 的 22 端口，等于对全世界敞开。这三样凑齐，就是一台随时会沦陷的机器。Windows 服务器同理，只是端口换成 3389 的 RDP。

密钥登录：passphrase 与 ssh-agent 的正确用法

生成密钥对现在很方便。本地执行 ssh-keygen -t ed25519 -C "ops@yourdomain"，用 ed25519 而不是老旧的 rsa 2048，更短更快；如果一定要用 rsa，至少 3072 位以上。生成时会问你要不要设 passphrase，这一步很多人直接回车跳过，我不建议。私钥不加 passphrase，等于把钥匙放在没锁的口袋里，一旦私钥文件泄露，攻击者不需要任何爆破就能直入系统。

那设了 passphrase 每次登录都要输岂不是很烦？用 ssh-agent 解决：eval $(ssh-agent) 起代理，ssh-add ~/.ssh/id_ed25519 把私钥加载进去，之后当前会话内就免重复输入。Mac 和 Linux 都原生支持，Windows 下用 OpenSSH 客户端或 WSL 也一样。

公钥怎么落到服务器上？两种做法。一是执行 ssh-copy-id，或手动写进 ~/.ssh/authorized_keys，把文件权限设成 600、目录设成 700——权限不对 sshd 会直接拒绝，这个细节卡住过不少人；二是创建腾讯云 CVM 实例时直接选择密钥对，或者在控制台绑定已有密钥，机器初始化阶段就把公钥写进去，省去手工操作。轻量应用服务器的镜像也支持密钥登录，但重装系统后密钥绑定关系可能变化，重建前先确认。

公钥上身之后，回到 /etc/ssh/sshd_config，把 PasswordAuthentication 设为 no、PubkeyAuthentication yes、PermitRootLogin no，然后 sshd -t 检查语法、systemctl reload sshd 生效。改配置时一定保持当前这条 SSH 连接别断，另开一个窗口验证新连接能不能进，确认没问题再退出——这就是前面说的"别把自己锁在门外"。

禁用 root 直登、sudo 与安全组源 IP 白名单

禁用 root 直登之后，日常运维要落到普通用户加 sudo 上。做法是 useradd deploy、usermod -aG wheel deploy（Debian/Ubuntu 是 sudo 组），再给这个用户配公钥。之后所有操作走 sudo，好处是每条提权命令都会被记录，审计链条完整；就算这个普通账号被盗，攻击者也只是普通权限，还得再想办法提权。

这里有个常见误区：禁用 root 登录就觉得安全了，却忘了 sudo 免密配得满天飞。visudo 里给全部命令 NOPASSWD: ALL，等于把 root 权限原样又发了一遍，只是换了个名字。我的建议是 sudo 该要密码就要密码，实在要自动化再用精细的命令白名单，而不是一刀切全免。改 sshd_config 之前，先确认新用户能正常登录、能正常 sudo，再禁 root；顺序反了，你又没有 root 能进，就真得去控制台走 VNC 或者重置密钥了。

再强的 sshd 配置，也架不住端口对着全世界开。真正一刀砍掉大部分爆破面的，是安全组源 IP 白名单——只放行办公网络出口 IP、跳板机 IP、VPN 网段访问 22 端口，其他来源直接拒绝。这样即使密码很弱，攻击者连握手都握不上。配套的还有轻量应用服务器的防火墙，逻辑和 CVM 安全组类似，都是实例外的网络层过滤，在控制台点几下就能调整，也不怕改错把自己锁死。我一般建议网络层收敛和系统层加固一起做：安全组收源 IP，sshd 关密码，两层叠加，攻击面从全世界收缩到几个可信网段。

如果运维人员经常在家办公、IP 不固定，纯白名单会很折腾。这时候要么上 VPN 固定入口，要么用堡垒机统一入口，不要为了图方便再把 22 端口对 0.0.0.0/0 放开，那是把前面所有工作一次清零。

fail2ban 与"改端口"：主动拦截和降噪的边界

改端口这件事，我的态度一直很明确：它只是降噪，不是加固。 把 22 改成 22222，能躲掉那些只扫默认端口的自动化脚本，日志确实清净不少；但端口扫描是分分钟的事，懂行的人全端口一扫就找到了。所以改端口可以作为减少噪音的辅助手段，绝不能当成安全措施本身。而且改端口要同步更新安全组、firewalld/ufw，以及所有自动化脚本和监控项，漏一处就是一次故障。

真正主动拦截的是 fail2ban 这类工具。它盯 auth.log（Debian/Ubuntu）或 /var/log/secure（RHEL/CentOS 系），失败登录达到阈值就在防火墙层临时封 IP。一个可用的起点配置是 maxretry = 5、findtime = 10m、bantime = 1h，再配 ignoreip 把自己办公 IP 加白，免得手滑把自己封了。sshguard 是同类思路的另一个选择，逻辑更轻。不过要注意，fail2ban 需要能操作 nftables/iptables/firewalld，容器里跑或者权限不足会失效；如果前面已经做了安全组源 IP 白名单，fail2ban 更多是纵深防御的补充，而不是唯一依赖。

登录审计与告警：lastb、auth.log 到闭环

加固做完了，怎么知道还有没有人在敲门？靠审计。lastb 读 /var/log/btmp，看失败登录列表；last 读 wtmp，看成功登录；who 看当前在线用户；journalctl -u sshd -f 实时盯 sshd 日志。养成上线第一件事就看一眼 lastb 的习惯，你会对公网有多热闹有直观认识。

光靠人肉看日志不现实，要接告警。思路是把失败登录数、成功登录来源异常这两个信号接到监控——腾讯云自带的云监控能对 CVM 做基础指标告警，主机安全 CWP 则提供登录审计和爆破拦截，能在控制台看到爆破尝试的源 IP 和趋势，比手工翻日志省事得多。自建的话可以用简单脚本定期统计 lastb 条数，超过阈值就推送到告警渠道。登录审计的价值不只是事后取证，更是提前发现异常：一个从没出现过的境外 IP 突然用某个普通账号登录成功，往往比失败爆破更值得警惕。

密钥轮换与堡垒机：从个人习惯到组织制度

密钥登录解决了猜密码的问题，但引入了新的管理问题：私钥分给谁、离职怎么办、多久换一次。私钥一旦多人共用、又不轮换，本质上和弱口令没区别——去年离职的同事手机上还留着这把钥匙，你根本不知道。

密钥轮换的朴素做法：每台机器、每个人一对独立密钥，authorized_keys 里按人标注注释（就是 ssh-keygen -C 那串），人员变动就删掉对应行，关键环境定期换钥。进阶一点，用配置管理工具统一下发和回收 authorized_keys，避免几十台机器手工改。

再往上是堡垒机，也就是跳板机。所有运维流量先到堡垒机，再转内网机器，内网机器根本不暴露公网端口。好处有三点：入口唯一、可审计（谁在什么时候连了哪台机器）、便于集中做认证和授权。对几台机器的团队，一台小规格 CVM 装个跳板就够了；规模大了可以上专门的堡垒机产品或腾讯云的运维审计类能力。从每台机器一个 22 端口，到一个入口加内网流转，是安全管理思路的一次真正升级。

Windows RDP：同源问题，别只加固 Linux

很多团队 Linux 加固做得很细，Windows 服务器却还开着 3389 对公网、用 Administrator 加简单密码，这是我见得最多的不对称。RDP 的爆破和 SSH 本质一样，甚至更值得担心，因为一旦登进去，拿到的是带图形界面的完整桌面权限。

RDP 的加固套路和 SSH 一一对应：安全组只放行可信源 IP；改默认端口只是降噪；禁用 Administrator 直连、改用普通账号加复杂密码；能上证书认证就别只靠密码；开启登录失败锁定策略；有条件一定走 VPN 或堡垒机进 RDP，不直接暴露在公网。Windows 自带的远程桌面日志配合事件查看器，能看到登录失败和来源，别让它躺着没人看。

下面这张表是我给客户做加固时用的核对清单，按优先级从高到低，Linux 和 Windows 都在里面。

加固项 位置或命令 解决什么风险 常见坑

密钥登录替换密码 sshd_config 中 PasswordAuthentication 设为 no 弱口令被撞 公钥权限位不对被拒绝

安全组源 IP 白名单 控制台安全组入站规则 全公网暴露 忘记加自己出口 IP 被锁门外

禁用 root 直登 PermitRootLogin no 配合 sudo 最高权限被直接拿下 sudo 配 NOPASSWD 等于白做

fail2ban 拦截 maxretry findtime bantime 反复爆破 未加 ignoreip 封了自己

改端口降噪 Port 改成非标端口 减少自动化扫描 安全组与脚本未同步

登录审计与告警 lastb auth.log 云监控 CWP 异常登录看不见 只装不看 形同虚设

密钥轮换 authorized_keys 按人管理 离职钥匙失控 多机手工改容易漏

RDP 对应加固 3389 源 IP 与账号锁定策略 Windows 被桌面入侵 只管 Linux 忘了 Windows

FAQ

Q：改了 SSH 端口就算加固完成了吗？

A：不算。改端口只是降低自动化脚本的噪音，全端口扫描照样能发现。真正的加固是密钥登录加安全组源 IP 白名单，改端口顶多算辅助。

Q：密钥加了 passphrase 每次都要输，太麻烦怎么办？

A：用 ssh-agent 加载一次，当前会话内免重复输入。passphrase 能防止私钥文件泄露后被直接使用，不建议为了省事干脆不设。

Q：禁用了 root 直登，万一 sudo 用户也进不