1. 项目概述为什么SSH安全加固是运维第一课刚接手一台新服务器或者公司新采购了一批云主机你做的第一件事是什么部署业务安装环境我的习惯是在干任何活之前必须先给SSH服务“上一把锁”。这就像你搬进新家第一件事肯定是换锁芯而不是先装修客厅。SSHSecure Shell是我们通往服务器世界的唯一大门如果这道门不牢靠后面所有的努力都可能瞬间归零。我见过太多因为SSH默认配置被攻破导致服务器沦为“肉鸡”数据被加密勒索的案例。所以今天我们就来聊聊这个看似基础实则至关重要的“SSH安全加固四板斧”免密登入、修改默认端口、禁止root登入、限制错误登入次数以及一个额外的安全模式强制修改root密码技巧。无论你是刚入行的运维新手还是需要批量管理数十上百台服务器的资深工程师这套组合拳都能为你构建起第一道坚实防线。2. SSH安全加固的核心思路与方案选型2.1 安全加固的底层逻辑从“默认”到“自定义”为什么默认的SSH配置不安全因为它是通用的、公开的。攻击者扫描互联网时默认的端口22、允许root登录、无失败限制这些信息就像贴在门上的“使用说明”。我们的目标就是抹去这些公开信息增加攻击者的成本和不确定性。方案选型的核心考量平衡安全与便利安全措施不能严重影响正常运维。例如完全禁用密码登录最安全但可能给临时登录或紧急救援带来麻烦。因此我们通常采用“密钥为主密码为辅但严格限制”的策略。防御的层次化单一措施容易被绕过。我们的四板斧构成了一个纵深防御体系修改端口第一层过滤掉大量无目的的自动化扫描。限制失败次数第二层抵御暴力破解。禁止root登录第三层即使凭证泄露攻击者也无法直接获得最高权限。使用密钥登录第四层从根本上提升认证强度。可管理性与可审计性所有操作都通过修改配置文件完成便于版本管理、批量部署和审计回溯。2.2 工具与环境准备在开始之前你需要一台Linux服务器以Ubuntu 22.04/CentOS 8为例原理通用。一个具有sudo权限的普通用户。绝对不要直接用root用户进行以下配置操作一旦配置失误导致无法登录后果严重。请先创建一个备用管理账号。本地终端Windows可使用PowerShell OpenSSH或MobaXterm、Xshell等macOS/Linux直接用系统终端。注意在进行任何关键配置修改前务必保持至少两个活跃的SSH会话。在一个会话中测试配置并重启服务如果配置错误导致无法登录你还可以通过另一个会话进行修复。这是无数前辈用血泪换来的经验。3. 核心细节解析与实操要点3.1 免密登入密钥对认证原理与优劣SSH免密登录的核心是非对称加密。你本地生成一对密钥私钥private key和公钥public key。私钥好比你家门的唯一一把钥匙必须绝对保密存放在本地公钥好比这把钥匙对应的锁芯结构可以公开需要放置到服务器的~/.ssh/authorized_keys文件中。认证流程当你连接服务器时服务器用你存放的公钥对一个随机数进行加密发回给你的客户端。你的客户端用本地私钥解密这个随机数再发回给服务器验证。如果匹配则认证通过。由于私钥从未在网络上传输因此避免了密码被嗅探或暴力破解的风险。实操心得密钥强度现在推荐使用ed25519算法它比传统的RSA更安全、更快、密钥更短。命令ssh-keygen -t ed25519 -C “your_emailexample.com”。私钥保管私钥文件默认id_ed25519的权限必须是600仅用户可读写。这是SSH客户端的强制要求权限不对会导致连接失败。公钥分发使用ssh-copy-id命令是最安全便捷的方式它会自动处理目录创建和权限设置。手动拷贝时务必确保~/.ssh目录权限为700authorized_keys文件权限为600。3.2 修改默认端口的策略与风险将SSH端口从22改为一个大于1024的非知名端口如3522可以立刻减少99%的自动化扫描和攻击脚本的骚扰。因为绝大多数扫描器只扫描22端口。风险与应对风险1端口冲突。确保你选择的新端口没有被其他服务占用。可以用ss -tulnp | grep :端口号检查。风险2忘记端口。这是最常见的“自己把自己锁门外”的操作。解决方法将新端口记录在安全的密码管理器或内部文档中。在防火墙规则或云安全组的描述里注明。连接时使用ssh -p 端口号 userhost。风险3企业防火墙限制。有些公司网络只允许出站到特定端口。修改前需与网络管理员确认。3.3 禁止Root登录的必要性与替代方案Root账户是Linux系统的超级管理员权限至高无上。允许Root直接通过SSH登录意味着攻击者一旦破解密码就能为所欲为。禁止后攻击者即使拿到一个普通用户的密码也需要再寻找本地提权漏洞难度大大增加。标准替代方案使用普通用户如admin或deploy通过SSH登录。登录后如果需要执行特权命令通过sudo来提权。为sudo配置精细的权限通过visudo编辑/etc/sudoers例如允许特定用户无需密码执行特定命令既安全又方便自动化脚本运行。3.4 限制错误登入次数的实现方式这是抵御暴力破解的关键。Fail2ban是此领域的“瑞士军刀”。它监控系统日志如/var/log/auth.log当发现来自同一IP的多次失败登录尝试可自定义次数和时间窗口后会自动调用防火墙如iptables或firewalld规则临时或永久封禁该IP地址。核心优势动态防御。相比于静态的只允许特定IP连接白名单Fail2ban更灵活它不阻止正常用户的偶然输错密码但能有效遏制持续性的自动化攻击。4. 完整实操流程与核心环节实现下面我们一步步完成整套安全加固配置。请在一个非生产环境的测试机上先完整走通流程。4.1 第一步创建备用管理账户并配置sudo在开始修改SSH配置前先确保有一条“逃生通道”。# 以root身份登录或使用已有sudo权限的用户 # 1. 创建新用户例如名为 ‘opsadmin’ adduser opsadmin # 2. 为新用户赋予sudo权限 usermod -aG sudo opsadmin # Ubuntu/Debian # 或者 CentOS/RHEL: usermod -aG wheel opsadmin # 3. 可选但推荐为新用户设置一个强密码 passwd opsadmin # 4. 立即打开一个新的终端窗口尝试用opsadmin登录 # ssh opsadmin服务器IP # 登录后尝试执行 sudo whoami验证sudo权限是否生效确保能用opsadmin用户通过密码正常登录并执行sudo命令后再进行后续操作。4.2 第二步配置SSH密钥对登录在本地客户端机器上操作# 1. 生成ED25519密钥对一路回车使用默认路径和空密码短语即可生产环境建议为密钥设密码 ssh-keygen -t ed25519 -C “opsadminworkstation” # 2. 将公钥上传到服务器的opsadmin账户 ssh-copy-id -i ~/.ssh/id_ed25519.pub opsadmin服务器IP # 系统会提示你输入opsadmin用户的密码手动部署公钥备用方法当ssh-copy-id不可用时在本地查看公钥cat ~/.ssh/id_ed25519.pub复制全部内容。登录服务器切换到opsadmin用户。确保~/.ssh目录存在且权限正确mkdir -p ~/.ssh chmod 700 ~/.ssh将复制的公钥内容追加到~/.ssh/authorized_keys文件末尾echo “粘贴你的公钥内容” ~/.ssh/authorized_keys设置正确的文件权限chmod 600 ~/.ssh/authorized_keys测试密钥登录关闭当前会话新开一个终端尝试用密钥登录此时应该不需要输入密码。ssh opsadmin服务器IP如果失败请检查服务器端/var/log/auth.log日志常见错误是.ssh目录或authorized_keys文件权限不对。4.3 第三步修改SSH服务器配置在服务器上使用opsadmin用户登录并操作# 1. 备份原始配置文件这是黄金法则。 sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak # 2. 使用vim或nano编辑SSH服务端配置文件 sudo vim /etc/ssh/sshd_config找到并修改以下参数。如果参数被注释以#开头请取消注释并修改值如果不存在则在文件末尾添加。# 修改默认端口例如改为 3522 Port 22 # 可以保留22端口作为备用但更安全的做法是只留一个。这里我们先保留测试成功后再删除。 Port 3522 # 新增一行指定新端口 # 禁止root用户直接登录 PermitRootLogin no # 启用密钥认证禁用密码认证在确认密钥登录成功后 PubkeyAuthentication yes PasswordAuthentication no # 关键先改为no但测试期间可以先保持yes最后再关闭。 # 允许使用空密码当然不 PermitEmptyPasswords no # 配置登录尝试限制需与Fail2ban配合效果更佳 MaxAuthTries 3 # 每个连接最大认证尝试次数 ClientAliveInterval 300 # 客户端活动间隔300秒 ClientAliveCountMax 2 # 客户端活动最大次数超时断开重要顺序建议按以下顺序测试先改端口用新端口能连接。再禁止root用普通用户能连接。最后再关闭密码认证确保密钥登录100%可靠。4.4 第四步安装并配置Fail2ban以Ubuntu为例# 1. 安装Fail2ban sudo apt update sudo apt install fail2ban -y # 2. 复制默认配置文件进行自定义不要直接修改jail.conf sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # 3. 编辑自定义配置文件 sudo vim /etc/fail2ban/jail.local找到[sshd]段落或在文件末尾添加进行如下配置[sshd] enabled true port 3522 # 重要这里要改成你设置的SSH新端口否则Fail2ban监控不到。 # 如果保留了22端口可以写 port ssh,3522 filter sshd logpath /var/log/auth.log maxretry 3 # 最大重试次数与SSHD的MaxAuthTries呼应 bantime 3600 # 封禁时间秒1小时 findtime 600 # 查找时间窗口秒10分钟内启动并检查Fail2ban# 启动服务并设置开机自启 sudo systemctl enable --now fail2ban # 查看状态 sudo systemctl status fail2ban # 查看sshd相关的封禁状态 sudo fail2ban-client status sshd4.5 第五步应用配置并测试这是最紧张的一步请确保你打开了两个独立的SSH会话窗口。在第一个会话窗口A中# 1. 检查SSH配置文件语法是否正确 sudo sshd -t # 2. 如果上一步没有报错则重启SSH服务 sudo systemctl restart sshd # 对于CentOS 7也可能是sudo systemctl restart sshd立即切换到第二个会话窗口B尝试用新配置登录# 使用新端口连接用户是opsadmin ssh -p 3522 opsadmin服务器IP测试场景测试密钥登录应该能直接登录无需密码。测试密码登录如果还未关闭PasswordAuthentication尝试用错误密码登录3次看是否会触发Fail2ban封禁。可以用sudo fail2ban-client status sshd查看是否有IP被ban。测试Root登录尝试ssh -p 3522 root服务器IP应该被拒绝。测试旧端口如果你删除了Port 22配置那么ssh -p 22 ...应该会连接失败Connection refused。全部测试通过后回到窗口A进行最终加固# 编辑sshd_config将PasswordAuthentication 改为 no并删除 Port 22 行如果决定不用的话 sudo vim /etc/ssh/sshd_config # 再次重启服务 sudo systemctl restart sshd4.6 第六步安全模式强制修改Root密码紧急恢复即使禁止了Root的SSH登录Root密码本身如果太弱在服务器本地或通过其他服务漏洞仍有风险。我们可以配置pam可插拔认证模块让用户首次通过su或sudo切换到root时强制要求修改密码。# 编辑PAM的system-auth配置文件不同发行版路径可能不同 # CentOS/RHEL: sudo vim /etc/pam.d/system-auth # Ubuntu/Debian: sudo vim /etc/pam.d/common-password # 在文件中找到关于password的配置行添加或修改如下 password requisite pam_pwquality.so retry3 minlen12 difok3 password required pam_unix.so sha512 shadow nullok use_authtok remember5 # 添加下面这行实现首次登录强制改密 password required pam_force.sopam_force模块可能默认未安装libpam-force包其作用是标记用户密码为“过期”状态。更通用的方法是使用chage命令# 强制root用户下次登录时必须更改密码 sudo chage -d 0 root这个命令会将root密码的“最后一次修改日期”设置为1970年1月1日系统会认为密码已过期在下次任何认证如su -、sudo提权时输入root密码时强制要求更改。这是一个非常有效的“唤醒式”安全措施适合在定期安全检查后执行。5. 常见问题与排查技巧实录即使按照步骤操作也难免会遇到问题。下面是我总结的常见“坑”和解决方法。5.1 问题配置后无法连接SSH这是最可怕的情况。排查步骤必须有序检查网络与防火墙ping 服务器IP是否通云服务器检查安全组规则是否放行了新的SSH端口如3522的入站流量服务器本地检查防火墙# Ubuntu ufw sudo ufw status sudo ufw allow 3522/tcp # CentOS firewalld sudo firewall-cmd --list-all sudo firewall-cmd --permanent --add-port3522/tcp sudo firewall-cmd --reload # 或者直接暂时关闭防火墙测试仅用于排查 sudo systemctl stop firewalld # 或 ufw disable检查SSH服务状态在另一个可用会话中执行sudo systemctl status sshd查看服务是否在运行是否有错误日志。检查SSH配置语法sudo sshd -t命令的输出会明确指出配置文件哪一行有语法错误。检查登录日志在服务器上查看/var/log/auth.log(Ubuntu) 或/var/log/secure(CentOS)。尝试连接失败后日志里会有详细的拒绝原因例如“Permission denied (publickey)”或“Invalid user”。5.2 问题密钥登录失败仍要求密码症状配置了公钥但登录时还是跳转到密码提示。排查检查服务器上对应用户的~/.ssh/authorized_keys文件权限必须是600上级目录~/.ssh权限必须是700。权限错误是首要原因。检查sshd_config中PubkeyAuthentication是否为yes。使用ssh -vvv -p 3522 userhost连接-vvv参数会输出极其详细的调试信息你可以看到客户端是否在尝试发送公钥、服务器是否接受了它等信息顺着日志就能找到问题根源。确认本地私钥路径是否正确是否使用了-i参数指定了正确的私钥文件。5.3 问题Fail2ban不生效没有封禁IP症状多次输错密码但IP没有被封。排查检查端口配置这是最常见的原因确保jail.local中[sshd]下的port 后面是你SSH服务实际监听的端口如3522而不是默认的ssh。检查日志路径确保logpath指向正确的认证日志文件。检查过滤器filter sshd使用的是/etc/fail2ban/filter.d/sshd.conf中定义的规则。可以手动测试过滤器sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf。查看Fail2ban日志sudo tail -f /var/log/fail2ban.log尝试触发几次失败登录观察日志是否有匹配和封禁动作。5.4 问题sudo操作需要频繁输入密码需求希望opsadmin用户执行sudo时不需要输入密码用于自动化脚本。解决谨慎编辑sudoers文件。sudo visudo在文件末尾添加一行opsadmin ALL(ALL) NOPASSWD: ALL警告这赋予了opsadmin用户无密码执行任何sudo命令的权限请仅在受控环境或充分信任该用户的情况下使用。更安全的做法是只对特定命令免密例如opsadmin ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/apt update。5.5 批量部署的自动化技巧当需要管理几十上百台服务器时手动操作不现实。可以采用以下方案使用Ansible编写Playbook将修改SSH配置、分发公钥、安装Fail2ban等任务自动化。Ansible基于SSH运行只需在一台控制机上操作即可。使用配置模板将优化后的sshd_config、jail.local等文件做成模板使用脚本如sed替换变量如端口号然后通过scp分发。使用云初始化脚本在创建云服务器ECS时将上述配置命令写入“用户数据”脚本实例启动时自动执行。一个简单的Ansible Playbook片段示例- name: Harden SSH Configuration hosts: all become: yes tasks: - name: Backup original sshd_config copy: src: /etc/ssh/sshd_config dest: /etc/ssh/sshd_config.bak remote_src: yes - name: Deploy hardened sshd_config template template: src: templates/sshd_config.j2 dest: /etc/ssh/sshd_config owner: root group: root mode: 0644 notify: restart sshd - name: Deploy public key for opsadmin authorized_key: user: opsadmin state: present key: “{{ lookup(‘file’, ‘~/.ssh/id_ed25519.pub’) }}” - name: Ensure .ssh directory has correct permissions file: path: /home/opsadmin/.ssh state: directory owner: opsadmin group: opsadmin mode: 0700 handlers: - name: restart sshd systemd: name: sshd state: restarted enabled: yes这套组合拳打下来你的服务器SSH入口安全性已经远超默认配置。安全是一个持续的过程不是一劳永逸的设置。定期审查日志、更新系统和软件、轮换密钥才是长治久安之道。记住最好的安全策略是“在方便与安全之间找到平衡并始终保持警惕”。 
长河君 · 2026/8/7 5:44:41 · 阅读 1.2k SSH安全加固四板斧：从原理到实战的服务器入口防护指南
1. 项目概述为什么SSH安全加固是运维第一课刚接手一台新服务器或者公司新采购了一批云主机你做的第一件事是什么部署业务安装环境我的习惯是在干任何活之前必须先给SSH服务“上一把锁”。这就像你搬进新家第一件事肯定是换锁芯而不是先装修客厅。SSHSecure Shell是我们通往服务器世界的唯一大门如果这道门不牢靠后面所有的努力都可能瞬间归零。我见过太多因为SSH默认配置被攻破导致服务器沦为“肉鸡”数据被加密勒索的案例。所以今天我们就来聊聊这个看似基础实则至关重要的“SSH安全加固四板斧”免密登入、修改默认端口、禁止root登入、限制错误登入次数以及一个额外的安全模式强制修改root密码技巧。无论你是刚入行的运维新手还是需要批量管理数十上百台服务器的资深工程师这套组合拳都能为你构建起第一道坚实防线。2. SSH安全加固的核心思路与方案选型2.1 安全加固的底层逻辑从“默认”到“自定义”为什么默认的SSH配置不安全因为它是通用的、公开的。攻击者扫描互联网时默认的端口22、允许root登录、无失败限制这些信息就像贴在门上的“使用说明”。我们的目标就是抹去这些公开信息增加攻击者的成本和不确定性。方案选型的核心考量平衡安全与便利安全措施不能严重影响正常运维。例如完全禁用密码登录最安全但可能给临时登录或紧急救援带来麻烦。因此我们通常采用“密钥为主密码为辅但严格限制”的策略。防御的层次化单一措施容易被绕过。我们的四板斧构成了一个纵深防御体系修改端口第一层过滤掉大量无目的的自动化扫描。限制失败次数第二层抵御暴力破解。禁止root登录第三层即使凭证泄露攻击者也无法直接获得最高权限。使用密钥登录第四层从根本上提升认证强度。可管理性与可审计性所有操作都通过修改配置文件完成便于版本管理、批量部署和审计回溯。2.2 工具与环境准备在开始之前你需要一台Linux服务器以Ubuntu 22.04/CentOS 8为例原理通用。一个具有sudo权限的普通用户。绝对不要直接用root用户进行以下配置操作一旦配置失误导致无法登录后果严重。请先创建一个备用管理账号。本地终端Windows可使用PowerShell OpenSSH或MobaXterm、Xshell等macOS/Linux直接用系统终端。注意在进行任何关键配置修改前务必保持至少两个活跃的SSH会话。在一个会话中测试配置并重启服务如果配置错误导致无法登录你还可以通过另一个会话进行修复。这是无数前辈用血泪换来的经验。3. 核心细节解析与实操要点3.1 免密登入密钥对认证原理与优劣SSH免密登录的核心是非对称加密。你本地生成一对密钥私钥private key和公钥public key。私钥好比你家门的唯一一把钥匙必须绝对保密存放在本地公钥好比这把钥匙对应的锁芯结构可以公开需要放置到服务器的~/.ssh/authorized_keys文件中。认证流程当你连接服务器时服务器用你存放的公钥对一个随机数进行加密发回给你的客户端。你的客户端用本地私钥解密这个随机数再发回给服务器验证。如果匹配则认证通过。由于私钥从未在网络上传输因此避免了密码被嗅探或暴力破解的风险。实操心得密钥强度现在推荐使用ed25519算法它比传统的RSA更安全、更快、密钥更短。命令ssh-keygen -t ed25519 -C “your_emailexample.com”。私钥保管私钥文件默认id_ed25519的权限必须是600仅用户可读写。这是SSH客户端的强制要求权限不对会导致连接失败。公钥分发使用ssh-copy-id命令是最安全便捷的方式它会自动处理目录创建和权限设置。手动拷贝时务必确保~/.ssh目录权限为700authorized_keys文件权限为600。3.2 修改默认端口的策略与风险将SSH端口从22改为一个大于1024的非知名端口如3522可以立刻减少99%的自动化扫描和攻击脚本的骚扰。因为绝大多数扫描器只扫描22端口。风险与应对风险1端口冲突。确保你选择的新端口没有被其他服务占用。可以用ss -tulnp | grep :端口号检查。风险2忘记端口。这是最常见的“自己把自己锁门外”的操作。解决方法将新端口记录在安全的密码管理器或内部文档中。在防火墙规则或云安全组的描述里注明。连接时使用ssh -p 端口号 userhost。风险3企业防火墙限制。有些公司网络只允许出站到特定端口。修改前需与网络管理员确认。3.3 禁止Root登录的必要性与替代方案Root账户是Linux系统的超级管理员权限至高无上。允许Root直接通过SSH登录意味着攻击者一旦破解密码就能为所欲为。禁止后攻击者即使拿到一个普通用户的密码也需要再寻找本地提权漏洞难度大大增加。标准替代方案使用普通用户如admin或deploy通过SSH登录。登录后如果需要执行特权命令通过sudo来提权。为sudo配置精细的权限通过visudo编辑/etc/sudoers例如允许特定用户无需密码执行特定命令既安全又方便自动化脚本运行。3.4 限制错误登入次数的实现方式这是抵御暴力破解的关键。Fail2ban是此领域的“瑞士军刀”。它监控系统日志如/var/log/auth.log当发现来自同一IP的多次失败登录尝试可自定义次数和时间窗口后会自动调用防火墙如iptables或firewalld规则临时或永久封禁该IP地址。核心优势动态防御。相比于静态的只允许特定IP连接白名单Fail2ban更灵活它不阻止正常用户的偶然输错密码但能有效遏制持续性的自动化攻击。4. 完整实操流程与核心环节实现下面我们一步步完成整套安全加固配置。请在一个非生产环境的测试机上先完整走通流程。4.1 第一步创建备用管理账户并配置sudo在开始修改SSH配置前先确保有一条“逃生通道”。# 以root身份登录或使用已有sudo权限的用户 # 1. 创建新用户例如名为 ‘opsadmin’ adduser opsadmin # 2. 为新用户赋予sudo权限 usermod -aG sudo opsadmin # Ubuntu/Debian # 或者 CentOS/RHEL: usermod -aG wheel opsadmin # 3. 可选但推荐为新用户设置一个强密码 passwd opsadmin # 4. 立即打开一个新的终端窗口尝试用opsadmin登录 # ssh opsadmin服务器IP # 登录后尝试执行 sudo whoami验证sudo权限是否生效确保能用opsadmin用户通过密码正常登录并执行sudo命令后再进行后续操作。4.2 第二步配置SSH密钥对登录在本地客户端机器上操作# 1. 生成ED25519密钥对一路回车使用默认路径和空密码短语即可生产环境建议为密钥设密码 ssh-keygen -t ed25519 -C “opsadminworkstation” # 2. 将公钥上传到服务器的opsadmin账户 ssh-copy-id -i ~/.ssh/id_ed25519.pub opsadmin服务器IP # 系统会提示你输入opsadmin用户的密码手动部署公钥备用方法当ssh-copy-id不可用时在本地查看公钥cat ~/.ssh/id_ed25519.pub复制全部内容。登录服务器切换到opsadmin用户。确保~/.ssh目录存在且权限正确mkdir -p ~/.ssh chmod 700 ~/.ssh将复制的公钥内容追加到~/.ssh/authorized_keys文件末尾echo “粘贴你的公钥内容” ~/.ssh/authorized_keys设置正确的文件权限chmod 600 ~/.ssh/authorized_keys测试密钥登录关闭当前会话新开一个终端尝试用密钥登录此时应该不需要输入密码。ssh opsadmin服务器IP如果失败请检查服务器端/var/log/auth.log日志常见错误是.ssh目录或authorized_keys文件权限不对。4.3 第三步修改SSH服务器配置在服务器上使用opsadmin用户登录并操作# 1. 备份原始配置文件这是黄金法则。 sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak # 2. 使用vim或nano编辑SSH服务端配置文件 sudo vim /etc/ssh/sshd_config找到并修改以下参数。如果参数被注释以#开头请取消注释并修改值如果不存在则在文件末尾添加。# 修改默认端口例如改为 3522 Port 22 # 可以保留22端口作为备用但更安全的做法是只留一个。这里我们先保留测试成功后再删除。 Port 3522 # 新增一行指定新端口 # 禁止root用户直接登录 PermitRootLogin no # 启用密钥认证禁用密码认证在确认密钥登录成功后 PubkeyAuthentication yes PasswordAuthentication no # 关键先改为no但测试期间可以先保持yes最后再关闭。 # 允许使用空密码当然不 PermitEmptyPasswords no # 配置登录尝试限制需与Fail2ban配合效果更佳 MaxAuthTries 3 # 每个连接最大认证尝试次数 ClientAliveInterval 300 # 客户端活动间隔300秒 ClientAliveCountMax 2 # 客户端活动最大次数超时断开重要顺序建议按以下顺序测试先改端口用新端口能连接。再禁止root用普通用户能连接。最后再关闭密码认证确保密钥登录100%可靠。4.4 第四步安装并配置Fail2ban以Ubuntu为例# 1. 安装Fail2ban sudo apt update sudo apt install fail2ban -y # 2. 复制默认配置文件进行自定义不要直接修改jail.conf sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # 3. 编辑自定义配置文件 sudo vim /etc/fail2ban/jail.local找到[sshd]段落或在文件末尾添加进行如下配置[sshd] enabled true port 3522 # 重要这里要改成你设置的SSH新端口否则Fail2ban监控不到。 # 如果保留了22端口可以写 port ssh,3522 filter sshd logpath /var/log/auth.log maxretry 3 # 最大重试次数与SSHD的MaxAuthTries呼应 bantime 3600 # 封禁时间秒1小时 findtime 600 # 查找时间窗口秒10分钟内启动并检查Fail2ban# 启动服务并设置开机自启 sudo systemctl enable --now fail2ban # 查看状态 sudo systemctl status fail2ban # 查看sshd相关的封禁状态 sudo fail2ban-client status sshd4.5 第五步应用配置并测试这是最紧张的一步请确保你打开了两个独立的SSH会话窗口。在第一个会话窗口A中# 1. 检查SSH配置文件语法是否正确 sudo sshd -t # 2. 如果上一步没有报错则重启SSH服务 sudo systemctl restart sshd # 对于CentOS 7也可能是sudo systemctl restart sshd立即切换到第二个会话窗口B尝试用新配置登录# 使用新端口连接用户是opsadmin ssh -p 3522 opsadmin服务器IP测试场景测试密钥登录应该能直接登录无需密码。测试密码登录如果还未关闭PasswordAuthentication尝试用错误密码登录3次看是否会触发Fail2ban封禁。可以用sudo fail2ban-client status sshd查看是否有IP被ban。测试Root登录尝试ssh -p 3522 root服务器IP应该被拒绝。测试旧端口如果你删除了Port 22配置那么ssh -p 22 ...应该会连接失败Connection refused。全部测试通过后回到窗口A进行最终加固# 编辑sshd_config将PasswordAuthentication 改为 no并删除 Port 22 行如果决定不用的话 sudo vim /etc/ssh/sshd_config # 再次重启服务 sudo systemctl restart sshd4.6 第六步安全模式强制修改Root密码紧急恢复即使禁止了Root的SSH登录Root密码本身如果太弱在服务器本地或通过其他服务漏洞仍有风险。我们可以配置pam可插拔认证模块让用户首次通过su或sudo切换到root时强制要求修改密码。# 编辑PAM的system-auth配置文件不同发行版路径可能不同 # CentOS/RHEL: sudo vim /etc/pam.d/system-auth # Ubuntu/Debian: sudo vim /etc/pam.d/common-password # 在文件中找到关于password的配置行添加或修改如下 password requisite pam_pwquality.so retry3 minlen12 difok3 password required pam_unix.so sha512 shadow nullok use_authtok remember5 # 添加下面这行实现首次登录强制改密 password required pam_force.sopam_force模块可能默认未安装libpam-force包其作用是标记用户密码为“过期”状态。更通用的方法是使用chage命令# 强制root用户下次登录时必须更改密码 sudo chage -d 0 root这个命令会将root密码的“最后一次修改日期”设置为1970年1月1日系统会认为密码已过期在下次任何认证如su -、sudo提权时输入root密码时强制要求更改。这是一个非常有效的“唤醒式”安全措施适合在定期安全检查后执行。5. 常见问题与排查技巧实录即使按照步骤操作也难免会遇到问题。下面是我总结的常见“坑”和解决方法。5.1 问题配置后无法连接SSH这是最可怕的情况。排查步骤必须有序检查网络与防火墙ping 服务器IP是否通云服务器检查安全组规则是否放行了新的SSH端口如3522的入站流量服务器本地检查防火墙# Ubuntu ufw sudo ufw status sudo ufw allow 3522/tcp # CentOS firewalld sudo firewall-cmd --list-all sudo firewall-cmd --permanent --add-port3522/tcp sudo firewall-cmd --reload # 或者直接暂时关闭防火墙测试仅用于排查 sudo systemctl stop firewalld # 或 ufw disable检查SSH服务状态在另一个可用会话中执行sudo systemctl status sshd查看服务是否在运行是否有错误日志。检查SSH配置语法sudo sshd -t命令的输出会明确指出配置文件哪一行有语法错误。检查登录日志在服务器上查看/var/log/auth.log(Ubuntu) 或/var/log/secure(CentOS)。尝试连接失败后日志里会有详细的拒绝原因例如“Permission denied (publickey)”或“Invalid user”。5.2 问题密钥登录失败仍要求密码症状配置了公钥但登录时还是跳转到密码提示。排查检查服务器上对应用户的~/.ssh/authorized_keys文件权限必须是600上级目录~/.ssh权限必须是700。权限错误是首要原因。检查sshd_config中PubkeyAuthentication是否为yes。使用ssh -vvv -p 3522 userhost连接-vvv参数会输出极其详细的调试信息你可以看到客户端是否在尝试发送公钥、服务器是否接受了它等信息顺着日志就能找到问题根源。确认本地私钥路径是否正确是否使用了-i参数指定了正确的私钥文件。5.3 问题Fail2ban不生效没有封禁IP症状多次输错密码但IP没有被封。排查检查端口配置这是最常见的原因确保jail.local中[sshd]下的port 后面是你SSH服务实际监听的端口如3522而不是默认的ssh。检查日志路径确保logpath指向正确的认证日志文件。检查过滤器filter sshd使用的是/etc/fail2ban/filter.d/sshd.conf中定义的规则。可以手动测试过滤器sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf。查看Fail2ban日志sudo tail -f /var/log/fail2ban.log尝试触发几次失败登录观察日志是否有匹配和封禁动作。5.4 问题sudo操作需要频繁输入密码需求希望opsadmin用户执行sudo时不需要输入密码用于自动化脚本。解决谨慎编辑sudoers文件。sudo visudo在文件末尾添加一行opsadmin ALL(ALL) NOPASSWD: ALL警告这赋予了opsadmin用户无密码执行任何sudo命令的权限请仅在受控环境或充分信任该用户的情况下使用。更安全的做法是只对特定命令免密例如opsadmin ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/apt update。5.5 批量部署的自动化技巧当需要管理几十上百台服务器时手动操作不现实。可以采用以下方案使用Ansible编写Playbook将修改SSH配置、分发公钥、安装Fail2ban等任务自动化。Ansible基于SSH运行只需在一台控制机上操作即可。使用配置模板将优化后的sshd_config、jail.local等文件做成模板使用脚本如sed替换变量如端口号然后通过scp分发。使用云初始化脚本在创建云服务器ECS时将上述配置命令写入“用户数据”脚本实例启动时自动执行。一个简单的Ansible Playbook片段示例- name: Harden SSH Configuration hosts: all become: yes tasks: - name: Backup original sshd_config copy: src: /etc/ssh/sshd_config dest: /etc/ssh/sshd_config.bak remote_src: yes - name: Deploy hardened sshd_config template template: src: templates/sshd_config.j2 dest: /etc/ssh/sshd_config owner: root group: root mode: 0644 notify: restart sshd - name: Deploy public key for opsadmin authorized_key: user: opsadmin state: present key: “{{ lookup(‘file’, ‘~/.ssh/id_ed25519.pub’) }}” - name: Ensure .ssh directory has correct permissions file: path: /home/opsadmin/.ssh state: directory owner: opsadmin group: opsadmin mode: 0700 handlers: - name: restart sshd systemd: name: sshd state: restarted enabled: yes这套组合拳打下来你的服务器SSH入口安全性已经远超默认配置。安全是一个持续的过程不是一劳永逸的设置。定期审查日志、更新系统和软件、轮换密钥才是长治久安之道。记住最好的安全策略是“在方便与安全之间找到平衡并始终保持警惕”。