1. 从“方便”到“安全”一次服务器被扫后的SSH加固实战那天凌晨三点手机突然收到一串告警短信提示一台放在公网上的测试服务器有大量来自未知IP的SSH登录尝试。虽然这台机器上没什么重要数据但看着日志里密密麻麻的“Failed password for root from...”记录后背还是有点发凉。这让我意识到很多朋友包括曾经的我在配置服务器时往往只图一个“方便”——用默认的22端口允许root直接登录密码也设置得比较简单。这种“出厂设置”在互联网上无异于在闹市区把家门钥匙挂在锁眼上。SSHSecure Shell是我们管理远程服务器的生命线但这条线如果保护不当也会成为攻击者入侵的捷径。这次事件促使我系统地梳理和加固了所有服务器的SSH配置。今天要聊的就是一套从“基础便捷”到“生产级安全”的SSH配置组合拳涵盖了免密登录、修改默认端口、禁止root登录、限制错误登录次数以及一个很多人忽略但非常实用的安全模式强制修改root密码。无论你是刚接触Linux的新手还是有一定经验的运维这套配置都能让你的服务器安全等级提升好几个档次。我们不仅要知道怎么做更要明白为什么这么做以及每一步背后的安全逻辑。2. 基石配置密钥对认证与免密登录在讨论安全加固之前我们得先解决一个基本矛盾既要安全强密码又要方便不用每次输密码。密码认证PasswordAuthentication是SSH最原始的认证方式但它有几个致命弱点容易被暴力破解密码可能被键盘记录或中间人攻击截获手动输入既麻烦又容易出错。因此我们的第一步就是用更安全、更便捷的密钥对认证Public Key Authentication来替代它。2.1 密钥对的工作原理非对称加密的妙用简单来说密钥对包含一把公钥和一把私钥。公钥可以公开就像一把打开的锁私钥必须严格保密就像唯一能打开那把锁的钥匙。当你尝试连接服务器时客户端会用你的私钥对一个随机生成的挑战码进行签名服务器用事先存储好的公钥来验证这个签名。验证通过则身份确认。这个过程完全避免了密码在网络上的传输从根源上杜绝了密码被窃听的风险。同时由于私钥通常有密码保护且长度远超普通密码如RSA 2048位暴力破解的难度呈指数级上升。2.2 生成与部署密钥手把手操作指南首先在你的本地机器客户端上生成密钥对。通常使用ssh-keygen命令。ssh-keygen -t rsa -b 4096 -C your_emailexample.com -f ~/.ssh/my_server_key-t rsa: 指定密钥类型为RSA。目前Ed25519也是安全且高效的选择可以用-t ed25519。-b 4096: 指定密钥长度为4096位更高的位数更安全。-C: 添加一个注释通常用邮箱方便标识。-f: 指定生成密钥文件的路径和名称。如果不指定默认生成在~/.ssh/id_rsa私钥和~/.ssh/id_rsa.pub公钥。执行命令后它会提示你输入一个密码来加密私钥文件Passphrase。这里强烈建议设置一个强密码。这样即使私钥文件被盗攻击者也无法直接使用。之后会生成两个文件my_server_key私钥和my_server_key.pub公钥。接下来将公钥部署到目标服务器。最安全可靠的方法是使用ssh-copy-id命令ssh-copy-id -i ~/.ssh/my_server_key.pub useryour_server_ip这条命令会自动将你的公钥内容追加到服务器上对应用户家目录下的~/.ssh/authorized_keys文件中。如果该文件或目录不存在它会自动创建并设置正确的权限700 for~/.ssh, 600 forauthorized_keys这一点非常关键错误的权限会导致SSH拒绝使用密钥认证。注意ssh-copy-id默认使用22端口。如果你的服务器SSH端口已修改我们接下来就会做需要加上-p参数指定端口例如ssh-copy-id -i ~/.ssh/my_server_key.pub -p 2222 useryour_server_ip。部署成功后尝试登录如果设置了私钥密码会提示输入私钥密码而非服务器用户密码。为了进一步方便可以使用ssh-agent来管理私钥密码实现一次输入多次使用。2.3 配置SSH服务端彻底关闭密码认证密钥配置妥当并测试成功后我们就可以在服务器上关闭危险的密码认证了。编辑SSH服务端配置文件/etc/ssh/sshd_configsudo vim /etc/ssh/sshd_config找到并修改以下行PasswordAuthentication no PubkeyAuthentication yesPasswordAuthentication no: 彻底禁用密码认证。从此不知道密钥的攻击者连尝试密码的机会都没有。PubkeyAuthentication yes: 确保公钥认证是开启的默认通常是yes。修改后务必重启SSH服务使配置生效sudo systemctl restart sshd # 对于使用systemd的系统如Ubuntu 16.04, CentOS 7 # 或 sudo service ssh restart # 对于使用SysV init的系统重要提示在重启服务前请务必确保你已经用密钥成功登录过一次并且当前有一个活跃的、通过密钥认证的SSH会话。这是你的“救命通道”。如果配置错误导致无法登录你还可以通过这个活跃会话进行修复。对于云服务器通常还有VNC控制台作为最后的手段。3. 降低被攻击面修改默认端口与禁用Root登录完成了认证方式的升级我们开始收缩服务器的暴露面。攻击者通常使用自动化工具扫描整个IP段默认的22端口是首要目标。同时root这个超级管理员账户名是尽人皆知的。3.1 修改默认SSH端口让扫描器扑个空修改端口不能从根本上阻止攻击但能过滤掉99%的自动化脚本和低水平扫描。这些脚本为了效率通常只扫描22等少数常见端口。修改端口后日志会清净很多。继续编辑/etc/ssh/sshd_config#Port 22 Port 2222 # 或其他1024-65535之间未被占用的端口注意Port 22那一行默认被注释了我们取消注释并修改或者直接新增一行Port 2222。建议保留#Port 22的注释行作为备份参考。端口选择建议选择大于1024的端口1024以下为知名端口需要root权限监听。避免使用像2222、22222这样过于“明显”的替代端口。确保选择的端口在服务器防火墙如ufwfirewalldiptables中是放行的。修改后同样需要重启SSH服务。此后客户端连接时需要显式指定端口ssh -p 2222 useryour_server_ip为了方便可以在本地客户端的~/.ssh/config文件中为服务器配置别名Host myserver HostName your_server_ip Port 2222 User your_username IdentityFile ~/.ssh/my_server_key配置后只需执行ssh myserver即可连接。3.2 禁止Root用户直接登录遵循最小权限原则直接以root身份远程登录是极危险的做法。一旦密钥泄露或密码被破解攻击者将立即获得系统最高权限。最佳实践是禁止root直接SSH登录使用普通用户登录后再通过sudo提权执行管理任务。在/etc/ssh/sshd_config中修改PermitRootLogin no这个设置强制所有远程登录都必须先通过一个普通用户账户。这带来了多重好处增加攻击难度攻击者需要同时破解一个有效的用户名和其对应的密钥/密码。审计清晰所有sudo操作都会被记录在/var/log/auth.log或/var/log/secure中方便追踪谁在什么时候执行了什么特权命令。减少误操作风险在普通用户下误执行毁灭性命令如rm -rf /会受到权限限制给你一个反悔的机会。修改后重启SSH服务。务必提前创建一个具有sudo权限的普通用户。4. 主动防御限制失败登录尝试与账户锁定即使我们用了密钥、改了端口、禁了root服务器仍然可能收到恶意登录尝试比如攻击者猜到了你的用户名和端口。这些尝试本身不构成威胁但会填满日志消耗资源。我们可以使用工具来主动限制这些行为。4.1 使用Fail2ban进行动态封禁Fail2ban是一个经典的入侵防御框架它监控系统日志如/var/log/auth.log根据定义的正则表达式匹配失败登录等恶意行为。当某个IP在特定时间内的失败次数超过阈值Fail2ban会自动调用防火墙规则如iptables将该IP封禁一段时间。安装与配置以Ubuntu/Debian为例sudo apt update sudo apt install fail2banFail2ban的配置文件通常在/etc/fail2ban/。不建议直接修改jail.conf而是创建本地覆盖文件jail.localsudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo vim /etc/fail2ban/jail.local找到[sshd]段落进行配置注意如果你的端口不是22配置需要调整[sshd] enabled true port 2222 # 改为你实际的SSH端口 filter sshd logpath /var/log/auth.log maxretry 5 # 最大尝试次数 findtime 600 # 在10分钟600秒内 bantime 3600 # 封禁1小时3600秒maxretry和findtime共同定义了触发条件在findtime时间内失败maxretry次则触发封禁。bantime是封禁的时长。由于我们修改了SSH端口还需要确保Fail2ban的action封禁动作能正确操作防火墙。对于默认的iptables通常无需修改。配置完成后启动并设置开机自启sudo systemctl start fail2ban sudo systemctl enable fail2ban你可以通过sudo fail2ban-client status sshd查看当前被禁的IP列表。4.2 系统内置的PAM模块pam_tally2除了Fail2banLinux的PAM可插拔认证模块也提供了账户锁定功能。pam_tally2模块可以在连续多次认证失败后直接锁定用户账户而不仅仅是封IP解锁需要管理员手动操作。编辑PAM的SSH配置文件/etc/pam.d/sshd或/etc/pam.d/login取决于系统在文件开头附近添加auth required pam_tally2.so deny5 unlock_time600 onerrsucceed file/var/log/tallylog这表示连续5次认证失败后账户将被锁定600秒。同时需要在/etc/ssh/sshd_config中确保UsePAM yes是开启的。使用pam_tally2 --user username查看用户失败次数用pam_tally2 --user username --reset重置计数并解锁。注意对于密钥认证失败PAM可能不会计数因为认证在PAM介入前就失败了。pam_tally2更适用于密码认证场景。在已禁用密码认证的环境中Fail2ban基于日志分析是更合适的端口扫描和暴力破解防御工具。5. 最后的防线安全模式与强制修改Root密码前面我们禁止了root的SSH登录但root密码本身可能还是弱的默认密码。如果攻击者通过其他漏洞比如Web应用漏洞获得了本地shell权限他们可能会尝试su或sudo su来提权到root这时root密码的强度就至关重要。5.1 为何需要强制修改弱密码很多云镜像或系统安装后root密码可能是随机的、空密码或简单的默认密码。管理员可能觉得反正不用密码登录就忽略了修改它。这留下了一个安全隐患。我们可以通过配置让系统在用户首次登录或定期时强制要求修改密码。5.2 使用chage命令管理密码过期策略chage命令是管理用户密码过期信息的强大工具。我们可以通过它强制用户包括root在下一次登录时修改密码。sudo chage -d 0 root-d 0: 将密码最后一次修改日期设置为“纪元”1970年1月1日。这会让系统认为root密码已经过期从而在root用户下一次通过任何方式如su,sudo -i登录时强制要求更改密码。执行后你可以用sudo chage -l root查看root账户的密码策略会看到“Last password change”是一个很久以前的日期并且“Password expires”和“Password inactive”都是“password must be changed”。操作流程管理员在服务器上执行sudo chage -d 0 root。当需要执行需要root权限的操作时管理员使用普通用户登录然后执行su -或sudo -i。系统会提示“You are required to change your password immediately (root enforced)”并引导你输入当前root密码旧的弱密码然后设置两次新的强密码。修改成功后才能获得root shell。5.3 结合Cron任务实现定期强制修改对于安全要求极高的环境可以设置定期强制修改root密码的策略。虽然root通常不直接登录但定期更新其密码仍是好习惯。可以通过cron任务结合chage实现。例如创建一个脚本/usr/local/bin/force_root_pw_change.sh#!/bin/bash # 强制root密码立即过期 chage -d 0 root # 可选发送通知给管理员 echo Root password has been expired and must be changed on next privilege escalation. | mail -s Root Password Change Alert adminexample.com然后通过crontab每月1号执行一次sudo crontab -e # 添加一行 0 0 1 * * /usr/local/bin/force_root_pw_change.sh这样每个月管理员都需要在第一次提权到root时修改密码。请注意这增加了管理开销请根据实际安全需求权衡。6. 完整配置检查清单与故障排查完成以上所有步骤后你的/etc/ssh/sshd_config文件应该包含类似以下的关键行注释和无关行已省略Port 2222 # 自定义端口 PermitRootLogin no # 禁止root登录 PubkeyAuthentication yes # 启用公钥认证 PasswordAuthentication no # 禁用密码认证 ChallengeResponseAuthentication no # 通常也禁用 UsePAM yes # 如果使用pam_tally2则需要yes AllowUsers your_username # (可选) 白名单只允许特定用户登录重启SSH服务sudo systemctl restart sshd6.1 连接测试与验证在关闭当前SSH会话前务必打开一个新的终端窗口测试所有新配置是否生效测试新端口和密钥登录ssh -p 2222 your_usernameserver_ip应该能直接通过密钥登录。测试密码登录是否被拒ssh -o PubkeyAuthenticationno -p 2222 your_usernameserver_ip应该提示“Permission denied (publickey)”。测试root登录是否被拒ssh -p 2222 rootserver_ip即使有root的密钥也应该提示“Permission denied (publickey)”或者更早的“Permission denied (root not allowed)”。6.2 常见故障与排查问题修改配置后无法连接检查确保防火墙放行了新的SSH端口。sudo ufw status或sudo firewall-cmd --list-all。检查确认sshd服务正在运行且监听在新端口。sudo ss -tlnp | grep :2222。检查确认sshd_config语法无误。sudo sshd -t测试配置语法不实际重启服务。最后手段通过云平台控制台或物理VNC登录服务器检查配置文件和日志/var/log/auth.log。问题密钥登录失败检查服务器上~/.ssh/authorized_keys文件的权限必须是600~/.ssh目录权限必须是700。检查sshd_config中PubkeyAuthentication是否为yes。检查使用ssh -vvv参数输出详细调试信息查看密钥认证在哪一步失败。问题Fail2ban不生效检查sudo systemctl status fail2ban查看服务状态。检查sudo fail2ban-client status sshd查看sshd监狱是否激活和被禁IP。检查日志路径logpath是否正确过滤规则filter是否匹配你的日志格式特别是如果你自定义了日志格式。安全配置是一个持续的过程而非一劳永逸的设置。这套组合拳——密钥认证、隐藏端口、禁用root、主动防御和密码策略——构成了SSH访问的基础安全框架。它极大地提高了攻击者的门槛将你的服务器从“默认的脆弱”变成了“定制的坚固”。在实际运维中还可以根据情况考虑添加双因素认证2FA、仅允许从特定IP段访问AllowUsers/AllowGroups配合IP限制等更高级的措施。记住安全的核心在于层次化防御没有单一银弹但每一步扎实的加固都在为你的数据和服务增添一份保障。 
长河君 · 2026/8/8 3:14:26 · 阅读 1.2k SSH安全加固实战：从密钥认证到主动防御的服务器防护指南
1. 从“方便”到“安全”一次服务器被扫后的SSH加固实战那天凌晨三点手机突然收到一串告警短信提示一台放在公网上的测试服务器有大量来自未知IP的SSH登录尝试。虽然这台机器上没什么重要数据但看着日志里密密麻麻的“Failed password for root from...”记录后背还是有点发凉。这让我意识到很多朋友包括曾经的我在配置服务器时往往只图一个“方便”——用默认的22端口允许root直接登录密码也设置得比较简单。这种“出厂设置”在互联网上无异于在闹市区把家门钥匙挂在锁眼上。SSHSecure Shell是我们管理远程服务器的生命线但这条线如果保护不当也会成为攻击者入侵的捷径。这次事件促使我系统地梳理和加固了所有服务器的SSH配置。今天要聊的就是一套从“基础便捷”到“生产级安全”的SSH配置组合拳涵盖了免密登录、修改默认端口、禁止root登录、限制错误登录次数以及一个很多人忽略但非常实用的安全模式强制修改root密码。无论你是刚接触Linux的新手还是有一定经验的运维这套配置都能让你的服务器安全等级提升好几个档次。我们不仅要知道怎么做更要明白为什么这么做以及每一步背后的安全逻辑。2. 基石配置密钥对认证与免密登录在讨论安全加固之前我们得先解决一个基本矛盾既要安全强密码又要方便不用每次输密码。密码认证PasswordAuthentication是SSH最原始的认证方式但它有几个致命弱点容易被暴力破解密码可能被键盘记录或中间人攻击截获手动输入既麻烦又容易出错。因此我们的第一步就是用更安全、更便捷的密钥对认证Public Key Authentication来替代它。2.1 密钥对的工作原理非对称加密的妙用简单来说密钥对包含一把公钥和一把私钥。公钥可以公开就像一把打开的锁私钥必须严格保密就像唯一能打开那把锁的钥匙。当你尝试连接服务器时客户端会用你的私钥对一个随机生成的挑战码进行签名服务器用事先存储好的公钥来验证这个签名。验证通过则身份确认。这个过程完全避免了密码在网络上的传输从根源上杜绝了密码被窃听的风险。同时由于私钥通常有密码保护且长度远超普通密码如RSA 2048位暴力破解的难度呈指数级上升。2.2 生成与部署密钥手把手操作指南首先在你的本地机器客户端上生成密钥对。通常使用ssh-keygen命令。ssh-keygen -t rsa -b 4096 -C your_emailexample.com -f ~/.ssh/my_server_key-t rsa: 指定密钥类型为RSA。目前Ed25519也是安全且高效的选择可以用-t ed25519。-b 4096: 指定密钥长度为4096位更高的位数更安全。-C: 添加一个注释通常用邮箱方便标识。-f: 指定生成密钥文件的路径和名称。如果不指定默认生成在~/.ssh/id_rsa私钥和~/.ssh/id_rsa.pub公钥。执行命令后它会提示你输入一个密码来加密私钥文件Passphrase。这里强烈建议设置一个强密码。这样即使私钥文件被盗攻击者也无法直接使用。之后会生成两个文件my_server_key私钥和my_server_key.pub公钥。接下来将公钥部署到目标服务器。最安全可靠的方法是使用ssh-copy-id命令ssh-copy-id -i ~/.ssh/my_server_key.pub useryour_server_ip这条命令会自动将你的公钥内容追加到服务器上对应用户家目录下的~/.ssh/authorized_keys文件中。如果该文件或目录不存在它会自动创建并设置正确的权限700 for~/.ssh, 600 forauthorized_keys这一点非常关键错误的权限会导致SSH拒绝使用密钥认证。注意ssh-copy-id默认使用22端口。如果你的服务器SSH端口已修改我们接下来就会做需要加上-p参数指定端口例如ssh-copy-id -i ~/.ssh/my_server_key.pub -p 2222 useryour_server_ip。部署成功后尝试登录如果设置了私钥密码会提示输入私钥密码而非服务器用户密码。为了进一步方便可以使用ssh-agent来管理私钥密码实现一次输入多次使用。2.3 配置SSH服务端彻底关闭密码认证密钥配置妥当并测试成功后我们就可以在服务器上关闭危险的密码认证了。编辑SSH服务端配置文件/etc/ssh/sshd_configsudo vim /etc/ssh/sshd_config找到并修改以下行PasswordAuthentication no PubkeyAuthentication yesPasswordAuthentication no: 彻底禁用密码认证。从此不知道密钥的攻击者连尝试密码的机会都没有。PubkeyAuthentication yes: 确保公钥认证是开启的默认通常是yes。修改后务必重启SSH服务使配置生效sudo systemctl restart sshd # 对于使用systemd的系统如Ubuntu 16.04, CentOS 7 # 或 sudo service ssh restart # 对于使用SysV init的系统重要提示在重启服务前请务必确保你已经用密钥成功登录过一次并且当前有一个活跃的、通过密钥认证的SSH会话。这是你的“救命通道”。如果配置错误导致无法登录你还可以通过这个活跃会话进行修复。对于云服务器通常还有VNC控制台作为最后的手段。3. 降低被攻击面修改默认端口与禁用Root登录完成了认证方式的升级我们开始收缩服务器的暴露面。攻击者通常使用自动化工具扫描整个IP段默认的22端口是首要目标。同时root这个超级管理员账户名是尽人皆知的。3.1 修改默认SSH端口让扫描器扑个空修改端口不能从根本上阻止攻击但能过滤掉99%的自动化脚本和低水平扫描。这些脚本为了效率通常只扫描22等少数常见端口。修改端口后日志会清净很多。继续编辑/etc/ssh/sshd_config#Port 22 Port 2222 # 或其他1024-65535之间未被占用的端口注意Port 22那一行默认被注释了我们取消注释并修改或者直接新增一行Port 2222。建议保留#Port 22的注释行作为备份参考。端口选择建议选择大于1024的端口1024以下为知名端口需要root权限监听。避免使用像2222、22222这样过于“明显”的替代端口。确保选择的端口在服务器防火墙如ufwfirewalldiptables中是放行的。修改后同样需要重启SSH服务。此后客户端连接时需要显式指定端口ssh -p 2222 useryour_server_ip为了方便可以在本地客户端的~/.ssh/config文件中为服务器配置别名Host myserver HostName your_server_ip Port 2222 User your_username IdentityFile ~/.ssh/my_server_key配置后只需执行ssh myserver即可连接。3.2 禁止Root用户直接登录遵循最小权限原则直接以root身份远程登录是极危险的做法。一旦密钥泄露或密码被破解攻击者将立即获得系统最高权限。最佳实践是禁止root直接SSH登录使用普通用户登录后再通过sudo提权执行管理任务。在/etc/ssh/sshd_config中修改PermitRootLogin no这个设置强制所有远程登录都必须先通过一个普通用户账户。这带来了多重好处增加攻击难度攻击者需要同时破解一个有效的用户名和其对应的密钥/密码。审计清晰所有sudo操作都会被记录在/var/log/auth.log或/var/log/secure中方便追踪谁在什么时候执行了什么特权命令。减少误操作风险在普通用户下误执行毁灭性命令如rm -rf /会受到权限限制给你一个反悔的机会。修改后重启SSH服务。务必提前创建一个具有sudo权限的普通用户。4. 主动防御限制失败登录尝试与账户锁定即使我们用了密钥、改了端口、禁了root服务器仍然可能收到恶意登录尝试比如攻击者猜到了你的用户名和端口。这些尝试本身不构成威胁但会填满日志消耗资源。我们可以使用工具来主动限制这些行为。4.1 使用Fail2ban进行动态封禁Fail2ban是一个经典的入侵防御框架它监控系统日志如/var/log/auth.log根据定义的正则表达式匹配失败登录等恶意行为。当某个IP在特定时间内的失败次数超过阈值Fail2ban会自动调用防火墙规则如iptables将该IP封禁一段时间。安装与配置以Ubuntu/Debian为例sudo apt update sudo apt install fail2banFail2ban的配置文件通常在/etc/fail2ban/。不建议直接修改jail.conf而是创建本地覆盖文件jail.localsudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo vim /etc/fail2ban/jail.local找到[sshd]段落进行配置注意如果你的端口不是22配置需要调整[sshd] enabled true port 2222 # 改为你实际的SSH端口 filter sshd logpath /var/log/auth.log maxretry 5 # 最大尝试次数 findtime 600 # 在10分钟600秒内 bantime 3600 # 封禁1小时3600秒maxretry和findtime共同定义了触发条件在findtime时间内失败maxretry次则触发封禁。bantime是封禁的时长。由于我们修改了SSH端口还需要确保Fail2ban的action封禁动作能正确操作防火墙。对于默认的iptables通常无需修改。配置完成后启动并设置开机自启sudo systemctl start fail2ban sudo systemctl enable fail2ban你可以通过sudo fail2ban-client status sshd查看当前被禁的IP列表。4.2 系统内置的PAM模块pam_tally2除了Fail2banLinux的PAM可插拔认证模块也提供了账户锁定功能。pam_tally2模块可以在连续多次认证失败后直接锁定用户账户而不仅仅是封IP解锁需要管理员手动操作。编辑PAM的SSH配置文件/etc/pam.d/sshd或/etc/pam.d/login取决于系统在文件开头附近添加auth required pam_tally2.so deny5 unlock_time600 onerrsucceed file/var/log/tallylog这表示连续5次认证失败后账户将被锁定600秒。同时需要在/etc/ssh/sshd_config中确保UsePAM yes是开启的。使用pam_tally2 --user username查看用户失败次数用pam_tally2 --user username --reset重置计数并解锁。注意对于密钥认证失败PAM可能不会计数因为认证在PAM介入前就失败了。pam_tally2更适用于密码认证场景。在已禁用密码认证的环境中Fail2ban基于日志分析是更合适的端口扫描和暴力破解防御工具。5. 最后的防线安全模式与强制修改Root密码前面我们禁止了root的SSH登录但root密码本身可能还是弱的默认密码。如果攻击者通过其他漏洞比如Web应用漏洞获得了本地shell权限他们可能会尝试su或sudo su来提权到root这时root密码的强度就至关重要。5.1 为何需要强制修改弱密码很多云镜像或系统安装后root密码可能是随机的、空密码或简单的默认密码。管理员可能觉得反正不用密码登录就忽略了修改它。这留下了一个安全隐患。我们可以通过配置让系统在用户首次登录或定期时强制要求修改密码。5.2 使用chage命令管理密码过期策略chage命令是管理用户密码过期信息的强大工具。我们可以通过它强制用户包括root在下一次登录时修改密码。sudo chage -d 0 root-d 0: 将密码最后一次修改日期设置为“纪元”1970年1月1日。这会让系统认为root密码已经过期从而在root用户下一次通过任何方式如su,sudo -i登录时强制要求更改密码。执行后你可以用sudo chage -l root查看root账户的密码策略会看到“Last password change”是一个很久以前的日期并且“Password expires”和“Password inactive”都是“password must be changed”。操作流程管理员在服务器上执行sudo chage -d 0 root。当需要执行需要root权限的操作时管理员使用普通用户登录然后执行su -或sudo -i。系统会提示“You are required to change your password immediately (root enforced)”并引导你输入当前root密码旧的弱密码然后设置两次新的强密码。修改成功后才能获得root shell。5.3 结合Cron任务实现定期强制修改对于安全要求极高的环境可以设置定期强制修改root密码的策略。虽然root通常不直接登录但定期更新其密码仍是好习惯。可以通过cron任务结合chage实现。例如创建一个脚本/usr/local/bin/force_root_pw_change.sh#!/bin/bash # 强制root密码立即过期 chage -d 0 root # 可选发送通知给管理员 echo Root password has been expired and must be changed on next privilege escalation. | mail -s Root Password Change Alert adminexample.com然后通过crontab每月1号执行一次sudo crontab -e # 添加一行 0 0 1 * * /usr/local/bin/force_root_pw_change.sh这样每个月管理员都需要在第一次提权到root时修改密码。请注意这增加了管理开销请根据实际安全需求权衡。6. 完整配置检查清单与故障排查完成以上所有步骤后你的/etc/ssh/sshd_config文件应该包含类似以下的关键行注释和无关行已省略Port 2222 # 自定义端口 PermitRootLogin no # 禁止root登录 PubkeyAuthentication yes # 启用公钥认证 PasswordAuthentication no # 禁用密码认证 ChallengeResponseAuthentication no # 通常也禁用 UsePAM yes # 如果使用pam_tally2则需要yes AllowUsers your_username # (可选) 白名单只允许特定用户登录重启SSH服务sudo systemctl restart sshd6.1 连接测试与验证在关闭当前SSH会话前务必打开一个新的终端窗口测试所有新配置是否生效测试新端口和密钥登录ssh -p 2222 your_usernameserver_ip应该能直接通过密钥登录。测试密码登录是否被拒ssh -o PubkeyAuthenticationno -p 2222 your_usernameserver_ip应该提示“Permission denied (publickey)”。测试root登录是否被拒ssh -p 2222 rootserver_ip即使有root的密钥也应该提示“Permission denied (publickey)”或者更早的“Permission denied (root not allowed)”。6.2 常见故障与排查问题修改配置后无法连接检查确保防火墙放行了新的SSH端口。sudo ufw status或sudo firewall-cmd --list-all。检查确认sshd服务正在运行且监听在新端口。sudo ss -tlnp | grep :2222。检查确认sshd_config语法无误。sudo sshd -t测试配置语法不实际重启服务。最后手段通过云平台控制台或物理VNC登录服务器检查配置文件和日志/var/log/auth.log。问题密钥登录失败检查服务器上~/.ssh/authorized_keys文件的权限必须是600~/.ssh目录权限必须是700。检查sshd_config中PubkeyAuthentication是否为yes。检查使用ssh -vvv参数输出详细调试信息查看密钥认证在哪一步失败。问题Fail2ban不生效检查sudo systemctl status fail2ban查看服务状态。检查sudo fail2ban-client status sshd查看sshd监狱是否激活和被禁IP。检查日志路径logpath是否正确过滤规则filter是否匹配你的日志格式特别是如果你自定义了日志格式。安全配置是一个持续的过程而非一劳永逸的设置。这套组合拳——密钥认证、隐藏端口、禁用root、主动防御和密码策略——构成了SSH访问的基础安全框架。它极大地提高了攻击者的门槛将你的服务器从“默认的脆弱”变成了“定制的坚固”。在实际运维中还可以根据情况考虑添加双因素认证2FA、仅允许从特定IP段访问AllowUsers/AllowGroups配合IP限制等更高级的措施。记住安全的核心在于层次化防御没有单一银弹但每一步扎实的加固都在为你的数据和服务增添一份保障。