Important

云服务器一旦暴露公网,SSH 扫描和暴力破解几乎是“秒级发生”的事情。
本文以 Debian 13 为例,在不禁止 root 登录的前提下,通过以下三项核心措施完成基础防护:

适合个人 VPS、学习服务器、轻量生产环境。


一、修改 SSH 端口到 50000 以上

1. 修改 SSH 服务端配置文件

SSH 服务端的配置文件路径是固定的:

/etc/ssh/sshd_config

使用 root 编辑:

nano /etc/ssh/sshd_config

在文件中 找到或新增 以下配置(注意不要重复):

Port 50222
AddressFamily inet
PermitRootLogin yes

说明:

如果原有配置前面有 #,需要去掉注释。


2. 重启 SSH 服务

systemctl restart ssh

3. 验证 SSH 是否监听新端口

ss -lntp | grep ssh

应看到类似:

0.0.0.0:50222

4. 新窗口测试登录

ssh -p 50222 root@服务器IP

确认可以正常登录后,再进行下一步。


二、生成 SSH 密钥(本地操作)

密钥必须在你用来连接服务器的那台电脑上生成,不是在服务器上。

1. 在本地终端执行

ssh-keygen -t ed25519

一路回车即可:

生成完成后,会得到两个文件:

ls ~/.ssh
id_ed25519
id_ed25519.pub

说明:


三、将 root 公钥上传到服务器

此时你仍然可以用 root + 密码 登录服务器,这是最后一次使用密码。


方法一(推荐):ssh-copy-id

在本地执行:

ssh-copy-id -p 50222 root@服务器IP

输入一次 root 密码即可。

该命令会自动完成:


方法二(手动方式,理解原理)

1. 本地查看公钥内容

cat ~/.ssh/id_ed25519.pub

复制输出的整一行。


2. 使用密码登录服务器

ssh -p 50222 root@服务器IP

3. 在服务器上执行

mkdir -p /root/.ssh
chmod 700 /root/.ssh
nano /root/.ssh/authorized_keys

将公钥粘贴进去,保存退出。


4. 设置文件权限

chmod 600 /root/.ssh/authorized_keys

5. 验证密钥登录是否生效

在本地新开一个终端:

ssh -p 50222 root@服务器IP

正确表现:

确认成功后,才能进入下一步。


四、禁止密码登录,仅允许密钥登录

1. 修改 SSH 配置

nano /etc/ssh/sshd_config

确认或修改以下配置:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

PubkeyAuthentication yes
PermitRootLogin yes

说明:


2. 重启 SSH

systemctl restart ssh

3. 再次验证

ssh -p 50222 root@服务器IP

如果还能输入服务器密码,说明配置未生效,不要继续。


五、安装并配置 Fail2Ban(阻止扫描与爆破)

1. 安装 Fail2Ban

apt update
apt install -y fail2ban

2. 创建本地配置文件

不要直接修改 jail.conf,而是创建:

nano /etc/fail2ban/jail.local

写入以下内容:

[DEFAULT]
bantime  = 1d
findtime = 10m
maxretry = 3
backend  = systemd

[sshd]
enabled  = true
port     = 50222
logpath  = %(sshd_log)s

含义:


3. 启动并设置开机自启

systemctl enable fail2ban
systemctl restart fail2ban

4. 查看 Fail2Ban 状态

fail2ban-client status
fail2ban-client status sshd

5. 查看已封禁 IP

fail2ban-client get sshd banned

六、(可选)启用基础防火墙

apt install -y ufw
ufw allow 50222/tcp
ufw enable

七、最终安全状态总结

完成以上步骤后,你的 Debian 13 云服务器将具备:


结语

真正有效的服务器安全并不是“禁止一切”,而是在使用习惯、风险与运维成本之间取得平衡
在允许 root 登录的现实前提下,上述方案已经能覆盖绝大多数公网攻击场景。

后续可进一步加强的方向包括: