1. 项目概述从“能用”到“抗揍”的SSH安全加固实战如果你管理过任何一台暴露在公网的Linux服务器那么对“SSH端口22被疯狂扫描”这个场景一定不会陌生。我的邮箱里几乎每天都能收到来自各种监控系统的告警提示有未知IP尝试用root和常见密码进行暴力破解。这就像把自家大门钥匙挂在门口总有不怀好意的人来试试锁芯。今天要聊的就是如何把这扇“大门”从普通的木门升级成带有指纹锁、监控探头和防撞结构的金库门。这不是什么高深的理论而是一套经过多年运维实战、可以直接“抄作业”的SSH安全加固组合拳涵盖了免密登入、修改默认端口、禁止root登入、限制错误登入次数以及一个很多人忽略但至关重要的“安全模式强制修改root密码”。我们不止讲配置更会深入每个配置背后的攻防逻辑让你知其然更知其所以然。2. SSH安全加固的核心思路与设计考量2.1 威胁模型分析攻击者到底在干什么在动手之前我们必须清楚对手是谁。针对SSH的自动化攻击其行为模式高度一致可以概括为“扫、猜、撞”三部曲。第一步扫描Scanning。攻击者利用工具如masscan,zmap对互联网IP段进行高速扫描专门探测22端口SSH默认端口的开放状态。一旦发现端口开放且服务为OpenSSH该IP地址就会被标记并加入待攻击列表。这个过程是全自动且7x24小时不间断的。第二步用户名枚举与密码猜测Guessing。攻击脚本会使用一个庞大的用户名和密码字典进行组合尝试。最常用的用户名就是root其次是admin、test、ubuntu、centos等系统常见用户名。密码字典则包含诸如123456、password、admin123以及各种默认密码和弱密码。第三步暴力破解Brute-force。如果简单的字典攻击不成功一些更“执着”的攻击者会采用更复杂的暴力破解策略尝试更多的用户名密码组合。我们的加固策略就是针对这三个步骤层层设防大幅提高攻击者的成本和难度迫使其放弃。2.2 加固策略总览纵深防御体系单一的安全措施很容易被绕过因此我们需要建立一个纵深防御体系。本次实战的五个措施构成了三道防线第一道防线降低被发现的概率修改默认端口。将SSH服务从众所周知的22端口迁移到一个高位随机端口如35222。这能过滤掉绝大部分广撒网式的自动化扫描因为扫描全端口的速度和成本远高于只扫22端口。第二道防线增加认证难度禁止root登入直接封堵攻击者最常用的突破口。即使攻击者猜到了密码也无法直接获取最高权限。使用密钥对认证免密登入用非对称加密的密钥对替代密码。从理论上讲暴力破解一个足够强度的私钥如RSA 4096位在现有计算能力下是不可能的。限制错误登入次数通过fail2ban或MaxAuthTries等机制短时间内多次认证失败即封禁IP。这是对抗暴力破解最直接有效的手段。第三道防线应急与兜底安全模式强制修改root密码。这是一个补救和强化措施。当系统因其他原因如弱密码、密钥泄露面临风险时能够提供一个强制修改最高权限密码的入口确保最后一道闸门是坚固的。这个体系的核心思想是隐匿、加固、监控、补救。接下来我们进入实操环节。3. 核心配置解析与实操要点3.1 基石使用SSH密钥对实现免密登入密码认证的弱点在于其在线验证和可猜测性。SSH密钥认证采用非对称加密服务器持有公钥客户端持有私钥。认证时服务器用公钥加密一个随机挑战只有持有对应私钥的客户端才能解密并回应从而证明身份。操作步骤在客户端生成密钥对如果还没有ssh-keygen -t rsa -b 4096 -C “your_emailexample.com” -f ~/.ssh/my_server_key-t rsa: 指定密钥类型为RSA。ed25519是更现代、更高效的选择但兼容性略逊于RSA。-b 4096: 指定密钥长度为4096位。2048位是目前的最低安全标准4096位能提供更强的安全保障以应对未来算力提升。-C: 添加一个注释通常用邮箱便于识别。-f: 指定密钥文件的保存路径和名称。不指定则默认为~/.ssh/id_rsa。将公钥上传到服务器ssh-copy-id -i ~/.ssh/my_server_key.pub useryour_server_ip -p 22这个命令会将你的公钥内容自动追加到服务器对应用户家目录下的~/.ssh/authorized_keys文件中。这是最安全便捷的方式。可选但推荐在服务器上优化authorized_keys文件权限chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh过于宽松的权限可能导致SSH拒绝使用密钥文件。关键配置文件 (/etc/ssh/sshd_config)PubkeyAuthentication yes # 启用公钥认证 AuthorizedKeysFile .ssh/authorized_keys # 指定公钥文件路径 PasswordAuthentication no # 在确认密钥登录成功后关闭密码认证重要警告在将PasswordAuthentication设置为no之前务必新开一个终端窗口使用密钥成功登录一次服务器。否则一旦配置错误你将永远无法登录建议先设置为PasswordAuthentication yes和PubkeyAuthentication yes测试密钥登录无误后再关闭密码认证。3.2 隐身术修改SSH默认监听端口修改端口不能算加密但它是非常有效的“安全通过隐匿”策略。将服务从默认端口移走能避开绝大多数自动化脚本的第一轮扫描。操作步骤选择端口号选择一个在1024到65535之间且不常用的端口。避免使用2222,222等常见替代端口。可以使用命令netstat -tunlp | grep ‘:’查看当前已占用的端口。修改SSH配置sudo vim /etc/ssh/sshd_config找到#Port 22这一行去掉注释#并将22改为你选择的端口例如Port 35222。可以保留Port 22并新增一行Port 35222进行双端口运行测试待新端口确认无误后再关闭22端口这样更稳妥。配置防火墙如果使用firewalldsudo firewall-cmd --permanent --add-port35222/tcp sudo firewall-cmd --reload如果使用ufwsudo ufw allow 35222/tcp sudo ufw reload如果使用iptablessudo iptables -A INPUT -p tcp --dport 35222 -j ACCEPT # 记得保存规则例如在CentOS上: service iptables save重启SSH服务并测试sudo systemctl restart sshd # 在新终端测试连接注意指定端口 ssh -p 35222 useryour_server_ip测试成功后再回到配置文件注释掉或删除Port 22那一行再次重启sshd。3.3 斩首行动禁止root用户直接登录root账户是系统的皇帝也是攻击者的头号目标。禁止其直接登录意味着即使攻击者通过某种方式获得了root密码也无法直接远程登录。他们必须先以一个普通用户身份登录然后再通过su或sudo提权这为我们设置了第二道关卡并且所有提权操作都会被记录在案。配置方法在/etc/ssh/sshd_config中修改或添加PermitRootLogin no重启SSH服务后生效。之后你需要使用一个普通用户登录然后使用sudo -i或su -来切换到root环境。实操心得在禁止root登录前请确保你至少有一个拥有sudo权限的普通用户。创建命令sudo adduser username然后sudo usermod -aG sudo username(Ubuntu/Debian) 或sudo usermod -aG wheel username(CentOS/RHEL)。3.4 主动防御使用fail2ban限制错误登录次数fail2ban是一个经典的入侵防御框架它监控系统日志如/var/log/auth.log当发现同一IP在短时间内有多次失败登录尝试时会自动调用防火墙规则如iptables, firewalld将该IP封禁一段时间。安装与配置安装fail2ban# Ubuntu/Debian sudo apt update sudo apt install fail2ban -y # CentOS/RHEL sudo yum install epel-release -y sudo yum install fail2ban -y创建本地配置文件避免升级被覆盖sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local配置SSH防护规则编辑/etc/fail2ban/jail.local找到[sshd]段落进行如下修改注意如果你修改了SSH端口配置需相应调整[sshd] enabled true port 35222 # 改为你的SSH端口多个端口用空格隔开如 port ssh,35222 filter sshd logpath /var/log/auth.log # CentOS/RHEL可能是 /var/log/secure maxretry 5 # 最大重试次数 findtime 600 # 在10分钟内 bantime 3600 # 禁止1小时maxretry和findtime定义了触发条件在findtime秒内失败maxretry次则触发。bantime是封禁时长秒。可以设置为-1永久封禁但通常不建议可能误封。启动并设置开机自启sudo systemctl start fail2ban sudo systemctl enable fail2ban检查状态sudo fail2ban-client status sshd # 查看sshd监狱状态 sudo fail2ban-client status # 查看所有监狱状态注意事项确保你的防火墙iptables/firewalld正在运行因为fail2ban通过添加防火墙规则来封禁IP。小心不要把自己锁在外面。在配置和测试阶段最好在本地虚拟机或另一个网络环境如手机热点保留一个测试连接。fail2ban可以防护很多服务如nginx, vsftpd只需启用对应的[jail]即可。4. 深度加固安全模式强制修改root密码这是一个进阶且非常实用的安全措施。它的场景是当你接手一台旧服务器或者怀疑root密码可能已泄露时你可以在服务器本地或通过远程控制台引导系统进入一个特殊的安全模式。在此模式下系统会强制要求你为root账户设置一个新密码然后才能继续正常启动。这确保了即使之前密码被窃取你也能立即重置夺回控制权。实现原理通过修改Linux系统的引导加载器通常是GRUB的内核参数让系统启动时直接运行passwd命令来修改root密码而不是正常的登录流程。操作步骤以GRUB2为例这是目前大多数发行版的默认引导器重启服务器在GRUB菜单出现时快速按下e键进入编辑模式。如果你使用云服务器通常需要通过VNC或云平台提供的“连接管理终端”来操作。找到以linux或linuxefi开头的行。这一行定义了内核启动参数。它可能看起来像这样linux /vmlinuz-5.4.0-xx-generic root/dev/mapper/ubuntu--vg-root ro quiet splash修改内核参数将光标移动到该行末尾。首先删除quiet和splash这类安静启动参数以便能看到启动过程的信息。然后在行末添加init/bin/bash。修改后的行类似linux /vmlinuz-5.4.0-xx-generic root/dev/mapper/ubuntu--vg-root ro init/bin/bash这个参数告诉内核不要启动常规的初始化系统如systemd或init而是直接启动一个bash shell。按CtrlX或F10用这些参数启动系统。系统会很快启动并直接给你一个root权限的bash提示符通常是#此时文件系统可能处于只读状态。重新挂载根文件系统为可读写并修改密码mount -o remount,rw / passwd输入并确认两遍新的root密码。你会看到passwd: password updated successfully的提示。同步数据并重启sync exec /sbin/init # 或者直接 reboot -fsync命令确保所有缓存数据写入磁盘。exec /sbin/init会以正常方式重新启动初始化进程使系统完整启动。之后你就可以用新设置的root密码通过之前配置的普通用户su上来了。严重警告此操作有风险需在物理机或可靠的虚拟化控制台进行。操作错误可能导致系统无法启动。务必在操作前确认你拥有服务器的物理或带外管理如iDRAC, iLO, IPMI访问权限。对于云服务器确保控制台连接可用。5. 综合配置与自动化部署脚本将以上所有配置整合并实现一定程度的自动化是运维效率的关键。下面是一个示例的sshd_config最终配置片段和部署思路。/etc/ssh/sshd_config关键配置汇总# 端口设置 Port 35222 # 禁用root登录 PermitRootLogin no # 启用密钥认证 PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # 禁用密码认证确保密钥登录测试成功后再开启 PasswordAuthentication no # 禁用空密码 PermitEmptyPasswords no # 使用更安全的协议版本 Protocol 2 # 限制认证尝试次数与fail2ban配合 MaxAuthTries 3 # 禁用不安全的认证方法 ChallengeResponseAuthentication no # 启用严格模式检查密钥和目录权限 StrictModes yes # 可选的限制可登录的用户或用户组 # AllowUsers your_username # AllowGroups ssh-users自动化部署脚本思路对于需要批量管理多台服务器的情况可以编写一个Ansible Playbook或Shell脚本。以下是一个简单的Shell脚本框架#!/bin/bash # deploy_ssh_hardening.sh set -e # 遇到错误即退出 SSH_PORT”35222” ADMIN_USER”deployer” SSH_KEY_PUB”$(cat ~/.ssh/id_rsa.pub)” # 1. 备份原配置 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %Y%m%d) # 2. 使用sed或cat修改sshd_config # 这里是一个示例实际应用应更严谨使用模板或ansible的lineinfile模块更好 cat /tmp/new_sshd_config EOF Port $SSH_PORT PermitRootLogin no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no PermitEmptyPasswords no Protocol 2 MaxAuthTries 3 ChallengeResponseAuthentication no UsePAM yes PrintMotd no Subsystem sftp /usr/lib/openssh/sftp-server EOF # 合并原有配置和新配置简化处理生产环境需更精细 mv /tmp/new_sshd_config /etc/ssh/sshd_config # 3. 创建管理员用户并授权sudo useradd -m -s /bin/bash $ADMIN_USER echo “$ADMIN_USER ALL(ALL) NOPASSWD:ALL” /etc/sudoers.d/$ADMIN_USER chmod 440 /etc/sudoers.d/$ADMIN_USER # 4. 部署公钥 mkdir -p /home/$ADMIN_USER/.ssh echo “$SSH_KEY_PUB” /home/$ADMIN_USER/.ssh/authorized_keys chmod 700 /home/$ADMIN_USER/.ssh chmod 600 /home/$ADMIN_USER/.ssh/authorized_keys chown -R $ADMIN_USER:$ADMIN_USER /home/$ADMIN_USER/.ssh # 5. 配置防火墙假设使用firewalld firewall-cmd --permanent --remove-servicessh # 移除默认22端口规则 firewall-cmd --permanent --add-port$SSH_PORT/tcp firewall-cmd --reload # 6. 安装并配置fail2ban yum install -y epel-release fail2ban || apt update apt install -y fail2ban systemctl enable --now fail2ban # 7. 重启SSH服务谨慎最好在另一个会话测试新端口后再执行 echo “配置完成。请在另一个终端使用 ‘ssh -p $SSH_PORT $ADMIN_USER服务器IP’ 测试连接。” echo “测试成功后再回到本终端按回车重启sshd…” read -p “按回车继续重启SSH服务…” systemctl restart sshd echo “SSH安全加固部署完成。”警告此类脚本具有破坏性务必先在测试环境中验证并确保在运行时有备用的登录方式如云控制台。6. 常见问题排查与运维技巧实录即使按照最佳实践操作在实际运维中仍会遇到各种问题。这里记录了几个最典型的“坑”和解决方法。6.1 问题修改SSH端口后无法连接排查思路检查服务状态sudo systemctl status sshd查看服务是否正常运行有无报错。检查端口监听sudo netstat -tlnp | grep sshd或sudo ss -tlnp | grep :35222。确认sshd进程是否在监听你配置的端口。检查防火墙这是最常见的原因。确认防火墙已放行新端口。对于firewalldsudo firewall-cmd --list-all对于ufwsudo ufw status verbose。检查云平台安全组/网络ACL如果你使用的是阿里云、AWS、腾讯云等云服务器必须在云控制台的安全组规则中添加入方向规则允许你的新SSH端口如35222/TCP。检查SELinux在某些系统如CentOS上SELinux可能会阻止SSH绑定非标准端口。可以临时禁用SELinux测试setenforce 0或者为SSH添加非标准端口标签semanage port -a -t ssh_port_t -p tcp 35222。使用telnet或nc测试从客户端使用telnet 服务器IP 35222或nc -zv 服务器IP 35222。如果能连接上看到SSH横幅或连接成功说明网络和端口是通的问题可能在客户端配置或密钥认证上。6.2 问题配置密钥登录后依然要求输入密码排查思路服务器端authorized_keys文件权限确保是600所属用户和家目录权限正确。SSH对此要求非常严格。服务器端sshd_config配置确认PubkeyAuthentication yes且PasswordAuthentication no或yes但你想用密钥。客户端私钥权限本地私钥文件如~/.ssh/id_rsa权限应为600。使用-v参数调试在客户端连接时添加多个-v参数如ssh -vvv -p 35222 userserver_ip。输出会非常详细通常会明确指出认证在哪一步失败例如“Permission denied (publickey)”或“Offering public key”。仔细阅读输出信息。检查密钥类型较新版本的OpenSSH可能默认禁用某些较弱的密钥类型如ssh-rsa。确保你生成的密钥类型是受支持的。使用ssh-keygen -l -f your_key.pub查看密钥指纹和类型。6.3 问题fail2ban不生效IP没有被封禁排查思路检查fail2ban服务状态sudo systemctl status fail2ban。检查监狱状态sudo fail2ban-client status sshd查看“Currently failed”和“Total banned”计数。检查日志路径确认jail.local中[sshd]下的logpath指向了正确的系统认证日志文件。Ubuntu/Debian通常是/var/log/auth.logCentOS/RHEL是/var/log/secure。手动测试过滤器fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf。这个命令会测试日志文件是否匹配fail2ban的过滤规则。检查防火墙后端fail2ban需要调用本地防火墙。检查jail.local中的banaction设置通常是iptables或firewalld并确保对应的防火墙服务正在运行。查看fail2ban日志sudo tail -f /var/log/fail2ban.log。当你尝试用错误密码登录几次后观察日志是否有封禁动作的记录。6.4 运维技巧如何安全地批量更新密钥当团队人员变动或密钥需要轮换时批量更新authorized_keys是个敏感操作。使用版本控制与自动化将服务器的authorized_keys文件内容管理在Git仓库中每个授权密钥作为一行。使用Ansible、SaltStack或Puppet等工具将仓库中的文件分发到所有服务器。这样可以清晰追溯谁在什么时候添加/移除了谁的密钥。使用ssh-copy-id的替代方案对于单次添加ssh-copy-id是最佳选择。对于脚本化操作可以使用以下命令组合PUB_KEY”ssh-rsa AAAAB3NzaC1yc2E... userhost” SSH_PORT”35222” SERVER”userserver_ip” ssh -p $SSH_PORT $SERVER “mkdir -p ~/.ssh echo ‘$PUB_KEY’ ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys”但要注意如果多次执行会导致authorized_keys文件中出现重复行。密钥集中管理工具考虑使用更专业的方案如HashiCorp Vault的SSH秘密引擎或者FreeIPA、Red Hat IdM这类身份管理系统它们能提供动态的、基于时间的SSH证书无需在每台服务器上维护静态的authorized_keys文件安全性更高。6.5 终极安全建议拥抱证书认证CA对于大型或对安全要求极高的环境SSH密钥对管理会变得繁琐。SSH证书认证SSH Certificate Authentication是更优的解决方案。它类似于HTTPS的SSL证书你建立一个内部的SSH证书颁发机构CA。CA为每个用户或主机签署一个短期有效的证书如一天或一周。服务器信任CA的公钥客户端持有由CA签名的证书。认证时服务器验证证书的签名和有效期。优势吊销方便无需到每台服务器删除密钥只需在CA吊销证书即可。自动过期证书短期有效减少了密钥长期泄露的风险。细粒度授权可以在证书中嵌入登录的用户名、允许访问的主机、有效期等元数据。虽然初始设置比密钥对复杂但对于需要管理成百上千台服务器和用户的企业环境证书认证在安全性和可管理性上具有压倒性优势。OpenSSH本身支持证书认证相关命令是ssh-keygen的-s签名和-K生成CA等选项。这套从基础到进阶的SSH安全加固方案几乎能抵御99%的自动化网络攻击。安全是一个过程而不是一个状态。定期审计检查/var/log/auth.log或/var/log/secure、及时更新系统和服务sudo apt update sudo apt upgrade、以及遵循最小权限原则与这些配置同样重要。记住没有绝对的安全但我们可以让攻击者的成本高到无法承受。
1. 项目概述从“能用”到“抗揍”的SSH安全加固实战如果你管理过任何一台暴露在公网的Linux服务器那么对“SSH端口22被疯狂扫描”这个场景一定不会陌生。我的邮箱里几乎每天都能收到来自各种监控系统的告警提示有未知IP尝试用root和常见密码进行暴力破解。这就像把自家大门钥匙挂在门口总有不怀好意的人来试试锁芯。今天要聊的就是如何把这扇“大门”从普通的木门升级成带有指纹锁、监控探头和防撞结构的金库门。这不是什么高深的理论而是一套经过多年运维实战、可以直接“抄作业”的SSH安全加固组合拳涵盖了免密登入、修改默认端口、禁止root登入、限制错误登入次数以及一个很多人忽略但至关重要的“安全模式强制修改root密码”。我们不止讲配置更会深入每个配置背后的攻防逻辑让你知其然更知其所以然。2. SSH安全加固的核心思路与设计考量2.1 威胁模型分析攻击者到底在干什么在动手之前我们必须清楚对手是谁。针对SSH的自动化攻击其行为模式高度一致可以概括为“扫、猜、撞”三部曲。第一步扫描Scanning。攻击者利用工具如masscan,zmap对互联网IP段进行高速扫描专门探测22端口SSH默认端口的开放状态。一旦发现端口开放且服务为OpenSSH该IP地址就会被标记并加入待攻击列表。这个过程是全自动且7x24小时不间断的。第二步用户名枚举与密码猜测Guessing。攻击脚本会使用一个庞大的用户名和密码字典进行组合尝试。最常用的用户名就是root其次是admin、test、ubuntu、centos等系统常见用户名。密码字典则包含诸如123456、password、admin123以及各种默认密码和弱密码。第三步暴力破解Brute-force。如果简单的字典攻击不成功一些更“执着”的攻击者会采用更复杂的暴力破解策略尝试更多的用户名密码组合。我们的加固策略就是针对这三个步骤层层设防大幅提高攻击者的成本和难度迫使其放弃。2.2 加固策略总览纵深防御体系单一的安全措施很容易被绕过因此我们需要建立一个纵深防御体系。本次实战的五个措施构成了三道防线第一道防线降低被发现的概率修改默认端口。将SSH服务从众所周知的22端口迁移到一个高位随机端口如35222。这能过滤掉绝大部分广撒网式的自动化扫描因为扫描全端口的速度和成本远高于只扫22端口。第二道防线增加认证难度禁止root登入直接封堵攻击者最常用的突破口。即使攻击者猜到了密码也无法直接获取最高权限。使用密钥对认证免密登入用非对称加密的密钥对替代密码。从理论上讲暴力破解一个足够强度的私钥如RSA 4096位在现有计算能力下是不可能的。限制错误登入次数通过fail2ban或MaxAuthTries等机制短时间内多次认证失败即封禁IP。这是对抗暴力破解最直接有效的手段。第三道防线应急与兜底安全模式强制修改root密码。这是一个补救和强化措施。当系统因其他原因如弱密码、密钥泄露面临风险时能够提供一个强制修改最高权限密码的入口确保最后一道闸门是坚固的。这个体系的核心思想是隐匿、加固、监控、补救。接下来我们进入实操环节。3. 核心配置解析与实操要点3.1 基石使用SSH密钥对实现免密登入密码认证的弱点在于其在线验证和可猜测性。SSH密钥认证采用非对称加密服务器持有公钥客户端持有私钥。认证时服务器用公钥加密一个随机挑战只有持有对应私钥的客户端才能解密并回应从而证明身份。操作步骤在客户端生成密钥对如果还没有ssh-keygen -t rsa -b 4096 -C “your_emailexample.com” -f ~/.ssh/my_server_key-t rsa: 指定密钥类型为RSA。ed25519是更现代、更高效的选择但兼容性略逊于RSA。-b 4096: 指定密钥长度为4096位。2048位是目前的最低安全标准4096位能提供更强的安全保障以应对未来算力提升。-C: 添加一个注释通常用邮箱便于识别。-f: 指定密钥文件的保存路径和名称。不指定则默认为~/.ssh/id_rsa。将公钥上传到服务器ssh-copy-id -i ~/.ssh/my_server_key.pub useryour_server_ip -p 22这个命令会将你的公钥内容自动追加到服务器对应用户家目录下的~/.ssh/authorized_keys文件中。这是最安全便捷的方式。可选但推荐在服务器上优化authorized_keys文件权限chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh过于宽松的权限可能导致SSH拒绝使用密钥文件。关键配置文件 (/etc/ssh/sshd_config)PubkeyAuthentication yes # 启用公钥认证 AuthorizedKeysFile .ssh/authorized_keys # 指定公钥文件路径 PasswordAuthentication no # 在确认密钥登录成功后关闭密码认证重要警告在将PasswordAuthentication设置为no之前务必新开一个终端窗口使用密钥成功登录一次服务器。否则一旦配置错误你将永远无法登录建议先设置为PasswordAuthentication yes和PubkeyAuthentication yes测试密钥登录无误后再关闭密码认证。3.2 隐身术修改SSH默认监听端口修改端口不能算加密但它是非常有效的“安全通过隐匿”策略。将服务从默认端口移走能避开绝大多数自动化脚本的第一轮扫描。操作步骤选择端口号选择一个在1024到65535之间且不常用的端口。避免使用2222,222等常见替代端口。可以使用命令netstat -tunlp | grep ‘:’查看当前已占用的端口。修改SSH配置sudo vim /etc/ssh/sshd_config找到#Port 22这一行去掉注释#并将22改为你选择的端口例如Port 35222。可以保留Port 22并新增一行Port 35222进行双端口运行测试待新端口确认无误后再关闭22端口这样更稳妥。配置防火墙如果使用firewalldsudo firewall-cmd --permanent --add-port35222/tcp sudo firewall-cmd --reload如果使用ufwsudo ufw allow 35222/tcp sudo ufw reload如果使用iptablessudo iptables -A INPUT -p tcp --dport 35222 -j ACCEPT # 记得保存规则例如在CentOS上: service iptables save重启SSH服务并测试sudo systemctl restart sshd # 在新终端测试连接注意指定端口 ssh -p 35222 useryour_server_ip测试成功后再回到配置文件注释掉或删除Port 22那一行再次重启sshd。3.3 斩首行动禁止root用户直接登录root账户是系统的皇帝也是攻击者的头号目标。禁止其直接登录意味着即使攻击者通过某种方式获得了root密码也无法直接远程登录。他们必须先以一个普通用户身份登录然后再通过su或sudo提权这为我们设置了第二道关卡并且所有提权操作都会被记录在案。配置方法在/etc/ssh/sshd_config中修改或添加PermitRootLogin no重启SSH服务后生效。之后你需要使用一个普通用户登录然后使用sudo -i或su -来切换到root环境。实操心得在禁止root登录前请确保你至少有一个拥有sudo权限的普通用户。创建命令sudo adduser username然后sudo usermod -aG sudo username(Ubuntu/Debian) 或sudo usermod -aG wheel username(CentOS/RHEL)。3.4 主动防御使用fail2ban限制错误登录次数fail2ban是一个经典的入侵防御框架它监控系统日志如/var/log/auth.log当发现同一IP在短时间内有多次失败登录尝试时会自动调用防火墙规则如iptables, firewalld将该IP封禁一段时间。安装与配置安装fail2ban# Ubuntu/Debian sudo apt update sudo apt install fail2ban -y # CentOS/RHEL sudo yum install epel-release -y sudo yum install fail2ban -y创建本地配置文件避免升级被覆盖sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local配置SSH防护规则编辑/etc/fail2ban/jail.local找到[sshd]段落进行如下修改注意如果你修改了SSH端口配置需相应调整[sshd] enabled true port 35222 # 改为你的SSH端口多个端口用空格隔开如 port ssh,35222 filter sshd logpath /var/log/auth.log # CentOS/RHEL可能是 /var/log/secure maxretry 5 # 最大重试次数 findtime 600 # 在10分钟内 bantime 3600 # 禁止1小时maxretry和findtime定义了触发条件在findtime秒内失败maxretry次则触发。bantime是封禁时长秒。可以设置为-1永久封禁但通常不建议可能误封。启动并设置开机自启sudo systemctl start fail2ban sudo systemctl enable fail2ban检查状态sudo fail2ban-client status sshd # 查看sshd监狱状态 sudo fail2ban-client status # 查看所有监狱状态注意事项确保你的防火墙iptables/firewalld正在运行因为fail2ban通过添加防火墙规则来封禁IP。小心不要把自己锁在外面。在配置和测试阶段最好在本地虚拟机或另一个网络环境如手机热点保留一个测试连接。fail2ban可以防护很多服务如nginx, vsftpd只需启用对应的[jail]即可。4. 深度加固安全模式强制修改root密码这是一个进阶且非常实用的安全措施。它的场景是当你接手一台旧服务器或者怀疑root密码可能已泄露时你可以在服务器本地或通过远程控制台引导系统进入一个特殊的安全模式。在此模式下系统会强制要求你为root账户设置一个新密码然后才能继续正常启动。这确保了即使之前密码被窃取你也能立即重置夺回控制权。实现原理通过修改Linux系统的引导加载器通常是GRUB的内核参数让系统启动时直接运行passwd命令来修改root密码而不是正常的登录流程。操作步骤以GRUB2为例这是目前大多数发行版的默认引导器重启服务器在GRUB菜单出现时快速按下e键进入编辑模式。如果你使用云服务器通常需要通过VNC或云平台提供的“连接管理终端”来操作。找到以linux或linuxefi开头的行。这一行定义了内核启动参数。它可能看起来像这样linux /vmlinuz-5.4.0-xx-generic root/dev/mapper/ubuntu--vg-root ro quiet splash修改内核参数将光标移动到该行末尾。首先删除quiet和splash这类安静启动参数以便能看到启动过程的信息。然后在行末添加init/bin/bash。修改后的行类似linux /vmlinuz-5.4.0-xx-generic root/dev/mapper/ubuntu--vg-root ro init/bin/bash这个参数告诉内核不要启动常规的初始化系统如systemd或init而是直接启动一个bash shell。按CtrlX或F10用这些参数启动系统。系统会很快启动并直接给你一个root权限的bash提示符通常是#此时文件系统可能处于只读状态。重新挂载根文件系统为可读写并修改密码mount -o remount,rw / passwd输入并确认两遍新的root密码。你会看到passwd: password updated successfully的提示。同步数据并重启sync exec /sbin/init # 或者直接 reboot -fsync命令确保所有缓存数据写入磁盘。exec /sbin/init会以正常方式重新启动初始化进程使系统完整启动。之后你就可以用新设置的root密码通过之前配置的普通用户su上来了。严重警告此操作有风险需在物理机或可靠的虚拟化控制台进行。操作错误可能导致系统无法启动。务必在操作前确认你拥有服务器的物理或带外管理如iDRAC, iLO, IPMI访问权限。对于云服务器确保控制台连接可用。5. 综合配置与自动化部署脚本将以上所有配置整合并实现一定程度的自动化是运维效率的关键。下面是一个示例的sshd_config最终配置片段和部署思路。/etc/ssh/sshd_config关键配置汇总# 端口设置 Port 35222 # 禁用root登录 PermitRootLogin no # 启用密钥认证 PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # 禁用密码认证确保密钥登录测试成功后再开启 PasswordAuthentication no # 禁用空密码 PermitEmptyPasswords no # 使用更安全的协议版本 Protocol 2 # 限制认证尝试次数与fail2ban配合 MaxAuthTries 3 # 禁用不安全的认证方法 ChallengeResponseAuthentication no # 启用严格模式检查密钥和目录权限 StrictModes yes # 可选的限制可登录的用户或用户组 # AllowUsers your_username # AllowGroups ssh-users自动化部署脚本思路对于需要批量管理多台服务器的情况可以编写一个Ansible Playbook或Shell脚本。以下是一个简单的Shell脚本框架#!/bin/bash # deploy_ssh_hardening.sh set -e # 遇到错误即退出 SSH_PORT”35222” ADMIN_USER”deployer” SSH_KEY_PUB”$(cat ~/.ssh/id_rsa.pub)” # 1. 备份原配置 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %Y%m%d) # 2. 使用sed或cat修改sshd_config # 这里是一个示例实际应用应更严谨使用模板或ansible的lineinfile模块更好 cat /tmp/new_sshd_config EOF Port $SSH_PORT PermitRootLogin no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no PermitEmptyPasswords no Protocol 2 MaxAuthTries 3 ChallengeResponseAuthentication no UsePAM yes PrintMotd no Subsystem sftp /usr/lib/openssh/sftp-server EOF # 合并原有配置和新配置简化处理生产环境需更精细 mv /tmp/new_sshd_config /etc/ssh/sshd_config # 3. 创建管理员用户并授权sudo useradd -m -s /bin/bash $ADMIN_USER echo “$ADMIN_USER ALL(ALL) NOPASSWD:ALL” /etc/sudoers.d/$ADMIN_USER chmod 440 /etc/sudoers.d/$ADMIN_USER # 4. 部署公钥 mkdir -p /home/$ADMIN_USER/.ssh echo “$SSH_KEY_PUB” /home/$ADMIN_USER/.ssh/authorized_keys chmod 700 /home/$ADMIN_USER/.ssh chmod 600 /home/$ADMIN_USER/.ssh/authorized_keys chown -R $ADMIN_USER:$ADMIN_USER /home/$ADMIN_USER/.ssh # 5. 配置防火墙假设使用firewalld firewall-cmd --permanent --remove-servicessh # 移除默认22端口规则 firewall-cmd --permanent --add-port$SSH_PORT/tcp firewall-cmd --reload # 6. 安装并配置fail2ban yum install -y epel-release fail2ban || apt update apt install -y fail2ban systemctl enable --now fail2ban # 7. 重启SSH服务谨慎最好在另一个会话测试新端口后再执行 echo “配置完成。请在另一个终端使用 ‘ssh -p $SSH_PORT $ADMIN_USER服务器IP’ 测试连接。” echo “测试成功后再回到本终端按回车重启sshd…” read -p “按回车继续重启SSH服务…” systemctl restart sshd echo “SSH安全加固部署完成。”警告此类脚本具有破坏性务必先在测试环境中验证并确保在运行时有备用的登录方式如云控制台。6. 常见问题排查与运维技巧实录即使按照最佳实践操作在实际运维中仍会遇到各种问题。这里记录了几个最典型的“坑”和解决方法。6.1 问题修改SSH端口后无法连接排查思路检查服务状态sudo systemctl status sshd查看服务是否正常运行有无报错。检查端口监听sudo netstat -tlnp | grep sshd或sudo ss -tlnp | grep :35222。确认sshd进程是否在监听你配置的端口。检查防火墙这是最常见的原因。确认防火墙已放行新端口。对于firewalldsudo firewall-cmd --list-all对于ufwsudo ufw status verbose。检查云平台安全组/网络ACL如果你使用的是阿里云、AWS、腾讯云等云服务器必须在云控制台的安全组规则中添加入方向规则允许你的新SSH端口如35222/TCP。检查SELinux在某些系统如CentOS上SELinux可能会阻止SSH绑定非标准端口。可以临时禁用SELinux测试setenforce 0或者为SSH添加非标准端口标签semanage port -a -t ssh_port_t -p tcp 35222。使用telnet或nc测试从客户端使用telnet 服务器IP 35222或nc -zv 服务器IP 35222。如果能连接上看到SSH横幅或连接成功说明网络和端口是通的问题可能在客户端配置或密钥认证上。6.2 问题配置密钥登录后依然要求输入密码排查思路服务器端authorized_keys文件权限确保是600所属用户和家目录权限正确。SSH对此要求非常严格。服务器端sshd_config配置确认PubkeyAuthentication yes且PasswordAuthentication no或yes但你想用密钥。客户端私钥权限本地私钥文件如~/.ssh/id_rsa权限应为600。使用-v参数调试在客户端连接时添加多个-v参数如ssh -vvv -p 35222 userserver_ip。输出会非常详细通常会明确指出认证在哪一步失败例如“Permission denied (publickey)”或“Offering public key”。仔细阅读输出信息。检查密钥类型较新版本的OpenSSH可能默认禁用某些较弱的密钥类型如ssh-rsa。确保你生成的密钥类型是受支持的。使用ssh-keygen -l -f your_key.pub查看密钥指纹和类型。6.3 问题fail2ban不生效IP没有被封禁排查思路检查fail2ban服务状态sudo systemctl status fail2ban。检查监狱状态sudo fail2ban-client status sshd查看“Currently failed”和“Total banned”计数。检查日志路径确认jail.local中[sshd]下的logpath指向了正确的系统认证日志文件。Ubuntu/Debian通常是/var/log/auth.logCentOS/RHEL是/var/log/secure。手动测试过滤器fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf。这个命令会测试日志文件是否匹配fail2ban的过滤规则。检查防火墙后端fail2ban需要调用本地防火墙。检查jail.local中的banaction设置通常是iptables或firewalld并确保对应的防火墙服务正在运行。查看fail2ban日志sudo tail -f /var/log/fail2ban.log。当你尝试用错误密码登录几次后观察日志是否有封禁动作的记录。6.4 运维技巧如何安全地批量更新密钥当团队人员变动或密钥需要轮换时批量更新authorized_keys是个敏感操作。使用版本控制与自动化将服务器的authorized_keys文件内容管理在Git仓库中每个授权密钥作为一行。使用Ansible、SaltStack或Puppet等工具将仓库中的文件分发到所有服务器。这样可以清晰追溯谁在什么时候添加/移除了谁的密钥。使用ssh-copy-id的替代方案对于单次添加ssh-copy-id是最佳选择。对于脚本化操作可以使用以下命令组合PUB_KEY”ssh-rsa AAAAB3NzaC1yc2E... userhost” SSH_PORT”35222” SERVER”userserver_ip” ssh -p $SSH_PORT $SERVER “mkdir -p ~/.ssh echo ‘$PUB_KEY’ ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys”但要注意如果多次执行会导致authorized_keys文件中出现重复行。密钥集中管理工具考虑使用更专业的方案如HashiCorp Vault的SSH秘密引擎或者FreeIPA、Red Hat IdM这类身份管理系统它们能提供动态的、基于时间的SSH证书无需在每台服务器上维护静态的authorized_keys文件安全性更高。6.5 终极安全建议拥抱证书认证CA对于大型或对安全要求极高的环境SSH密钥对管理会变得繁琐。SSH证书认证SSH Certificate Authentication是更优的解决方案。它类似于HTTPS的SSL证书你建立一个内部的SSH证书颁发机构CA。CA为每个用户或主机签署一个短期有效的证书如一天或一周。服务器信任CA的公钥客户端持有由CA签名的证书。认证时服务器验证证书的签名和有效期。优势吊销方便无需到每台服务器删除密钥只需在CA吊销证书即可。自动过期证书短期有效减少了密钥长期泄露的风险。细粒度授权可以在证书中嵌入登录的用户名、允许访问的主机、有效期等元数据。虽然初始设置比密钥对复杂但对于需要管理成百上千台服务器和用户的企业环境证书认证在安全性和可管理性上具有压倒性优势。OpenSSH本身支持证书认证相关命令是ssh-keygen的-s签名和-K生成CA等选项。这套从基础到进阶的SSH安全加固方案几乎能抵御99%的自动化网络攻击。安全是一个过程而不是一个状态。定期审计检查/var/log/auth.log或/var/log/secure、及时更新系统和服务sudo apt update sudo apt upgrade、以及遵循最小权限原则与这些配置同样重要。记住没有绝对的安全但我们可以让攻击者的成本高到无法承受。
)
