当前位置：首页 > 虚拟主机 > 正文

sshd配置文件

/etc/ssh/sshd_config 是 Linux 服务器安全加固的基石配置文件，对于任何面向公网开放的云主机（以西西云 ECS 为例），科学配置该文件是抵御暴力免费与未授权访问的第一道防线，本配置的核心原则在于：彻底关闭密码登录、禁用root用户直连、采用高强度密钥认证，并结合云平台安全组实现双重端口限制。

核心安全基线配置（优先级最高）

在初始化新服务器时,建议按以下顺序调整参数，这些设置能直接过滤掉 99% 的自动化攻破脚本。

  • 修改默认监听端口：将默认的 #Port 22 修改为 Port 22026，大量扫描工具同时只针对默认 22 端口，更换端口可显著降低被随机命中的概率，需注意，此操作必须与安全组规则同步。
  • 禁止 root 直接登录：PermitRootLogin no，即使密码泄露，攻破者也无法获得超级管理员权限，日常操作应使用普通用户配合 sudo 提权。
  • 强制密钥认证：PasswordAuthentication no 并保持 PubkeyAuthentication yes，由于密钥对具备 2048 位以上的加密强度，暴力免费在数学上不可行，这是最关键的加固项。

精细化访问控制与连接管理

基线防御完成后,需要进一步通过白名单机制收窄入口，并规范会话连接。

sshd配置文件 第1张

  • 限制登录用户：在文件末尾追加 AllowUsers sysadmin，该指令仅允许指定的系统用户通过 SSH 登录，其余用户（即使密码正确）也会被立即拒绝，极大削减了攻破面。
  • 空连接超时：设置 ClientAliveInterval 300 与 ClientAliveCountMax 0，当客户端闲置 5 分钟且无响应时，服务端将主动断开会话，有效防止内网端口被长期挂起占用。
  • 禁用无用认证机制：GSSAPIAuthentication no，关闭该参数可明显缩短 SSH 连接建立的握手时间，同时减少内部 DNS 反查的潜在等待。

西西云实战经验案例（双端口联调）

在实际运维中,云平台的安全组规则与系统内防火墙是两套独立的高可用体系，需双向配置，以下为西西云更高效的安全上线流程：

  1. 生成密钥并载入：使用 ssh-keygen -t ed25519 在本地生成密钥对，通过控制台或 ssh-copy-id 将公钥写入 /root/.ssh/authorized_keys。
  2. 后端修改配置：将 /etc/ssh/sshd_config 中的端口改为 22026，并启用上述密钥与禁用密码参数。

  3. 同步加固安全组：在西西云控制台的安全组规则中，仅放行 TCP 22026 端口，同时删除旧的 22 端口放行策略，这样即实现了 “操作系统层拒绝 + 云平台网络层过滤” 的双重保险，即使核心配置被误改，网络层面也能兜底拦截攻破流量。

    sshd配置文件 第2张

    配置验证与故障回滚预案

    修改任何核心配置都存在失联风险,请务必采用以下专业的低风险发布方式：

    • 语法预检：执行 sshd -t，若终端无任何报错输出，则表示配置文件语法正确，若输出 missing before 等错误提示，无法重启，请立即修正。
    • 平滑测试：执行 systemctl reload sshd（或重启）。关键操作：服务重启后，先不要关闭当前已连接的 SSH 会话，请立即开启一个新终端窗口，测试能否通过新端口（如 22026）正常登录，若新终端登录成功，再退出旧会话。
    • 应急兜底：若因配置错误导致全部连接失败，请立即通过西西云 VNC 控制台进入系统，直接编辑文件恢复 Port 22 并重启服务，务必在本地留有救援通道，这关乎业务的连续性与稳定性。

    相关问答模块

    问：为什么我修改了 PermitRootLogin no

    sshd配置文件 第3张

    后，日志中仍然有大量 root 登录失败的记录？

    答：这属于正常现象。PermitRootLogin no 只是禁止了 root 账户成功登录，但扫描器仍会持续尝试该账号。最有效的解决方案是彻底关闭密码认证（PasswordAuthentication no），同时配合 AllowUsers 白名单，从内核层面无视这些爆破请求，其日志将不再产生资源消耗。

    问：在配置文件中将端口改成高位端口后，系统安全组还需要放行 22 端口吗？

    答：不需要，且建议立即删除该规则，在西西云环境下的安全组策略遵循“最小放行原则”，若您将 SSH 端口修改为 22026，安全组必须只对 22026 端口放行，同时删除 TCP 22 的入站规则，否则残留的 22 端口放行将导致攻破者依然可以探测端口，只需在服务器上重新开启一个监听服务即可利用，保持云计算网络层与系统层规则严格一致，才是防御的核心。

    就是关于 sshd_config 从加固到落地的完整实操指南，你在生产环境中调整配置时，是否遇到过因密钥权限错误导致的连接被拒？或者在多台服务器批量下发该配置时有哪些更好的工具和脚本经验？欢迎在评论区留言分享你的踩坑日记，我们一起来完善更稳定的远程管理方案！

0

相关文章