SSH端口和登录方式的安全设置，核心就两条：改掉默认22端口，禁用密码登录改用密钥认证，做完这两步，绝大多数自动化爆破攻击基本就失效了。
很多人的服务器被入侵，问题不是出在系统漏洞，而是SSH服务裸奔在默认端口上，还开着密码登录，服务器一上线，全网扫描器几分钟就能找到你，然后开始暴力破解，本文从实际运维场景出发，给出具体操作路径,帮你把SSH这扇门彻底锁好。
为什么你的服务器总是被暴力破解
22端口是黑客的"默认门牌号"
默认22端口是SSH服务的标准入口，这意味着全球所有扫描工具都优先探测这个端口，业内专家指出，互联网上针对22端口的暴力破解攻击从未停止过，任何暴露公网的IP在几小时内就会收到来自不同来源的扫描和尝试登录请求。
举个具体场景：你刚买了一台云服务器，配置好SSH工作正常，第二天查看登录日志，发现几十条来自海外IP的登录失败记录，这不是针对你，而是自动化的扫描程序在批量撒网,碰巧扫到了你。
密码登录是最大的"后门"
密码登录方式本身就有天然缺陷：人类设置的密码强度有限，容易复用，而且无法阻止暴力尝试，即便你设置了一个强密码，理论上也架不住持续的字典攻击，更麻烦的是密码登录日志中不会记录输入来源的键盘特征,一旦泄露完全无法追溯。
相比之下，密钥认证的强度是指数级的，它使用非对称加密，私钥长度动辄2048位或4096位,暴力破解的计算量在物理上就不现实。
SSH端口修改教程：关键一步，立竿见影
第一步：修改sshd_config配置文件
登录服务器后,直接编辑SSH主配置文件：
sudo vim /etc/ssh/sshd_config找到 #Port 22 这一行，去掉注释，把22改成你想要的高位端口号。端口范围可选1024-65535之间，建议避开常见服务端口如3306、6379等，防止混淆，举例：Port 28462,一个随机高位端口足够隐蔽。
保存退出后，务必先测试再重启服务
,防止把自己锁在外面：
sudo sshd -t # 检查语法
sudo systemctl restart sshd第二步：防火墙同步规则
修改端口后，防火墙和云平台安全组必须同步放行新端口，这一步漏了,你会发现SSH直接连不上。
以firewalld为例：
sudo firewall-cmd --permanent --add-port=28462/tcp
sudo firewall-cmd --reload同时删除旧的22端口放行规则，登录测试确认新端口正常后,再考虑关闭22端口。
第三步：验证新端口生效
另开一个终端,使用新端口连接：
ssh -p 28462 用户名@服务器IP连接成功后，回到服务器上确认监听状态已经变为新端口，并且22端口不再监听,才算彻底切换完成。
SSH密钥登录怎么配置：比密码安全一个量级
生成密钥对并部署到服务器
在本地电脑（不是服务器）上生成密钥对：
ssh-keygen -t ed25519 -C "icloud-2026-ssh"推荐ed25519算法，密钥短、速度快、安全性高，也可以选择rsa -b 4096,但ed25519更符合当前行业共识。
一路回车默认保存到 ~/.ssh/id_ed25519，然后使用ssh-copy-id将公钥部署到服务器：
ssh-copy-id -p 28462 用户名@服务器IP也可以手动追加公钥到服务器的 ~/.ssh/authorized_keys 文件中，注意确保该文件权限为600，.ssh 目录权限为700。
禁用密码登录：终极设置
密钥部署成功并确认可以正常登录后,修改sshd_config：
PasswordAuthentication no
PubkeyAuthentication yes重启sshd服务后，密码登录方式彻底关闭，此时哪怕知道密码也进不来,只有持有私钥的设备才能访问。
多台服务器场景下的密钥策略
管理多台服务器时，建议为不同安全级别的机器使用不同的密钥对，把线上生产环境的私钥单独存放，并设置强密码保护私钥本身（passphrase）,防止本地电脑被攻破导致密钥泄露。
| 对比维度 | 密码登录 | 密钥登录 |
|---|---|---|
| 暴力破解难度 | 较低，持续尝试即可 | 极高，计算上不可行 |
| 密码泄露风险 | 存在（撞库、钓鱼） | 私钥本地持有 |
| 多服务器管理 | 密码需各自独立 | 可分发公钥集中管控 |
| 审计追溯 | 日志仅记录IP | 可按密钥区分访问者 |
SSH安全加固进阶配置：从可用到安全
限制登录用户和IP白名单
在sshd_config中指定允许登录的用户：
AllowUsers admin deploy这行配置见效快，效果明确只有这两个用户可以SSH登录，其余用户一律拒绝，如果办公IP固定，可以叠加防火墙规则白名单，只允许特定IP访问SSH端口，多数情况下移动办公场景不合适,但固定工位场景强烈建议。
开启Fail2Ban拦截恶意IP
Fail2ban是Linux下主流的入侵防御工具，它监测SSH登录日志，发现连续失败自动封禁来源IP,配置操作路径：
sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local修改 jail.local 中 [sshd] 段落：
enabled = true
port = 28462
maxretry = 3
bantime = 3600设置含义：连续3次失败，封禁1小时,这套机制能自动过滤掉绝大多数批量攻击来源。
使用非root账号管理服务器
root账号拥有全部权限，默认是攻击者的第一目标，创建普通用户，赋予sudo权限,使用普通用户登录后再提权操作：
sudo useradd -m -s /bin/bash admin
sudo usermod -aG sudo admin在sshd_config中设置 PermitRootLogin no，不给root任何直接登录的机会。所有操作都通过普通用户+sudo执行，日志可追溯,避免误操作造成不可逆损伤。
监控登录日志和异常行为
养成定期检查登录日志的习惯,查看所有登录记录：
sudo journalctl -u ssh -n 200或查看auth日志：
sudo tail -f /var/log/auth.log关注持续失败登录、异常时间的成功登录、非预期IP来源，自动化报警可以用简单的cron脚本+邮件通知来实现,检测到连续失败记录自动发送告警。
SSH安全设置的常见误区
只改端口不关密码登录
改端口只是提高了攻击门槛，并没有改变认证方式的安全等级，如果新端口被探测到，密码暴力破解依旧可以推进，安全核心是密钥认证,改端口只是辅助手段。
密钥文件不设口令
私钥本身泄露等同于账号沦陷，生成私钥时设置passphrase，每次使用私钥时输入口令验证，配合ssh-agent可以避免频繁输入口令,既安全又方便。
认为内网服务器不需要加固
很多人在阿里酷番云上做了安全设置，但内网服务器之间不设防，实际运维中，内网机器一旦被横向移动攻破，可以做很多事情了。内网SSH同样应该用密钥登录,设置一致的安全基线。
关于SSH安全设置的Q&A
修改SSH端口会不会影响现有业务？
不会。 SSH端口与应用服务端口是两套独立体系，修改22为新端口后,只需注意：
- 防火墙、安全组同步放行新端口
- 所有自动化脚本中的连接端口同步更新，包括rsync、git、ansible等工具
- 监控系统探测SSH端口的配置同步修改
做好这三处同步,业务无感切换。
SSH登录失败太多，如何快速排查？
首先查看错误日志定位原因：
sudo tail -100 /var/log/auth.log | grep Failed常见情况有：密钥不匹配、authorized_keys权限错误、用户名拼写错误、新端口未同步到防火墙，按顺序验证端口连通性、密钥格式、服务状态即可,多数情况下是防火墙规则遗漏导致的。
服务器被入侵了怎么判断是否通过SSH进来的？
查看登录记录是最直接的判断方式，检查 /var/log/auth.log 中是否有非预期的成功登录记录，同时查看 ~/.ssh/authorized_keys 是否被篡改添加了新密钥，如果确认被入侵，立即吊销当前密钥对、检查系统用户列表，并排查是否有setuid后门文件，安全事件处理优先断开网络再取证分析,避免攻击者通过已植入的后门持续控制机器。