一台新交付的香港CN2服务器，SSH端口暴露在公网后，最快几分钟内就会被扫描器盯上，暴力破解脚本自动跑起来，auth.log里的失败记录刷得飞起。很多人觉得“我密码设得够复杂了，应该没事”，但事实是，密码再复杂也扛不住自动化穷举。真要加固这台服务器，得从根上解决认证方式的问题——禁用root远程登录只是第一步，切换到密钥认证才是关键。

　　为什么香港CN2服务器尤其需要这套加固方案

　　先看一个现实：香港服务器因为CN2 GIA线路直连大陆，延迟低、带宽足，攻击者发起扫描和暴力破解的成本也更低。而root账户是每个攻击者的首要目标——用户名是已知的，只需要试密码就行。如果一台服务器开着root密码登录，就相当于把大门钥匙挂在门口让人猜。

　　禁用root远程登录的意义在于：攻击者不仅需要猜密码，还得先猜对用户名。而SSH密钥认证则更进一步——它用2048位甚至4096位的非对称加密，破解难度远超密码，理论上需要数万年。

　　这两个措施组合起来，能挡掉90%以上的自动化攻击。

　　第一步：创建普通用户并配置sudo权限

　　永远不要直接用root操作服务器。正确的做法是创建一个普通用户，日常用这个账号登录，需要提权时再通过sudo执行管理命令。

　　创建用户：

adduser admin

　　系统会提示设置密码和填写用户信息，密码这部分按提示输入就行。注意这个密码只是第一次登录用的临时凭证，后面我们切换成密钥认证之后密码就基本不用了。

　　赋予sudo权限：

# Ubuntu/Debian 系统
usermod -aG sudo admin

# CentOS/RHEL 系统
usermod -aG wheel admin

　　这一步做完，先别急着切出去。用新用户登录一次，确认sudo能正常提权，再做后面的操作。很多人栽在没验证这一步就改了SSH配置，结果把自己锁门外了。

　　第二步：生成SSH密钥对并上传公钥

　　在本地电脑(不是服务器)上生成密钥对。推荐用ed25519算法，性能和安全性都比RSA好：

ssh-keygen -t ed25519 -C "你的邮箱@example.com"

　　一路回车，会生成两个文件：~/.ssh/id_ed25519(私钥，打死也不能给别人)和~/.ssh/id_ed25519.pub(公钥，可以放心上传)。

　　然后把公钥传到服务器上：

ssh-copy-id -p 22 admin@你的服务器IP

　　输入admin的密码后，公钥会自动写入服务器的~/.ssh/authorized_keys。如果ssh-copy-id用不了，手动复制也行——把本地id_ed25519.pub的内容贴到服务器上/home/admin/.ssh/authorized_keys文件里。

　　注意目录和文件的权限要设置对，否则密钥认证会失败：

chmod 700 /home/admin/.ssh
chmod 600 /home/admin/.ssh/authorized_keys

　　上传完成后，先别急着关当前会话。另外开一个终端窗口，用密钥登录一次试试：

ssh -i ~/.ssh/id_ed25519 admin@你的服务器IP

　　能登录成功，说明密钥配置没问题，可以继续往下走。

　　第三步：修改SSH配置文件

　　用vim或nano打开/etc/ssh/sshd_config，改下面几项：

　　禁用root远程登录：

PermitRootLogin no

　　禁用密码登录，强制使用密钥认证：

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

　　建议顺手把默认端口也改了(可选，但强烈推荐)，比如改成22522：

Port 22522

　　改端口能过滤掉大部分针对22端口的自动化扫描。

　　如果只想让特定用户登录，还可以加一行白名单：

AllowUsers admin

　　这样只有admin这个用户能通过SSH登录，其他用户一概拒绝。

　　改完之后检查一遍配置文件，确认没有语法错误：

sshd -t

　　没有任何输出就表示配置没问题。然后重启SSH服务：

systemctl restart sshd

　　这里有个关键动作：重启之后，在另一个终端用新端口、用admin用户、用密钥登录一次验证。 确认能登录成功，再关掉旧的root会话。否则万一配置哪里不对，你可能就再也连不上服务器了。

　　第四步：别忘了防火墙和安全组也要同步改

　　修改了SSH端口之后，服务器内部的防火墙和云服务商的安全组都要同步放行新端口，否则流量被挡在外面，连都连不上。

　　iptables放行示例(假设新端口是22522)：

iptables -A INPUT -p tcp --dport 22522 -j ACCEPT
iptables-save > /etc/iptables.rules

　　华纳云安全组：在控制台的安全组规则里，新增一条入站规则，协议TCP，端口22522，来源写你的办公IP或0.0.0.0/0(如果IP不固定的话)。

　　改完端口后，记得把22端口的放行规则删掉，减少暴露面。

　　这套方案的潜在风险与应对

　　风险一：密钥丢了怎么办? 私钥文件如果泄露，攻击者就能直接用你的身份登录。应对方法是给私钥再加一层密码保护(生成密钥时加-N参数)，或者定期更换密钥对。

　　风险二：万一配置错了把自己锁外面了怎么办? 不要慌，大多数云服务商都提供VNC或救援模式控制台。通过控制台登录后，把sshd_config改回去，重启服务就能恢复。如果连控制台都没有，就只能联系机房走救援模式了。

　　风险三：密钥认证失败了怎么办? 检查几个常见问题：公钥有没有正确写到authorized_keys里?文件权限是不是600?目录权限是不是700?sshd_config里PubkeyAuthentication是不是yes?都确认完还不行，看/var/log/auth.log里的报错信息。

　　长期维护建议

　　这套加固做完之后，SSH服务的攻击面已经收窄了很多。但安全是个持续的过程，以下几点值得常态化坚持：

　　1. 定期更新系统补丁，至少每月执行一次apt update && apt upgrade或yum update

　　2. 配合Fail2Ban做暴力破解防护，即便已经禁用了密码登录，也能在应用层增加一道保险

　　3. 定期审计用户列表，及时清理离职人员或不活跃的账号

　　4. 如果办公IP固定，可以在安全组里把SSH端口来源限制为特定IP，连暴露面都不留

　　说到底，禁用root登录和启用密钥认证这套组合拳，属于投入产出比极高的安全投资——花不了多少时间，但能挡住绝大部分自动化攻击。很多入侵案例的根本原因，往往就是“没关root密码登录”这种低级疏忽。别偷懒，该做的配置做上，后面能省不少心。