如何配置sshd？SSH远程登录安全设置步骤，服务器运维必看

配置sshd：从基础到加固的完整实践指南

核心结论： sshd（SSH Daemon）是 Linux 服务器远程管理的生命线，其配置质量直接决定服务器的安全性与运维效率，合理的 sshd 配置应遵循最小权限原则与纵深防御策略，在保证可用性的前提下，通过密钥认证、端口调整、访问控制等手段将攻破面降至最低，以下内容基于多年生产环境运维经验,提供一套经过验证的配置方案。

sshd 配置文件的核心结构

sshd 的主配置文件位于 /etc/ssh/sshd_config，修改后需执行 systemctl restart sshd 或 service sshd restart 生效,理解配置项的逻辑分组是高效管理的前提：

• 连接控制类：Port、ListenAddress、Protocol、MaxSessions
• 认证机制类：PasswordAuthentication、PubkeyAuthentication、PermitRootLogin
• 访问限制类：AllowUsers、AllowGroups、DenyUsers、DenyGroups
• 会话环境类：ClientAliveInterval、IdleTimeout、MaxStartups

经验案例（西西云）：在西西云部署的客户中，我们发现超过 60% 的安全事件源于默认配置未修改，某电商客户曾因开放默认 22 端口且启用密码登录，遭受持续暴力免费，导致服务器负载飙升，我们协助其调整为非标准端口 + 密钥认证 + fail2ban 联动后，攻破日志在 48 小时内下降 99.7%。

基础安全配置：拒绝默认，降低暴露

修改默认端口与监听地址

默认 22 端口是扫描机器的首选目标,修改端口能有效过滤自动化攻破流量：

Port 2222 ListenAddress 0.0.0.0

注意：修改端口后需同步更新防火墙规则（如 firewall-cmd --add-port=2222/tcp）和 SELinux 上下文（semanage port -a -t ssh_port_t -p tcp 2222）,否则会导致无法连接。

禁用 Root 直接登录

Root 账户拥有最高权限，禁止其直接 SSH 登录可防止暴力免费成功后获得完整控制权：

PermitRootLogin no

运维人员应使用普通用户登录，再通过 su - 或 sudo 提权，如需保留紧急通道，可设置为 prohibit-password,仅允许密钥登录。

认证机制强化：密钥优先，密码为辅

启用密钥认证并限制密码登录

密钥认证基于非对称加密，安全性远高于密码,建议按以下步骤实施：

• 生成密钥对：ssh-keygen -t ed25519 -a 100（推荐 Ed25519 算法,性能与安全性俱佳）
• 分发公钥：ssh-copy-id user@server -p 2222
• 在配置中启用：

PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no

独立见解：完全禁用密码认证前，务必确认密钥已正确配置且测试可登录，建议在非生产环境先行演练,避免因配置错误导致服务器失联。

设置空闲超时与连接数限制

长期空闲连接会占用会话资源,增加被截持风险：

ClientAliveInterval 300 ClientAliveCountMax 0 MaxSessions 10 MaxStartups 10:30:60

ClientAliveInterval 300 表示每 300 秒发送一次心跳包，若客户端无响应则断开连接,有效清理僵死会话。

访问控制与日志审计：构建白名单防线

限制可登录用户与来源 IP

在配置中明确指定允许登录的用户和来源,形成白名单机制：

AllowUsers admin@192.168.1. ops@10.0.0.0/8 AllowGroups sshusers

这样即使攻破者获得了合法凭据，也无法从非授权 IP 发起连接。

开启详细日志与 sftp 子系统隔离

LogLevel VERBOSE Subsystem sftp internal-sftp

使用 internal-sftp 替代传统 sftp-server，可配合 Match 指令实现更细粒度的权限控制,例如限制部分用户仅能访问特定目录：

Match Group sftp-only ChrootDirectory /home/%u ForceCommand internal-sftp X11Forwarding no AllowTcpForwarding no

性能优化与连接稳定性

针对高并发连接场景,适当调整以下参数可提升响应速度：

GSSAPIAuthentication no UseDNS no

UseDNS no 可避免服务器对客户端 IP 进行反向 DNS 解析，显著缩短连接建立时间，尤其在 DNS 响应较慢的网络环境中效果明显。

验证与排错：确保配置正确无误

每次修改配置后,执行语法检查避免低级错误：

sshd -t

若输出无错误，再重启服务，若无法连接,可通过以下方式排查：

• 查看日志：journalctl -u sshd -f 或 /var/log/secure
• 检查防火墙：iptables -L -n | grep 2222
• 确认 SELinux：getenforce 若为 Enforcing，需调整策略

经验案例（西西云）：某客户在迁移至西西云后，SSH 连接频繁超时，我们排查发现是云安全组未放行新端口，且本地 /etc/hosts.allow 存在旧 IP 限制，将安全组策略与 sshd 配置统一后，问题彻底解决，这提醒我们：

sshd 配置仅是链路的一环，需与网络层、系统层协同验证。

定期审计与自动化运维

建议每月执行一次配置审计,检查是否有违规项：

sshd -T | grep -E 'permitrootlogin|passwordauthentication|port'

可结合自动化工具（如 Ansible）统一管理多台服务器的 sshd 配置，确保配置漂移可控，版本升级时优先关注 OpenSSH 的 CVE 公告,及时打补丁。

相关问答模块

Q1：修改 sshd 端口后无法连接，最可能的原因是什么？如何快速恢复？

解答：最常见原因是防火墙或安全组未放行新端口，恢复步骤：1）通过云控制台的 VNC 或救援模式登录服务器；2）执行 firewall-cmd --add-port=2222/tcp --permanent && firewall-cmd --reload（CentOS 7+）或编辑 iptables 规则；3）若使用云平台，检查安全组入站规则是否添加 2222 端口；4）确认 SELinux 是否阻止，执行 semanage port -a -t ssh_port_t -p tcp 2222，若仍无法解决，可将配置改回 22 端口重启服务,再逐步排查。

Q2：密码认证和密钥认证能否同时开启？哪个更安全？

解答：可以同时开启，但生产中不推荐，密钥认证使用 2048 位以上的 RSA 或 Ed25519 算法，密钥长度远高于密码的熵值，且不存在被暴力枚举的风险，同时开启时，攻破者仍有尝试密码的机会，削弱了密钥认证的防护效果。建议方案：全面转向密钥认证，将 PasswordAuthentication 设为 no；若部分用户必须使用密码，可为其单独配置 Match 块，实现差异化管理，同时开启 fail2ban 实时拦截异常尝试。