GXCOM 安全 SSH 安全最佳实践:如何保护您的 Linux 服务器
Cherry Servers 独立服务器、VPS、GPU 服务器和裸机基础设施

SSH 安全最佳实践:如何保护您的 Linux 服务器

SSH 是 Linux 服务器上最重要的管理接口之一——也是服务器获得公共 IP 地址后,攻击者可能首先尝试探测的服务之一。.

弱密码、暴露的root账户、被盗的私钥或配置不当的SSH服务,都可能让攻击者直接入侵您的VPS或独立服务器。.

好消息是,SSH 的安全性可以得到显著增强,同时又不会让日常服务器管理变得不必要地复杂。.

本指南涵盖了最重要的 SSH 安全最佳实践 用于保护 Linux 服务器,包括 SSH 密钥、root 权限、密码、防火墙、身份验证控制和监控。.

关键 → 限制 → 限制 → 监控 → 恢复

保护 Linux 服务器的 SSH 安全最佳实践

为什么 SSH 安全至关重要

安全外壳协议(Secure Shell,简称 SSH)可提供对 Linux 系统的加密远程访问。.

管理员通常将其用于:

  • 管理VPS服务器
  • 安装软件
  • 编辑配置文件
  • 传输文件
  • 重新启动服务
  • 管理数据库和应用程序
  • 执行系统维护

由于SSH能够提供强大的管理权限,因此SSH账户一旦遭到入侵,可能会造成严重后果。.

因此,一个安全的Linux服务器仅靠加密是不够的。.

加密连接 ≠ 安全认证。.

如果您正在对新的VPS进行安全加固,请从我们的 VPS 安全指南 有关更全面的服务器安全检查清单。.

SSH 安全检查清单

安全控制 目的 优先级
SSH 密钥 强认证 关键
非root用户 减少直接特权访问 关键
限制 root 登录 保护root账户 关键
限制密码登录 减少密码攻击 高
防火墙 限制网络暴露 关键
Fail2ban / 速率控制 减少重复登录尝试 高
监测 检测可疑访问 高
恢复访问 防止永久锁定 关键

1. 保持 OpenSSH 和 Linux 系统最新

SSH 安全加固要从现有软件入手。.

在 Ubuntu 或 Debian 上:

sudo apt update
sudo apt upgrade -y

更新可能包含针对 OpenSSH、系统库、内核及其他组件的安全修复程序。.

不要花几个小时去调整身份验证设置,却放任已知的漏洞得不到修复。.

系统加固 + 无更新 = 安全措施不完善。.

2. 创建一个非root管理员用户

请避免将 root 作为您的常规 SSH 账户。.

在 Ubuntu/Debian 上,创建一个用户:

sudo adduser adminuser

然后在适当的时候授予 sudo 权限:

sudo usermod -aG sudo adminuser

测试该账户:

ssh adminuser@SERVER_IP

并验证 sudo 访问权限:

sudo whoami

您应该看到:

root

这提供了管理功能,同时无需进行常规的直接root登录。.

3. 使用 SSH 密钥认证

SSH 密钥是您在远程服务器身份验证方面可以采取的最重要改进措施之一。.

在本地计算机上生成一个 Ed25519 密钥:

ssh-keygen -t ed25519

您可以使用一个强密码短语来保护私钥,从而增加一层安全保障。.

使用适当的方法将公钥复制到服务器上,例如:

ssh-copy-id adminuser@SERVER_IP

然后,在更改任何现有身份验证方法之前,请在新的终端中测试连接。.

公钥 → 服务器
私钥 → 请妥善保管

切勿上传、通过电子邮件发送或公开分享您的私钥。.

4. 保护您的私有 SSH 密钥

SSH 密钥认证的安全性完全取决于私钥的安全性。.

良好做法包括:

  • 请仅将私钥保存在可信设备上
  • 使用适当的本地文件权限
  • 使用密码短语保护重要密钥
  • 不要在不考虑风险的情况下,将同一组管理密钥用于所有场景
  • 删除不再需要的键
  • 如果怀疑密钥已泄露,请更换密钥

对于团队而言,应避免让多名管理员随意共用一个私钥。.

个人凭证有助于加强问责制,并在用户不再需要时更方便地撤销其访问权限。.

5. 限制直接通过 SSH 以 root 用户身份登录

一旦非root管理员账户运行正常,请考虑禁用通过SSH直接登录root账户的功能。.

OpenSSH 服务器配置通常位于:

/etc/ssh/sshd_config

此外,还可使用以下路径下的文件:

/etc/ssh/sshd_config.d/

一种常见的设置是:

PermitRootLogin no

使用前,请确认:

  • 您的管理员用户正在工作
  • SSH密钥认证正常工作
  • Sudo 有效
  • 您拥有服务提供商控制台或恢复访问权限

在测试替换件之前,切勿移除当前的访问权限。.

6. 在适当的情况下禁用 SSH 密码认证

在对基于密钥的身份验证进行全面测试后,管理员可以选择禁用 SSH 密码身份验证。.

一种典型的配置是:

PasswordAuthentication no

在重新加载 SSH 之前,请验证配置:

sudo sshd -t

如果该命令报告了配置错误,请在重新加载服务之前先进行修复。.

在测试第二个连接时,请保持现有的 SSH 会话保持打开状态。.

这个简单的操作流程可以防止意外导致服务器被锁定。.

7. 为 SSH 配置防火墙

不要公开那些不需要公开访问的服务。.

在运行 Ubuntu 并使用 UFW 的系统上,您可以通过以下命令查看当前规则:

sudo ufw status verbose

如果 SSH 必须保持对公众开放,请在启用或收紧防火墙之前,确保已存在相应的 SSH 规则。.

在可行的情况下,可将管理用途的 SSH 访问权限限制在可信的源网络或地址范围内。.

然而,静态 IP 限制并不适合所有人,特别是那些经常从不同网络连接的管理员。.

防火墙策略应与您的实际访问模式相匹配。.

8. 是否应该更改默认的 SSH 端口?

将SSH端口从22号端口更改为其他端口,通常被推荐作为一项安全措施。.

它可以减少针对默认端口的自动扫描产生的干扰,但不应将其视为主要的安全控制措施。.

攻击者仍然可以发现运行在其他端口上的 SSH 服务。.

不妨将非标准端口理解为:

更少的“噪音” ≠ 强认证。.

SSH密钥、账户限制、防火墙和监控的重要性要大得多。.

9. 限制哪些用户可以访问 SSH

如果只有特定账户需要远程 SSH 访问,请据此限制访问权限。.

OpenSSH 支持以下指令:

AllowUsers adminuser

或基于组的控件,例如:

AllowGroups sshusers

这些控制措施可减少能够尝试远程身份验证的账户数量。.

在应用这些设置之前,请确认已包含所需的系统管理员账户。.

10. 防范重复登录尝试

面向互联网的 SSH 服务器通常会收到自动登录尝试。.

Fail2ban 可以监控身份验证日志,并暂时封禁那些反复触发已配置失败规则的来源。.

在 Ubuntu/Debian 上:

sudo apt install fail2ban -y

检查该服务:

sudo systemctl status fail2ban

应将Fail2ban视为一道额外的防御层。.

它不能替代:

  • SSH密钥
  • 保护用户账户安全
  • 防火墙控制
  • 软件更新
  • 监测

一种安全工具 ≠ 完整的 SSH 安全。.

11. 检查 SSH 身份验证设置

在未弄清楚每个设置的作用之前,请勿直接从互联网上复制一个庞大的“终极 sshd_config”文件。.

相反,请检查那些直接影响您的身份验证模型的设置。.

根据您的环境不同,这些可能包括:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

正确的配置取决于您的 Linux 发行版、OpenSSH 版本以及身份验证要求。.

另外请记住,配置片段可能会覆盖主配置中的设置 sshd_config 文件。.

在认为某项更改已生效之前,请务必验证实际配置。.

12. 减少空闲和废弃的 SSH 会话

长期存在的无人看管的管理会话会增加不必要的风险。.

OpenSSH 提供了有助于检测处于非活动状态或已断开连接的客户端的控制功能。.

具体数值应根据您的服务器管理方式来确定。过短的超时时间可能会中断正常的维护任务。.

其目的并非要不断断开管理员的连接,而是为了避免让被遗忘的特权会话无限期保持打开状态。.

13. 监控 SSH 登录活动

SSH 安全措施不会在配置完成后就结束。.

监控成功的和失败的身份验证活动。.

有用的工具和日志因 Linux 发行版而异,但可能包括:

journalctl -u ssh

或位于以下位置的身份验证日志:

/var/log/

您还可以通过以下方式查看最近的登录记录:

最后

请查找:

  • 意外成功的登录
  • 多次身份验证失败
  • 未知用户名
  • 出乎意料的登录时间
  • 意外的源地址
  • 新的管理员账户

安全访问 + 无监控 = 盲点。.

14. 删除旧的 SSH 密钥和账户

访问量往往会随着时间的推移而逐渐积累。.

某位开发人员、承包商或旧笔记本电脑可能已不再需要访问权限,但其凭据仍会无限期保持有效。.

定期审查:

  • 用户账户
  • Sudo 权限
  • 授权的 SSH 密钥
  • 服务账户
  • 自动化资质

撤销不再需要的访问权限。.

旧版 Access 依然是 Access。.

15. 维护应急控制台和恢复访问权限

在强化SSH安全性时,最大的风险之一就是把自己锁在服务器外面。.

在进行重大的身份验证或防火墙配置更改之前,请先了解您的 VPS 服务商提供的恢复工具。.

根据服务提供商的不同,这些可能包括:

  • Web控制台
  • VNC 控制台
  • 串行控制台
  • 救援环境
  • 恢复模式
  • 快照

在禁用 root 权限或密码认证之前,这一点尤为重要。.

一种会阻止合法管理员访问服务器的严格安全配置,仍然属于运行故障。.

推荐的 SSH 安全加固工作流

更改的顺序很重要。.

更安全的工作流程是:

1. 更新服务器
安装最新的安全更新。.

↓

2. 创建管理员用户
配置适当的 sudo 访问权限。.

↓

3. 添加 SSH 密钥
测试密钥认证。.

↓

4. 第二届会议开幕
确认新登录方式是否有效。.

↓

5. 配置防火墙
请确保 SSH 始终可访问。.

↓

6. 限制 root / 密码登录
只有在替换方法生效之后。.

↓

7. 验证 SSH 配置
使用 sshd -t.

↓

8. 监控
监控认证活动。.

先测试 → 后限制。.

SSH密钥与密码的对比

功能 SSH 密钥 密码
抵制猜测 非常强 取决于密码
自动化 非常棒 不太合适
凭证盗用风险 私钥必须妥善保管 密码必须受到保护
撤销 删除授权密钥 更改/禁用账户密码
推荐给服务器管理员 通常是 根据安全模型使用

SSH 密钥并非魔法。如果未受保护的私钥被盗,攻击者可能会利用它。.

这就是为什么终端安全和私钥保护依然至关重要。.

SSH 安全与 DDoS 防护是不同的

SSH 安全强化措施可保护管理访问权限。.

DDoS防护主要侧重于服务可用性和恶意流量。.

一台服务器即使拥有出色的SSH安全防护,仍可能面临大规模网络攻击的威胁。.

同样,即使位于强大的DDoS防御系统之后,如果VPS的管理凭据不够安全,它仍然可能遭到入侵。.

关于网络层的防护,请阅读我们的 DDoS防护指南.

这两种策略相辅相成:

DDoS 防护 → 保障可用性
SSH 安全 → 保护管理员访问权限

SSH 安全中的常见错误

凡事都使用Root权限

请使用专用管理员账户,并在适当情况下使用 sudo 命令。.

在测试 SSH 密钥之前禁用密码登录

这是把自己锁在门外最简单的方法之一。.

使用不同的端口能让SSH更安全

更改端口可能会减少自动化攻击产生的噪音,但不能替代安全认证。.

与所有人共享一个私钥

个人凭证能更好地落实责任,且撤销起来更方便。.

永久保留旧密钥的授权

审查并删除不再需要的凭据。.

在不进行监控的情况下将SSH对外开放

应加强对公共行政服务中可疑身份验证活动的监控。.

一次性进行多项 SSH 更改

每次只更改一层安全措施,并在每个主要步骤之后测试访问情况。.

如果 SSH 突然变慢了怎么办?

SSH 速度变慢并不一定意味着受到了攻击。.

可能的原因包括:

  • CPU 负载过高
  • 内存压力
  • 磁盘 I/O 瓶颈
  • 网络延迟
  • 数据包丢失
  • DNS 或身份验证延迟

如果整个服务器运行缓慢,请使用我们的 服务器运行缓慢故障排除指南 以检查 CPU、内存、磁盘和网络方面的瓶颈。.

SSH 安全常见问题解答

SSH 默认情况下是安全的吗?

SSH 提供了加密通信,但整体安全性取决于身份验证、用户账户、软件更新、防火墙配置、私钥保护以及监控。.

我应该禁用 root 的 SSH 登录吗?

限制直接通过SSH以root身份登录是一种常见的系统加固措施。首先,创建并测试另一个具有有效sudo权限和恢复访问权限的管理员账户。.

我应该禁用 SSH 密码吗?

如果 SSH 密钥认证已正确配置并经过测试,禁用密码认证可以减少密码猜测攻击。请务必先确保拥有可靠的密钥和恢复访问途径。.

我应该更改 SSH 端口 22 吗?

更改端口可以减少自动扫描产生的干扰,但不应将其视为主要的安全措施。强身份验证和访问控制更为重要。.

SSH密钥完全安全吗?

没有任何一种身份验证方法是完全没有风险的。SSH密钥虽然能提供强身份验证,但必须保护私钥不被盗取,并在授权失效时将其删除。.

Fail2ban 能保障 SSH 的安全吗?

Fail2ban 有助于减少重复的身份验证尝试,但这仅是一层防护。应将其与 SSH 密钥、防火墙规则、系统更新及监控措施结合使用。.

我可以将SSH访问限制为一个IP地址吗?

是的,前提是您的防火墙和网络配置支持此功能。如果您拥有一个可靠的可信源IP地址,这可以显著降低安全风险,但对于使用动态网络的管理员来说,可能会带来不便。.

SSH 安全最佳实践检查清单

  • ✓ 保持 Linux 和 OpenSSH 处于最新状态
  • ✓ 创建一个非root的管理用户
  • ✓ 使用 SSH 密钥认证
  • ✓ 保护私有 SSH 密钥
  • ✓ 限制直接通过 SSH 以 root 身份登录
  • ✓ 检查密码认证
  • ✓ 配置防火墙规则
  • ✓ 不要仅依赖更改 SSH 端口
  • ✓ 限制授权的 SSH 用户
  • ✓ 防范重复登录尝试
  • ✓ 检查身份验证设置
  • ✓ 妥善管理空闲会话
  • ✓ 监控登录活动
  • ✓ 删除旧账户和密钥
  • ✓ 保持紧急恢复访问权限

最终建议

最有效的 SSH 安全最佳实践 并不是晦涩难懂的配置技巧。.

先从一个简单的分层策略开始:

更新
请及时为 Linux 和 OpenSSH 安装补丁。.

↓

关键词
请使用强SSH密钥认证。.

↓

RESTRICT
降低 root、用户和网络的风险。.

↓

LIMIT
控制重复的身份验证尝试。.

↓

MONITOR
注意谁正在尝试访问该服务器。.

↓

恢复
在收紧 SSH 安全措施之前,请确保保留控制台或紧急恢复访问权限。.

最重要的是:

在撤销访问权限之前,请先测试访问权限。.

SSH 安全是分层实现的。.

© GXCOM.NET。本网站上的所有内容均代表我们团队的独立研究、编辑分析及原创见解。任何转载、引用或再发布均须注明原始来源,并附上原文链接。.https://www.gxcom.net/zh/ssh-%e5%ae%89%e5%85%a8%e6%9c%80%e4%bd%b3%e5%ae%9e%e8%b7%b5/
InterServer 网站托管和 VPS hostwinds
下一篇
保护 Linux 服务器的 SSH 安全最佳实践

没有更多帖子了

订阅
通知
访客
0 评论
最旧的
最新 得票最多
返回顶部
0
很想听听大家的看法,请留言。.x