1.6. 使 OpenSSH 更安全


在使用 OpenSSH 时,您可以调整系统以提高安全性。

请注意,/etc/ssh/sshd_config OpenSSH 服务器配置文件中的更改需要重新载入 sshd 守护进程才能生效:

# systemctl reload sshd
警告

大多数安全强化配置更改会降低与不支持最新算法或密码套件的客户端的兼容性。

禁用不安全的连接协议
要使 SSH 生效,防止使用由 OpenSSH 套件替代的不安全连接协议。否则,用户的密码可能只会在一个会话中被 SSH 保护,可能会在以后使用 Telnet 登录时被捕获。
禁用基于密码的身份验证
禁用用于身份验证的密码,并只允许密钥对减少攻击面。如需更多信息,请参阅将基于密钥的身份验证设置为 OpenSSH 服务器的唯一方法 部分。
更强大的密钥类型

虽然 ssh-keygen 命令默认生成一组 RSA 密钥,但您可以使用 -t 选项指示它生成 Elliptic Curve Digital Signature Algorithm (ECDSA)或 Edwards-Curve 25519 (Ed25519)密钥。ECDSA 在等同的对称密钥强度下提供比 RSA 更好的性能。它还会生成较短的密钥。Ed25519 公钥算法是 一种变形的 Edwards 曲线的实现,其比 RSA、DSA 和 ECDSA 更安全,也更快。

如果没有这些密钥,OpenSSH 会自动创建 RSA、ECDSA 和 Ed25519 服务器主机密钥。要在 RHEL 中配置主机密钥创建,请使用 sshd-keygen@.service 实例化服务。例如,禁用自动创建 RSA 密钥类型:

# systemctl mask sshd-keygen@rsa.service
# rm -f /etc/ssh/ssh_host_rsa_key*
# systemctl restart sshd
注意

在启用了 cloud-init 方法的镜像中,ssh-keygen 单元会自动禁用。这是因为 ssh-keygen template 服务可能会干扰 cloud-init 工具,并导致主机密钥生成问题。要防止这些问题,etc/systemd/system/sshd-keygen@.service.d/disable-sshd-keygen-if-cloud-init-active.conf 置入配置文件禁用了 ssh-keygen 单元(如果 cloud-init 正在运行)。

要只允许 SSH 连接的特定密钥类型,请在 /etc/ssh/sshd_config 中相关行的开头删除注释,并重新载入 sshd 服务。例如,要只允许 Ed25519 主机密钥,相应的行必须如下:

# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
重要

Ed25519 算法与 FIPS-140 不兼容,OpenSSH 在 FIPS 模式下无法与 Ed25519 密钥一起工作。

非默认端口

默认情况下,sshd 守护进程侦听 TCP 端口 22。更改端口可降低系统因默认端口中自动网络扫描而受到攻击的风险,从而提高了安全性。您可以使用 /etc/ssh/sshd_config 配置文件中的 Port 指令指定端口。

您还必须更新默认 SELinux 策略以允许使用非默认端口。要做到这一点,使用 policycoreutils-python-utils 软件包中的 semanage 工具:

# semanage port -a -t ssh_port_t -p tcp <port-number>

另外,更新 firewalld 配置:

# firewall-cmd --add-port <port-number>/tcp
# firewall-cmd --remove-port=22/tcp
# firewall-cmd --runtime-to-permanent

在前面的命令中,将 &lt ;port-number > 替换为使用 Port 指令指定的新端口号。

root 登录

默认情况下,PermitRootLogin 设置为 prohibit-password。这强制使用基于密钥的身份验证,而不是使用密码以 root 身份登录,并通过防止暴力攻击来降低风险。

警告

以 root 用户身份登录并不是一个安全的做法,因为管理员无法审核运行哪个特权命令。要使用管理命令,请登录并使用 sudo

使用 X 安全性扩展

Red Hat Enterprise Linux 客户端中的 X 服务器不提供 X 安全性扩展。因此,当连接到带有 X11 转发的不可信 SSH 服务器时,客户端无法请求另一个安全层。大多数应用程序都无法在启用此扩展时运行。

默认情况下,/etc/ssh/ssh_config.d/50-redhat.conf 文件中的 ForwardX11Trusted 选项被设置为 yesssh -X remote_machine(不信任的主机)和 ssh -Y remote_machine (信任的主机)命令之间没有区别。

如果您的场景根本不需要 X11 转发功能,请将 /etc/ssh/sshd_config 配置文件中的 X11Forwarding 指令设置为 no

限制对特定用户、组或 IP 范围的 SSH 访问

/etc/ssh/sshd_config 配置文件服务器中的 AllowUsersAllowGroups 指令可让您只允许某些用户、域或组连接到您的 OpenSSH 服务器。您可以组合 AllowUsersAllow Groups 来更准确地限制访问,例如:

AllowUsers *@192.168.1.* *@10.0.0.* !*@192.168.1.2
AllowGroups example-group

只有在以下所有条件都满足时,此配置只允许连接:

  • 连接的源 IP 位于 192.168.1.0/24 或 10.0.0.0/24 子网中。
  • 源 IP 不是 192.168.1.2。
  • 用户是 example-group 组的成员。

OpenSSH 服务器仅允许 /etc/ssh/sshd_config 中通过所有 Allow 和 Deny 指令的连接。例如,如果 AllowUsers 指令列出的用户不是 AllowGroups 指令中列出的组的一部分,则用户无法登录。

请注意,使用允许列表(以 Allow 开头的指令)比使用阻止列表(以 Deny 开始的选项)更安全,因为允许列表也会阻止新的未授权的用户或组。

更改系统范围的加密策略

OpenSSH 使用 RHEL 系统范围的加密策略,默认的系统范围的加密策略级别为当前威胁模型提供了安全设置。要使您的加密设置更严格,请更改当前的策略级别:

# update-crypto-policies --set FUTURE
Setting system policy to FUTURE
警告

如果您的系统与旧系统通信,您可能会遇到互操作性问题,因为 FUTURE 策略严格设置。

您还可以通过系统范围的加密策略只为 SSH 协议禁用特定的密码。如需更多信息,请参阅 安全强化文档中的 使用子策略自定义系统范围的加密策略 部分。

选择不使用系统范围的加密策略

要为您的 OpenSSH 服务器选择不使用系统范围的加密策略,请在位于 /etc/ssh/sshd_config.d/ 目录中的置入配置文件中指定前缀为小于 50 的两位数的加密策略,以便它在字典中位于 50-redhat.conf 文件之前,并具有 .conf 后缀,例如 49-crypto-policy-override.conf

详情请查看 sshd_config(5) 手册页。

要为您的 OpenSSH 客户端选择不使用系统范围的加密策略,请执行以下任务之一:

  • 对于给定的用户,使用 ~/.ssh/config 文件中特定于用户的配置覆盖全局 ssh_config
  • 对于整个系统,在 /etc/ssh/ssh_config.d/ 目录中的置入配置文件中指定前缀为小于 50 的两位数的加密策略,以便它在字典中位于 50-redhat.conf 文件之前,并具有 .conf 后缀,例如 49-crypto-policy-override.conf

其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.