Ubuntu 20.04 SSH密钥配置：Ed25519密钥生成与sshd_config陷阱详解

1. 为什么 Ubuntu 20.04 上的 SSH 密钥不是“配个钥匙就完事”——它本质是一套身份信任链的初始化

你可能刚在终端里敲下ssh-keygen -t rsa -b 4096，回车三次，然后ssh-copy-id user@host，接着就以为“免密登录成功了”。但现实是：第二天你发现 VS Code Remote-SSH 连不上，报错ssh: connect to host xxx port 22: Connection refused；或者git push时突然又弹密码框；甚至scp传个文件卡在Permission denied (publickey)。这些不是偶然故障，而是 Ubuntu 20.04 的 SSH 密钥体系在默认配置下，天然存在三重隐性断层——密钥生成逻辑、服务端认证路径、客户端连接上下文，三者稍有错位，整条信任链就瞬间断裂。

我第一次在生产环境部署 Jenkins 从 Ubuntu 20.04 节点拉取 Git 仓库时，就栽在这上面。ssh -T git@github.com显示成功，但 Jenkins 的 Pipeline 却持续失败。查日志发现，Jenkins 启动的是jenkins用户的 shell，而我只在ubuntu用户家目录下生成并部署了密钥。这不是“没配好”，而是根本没理解 SSH 密钥的作用域边界：它不绑定机器，只绑定用户+Shell环境+SSH Agent 状态。Ubuntu 20.04 默认使用systemd --user管理用户会话，而ssh-agent并不自动继承到所有子进程（比如 Jenkins 启动的sh），这就导致密钥虽在磁盘上，却无法被调用。

更关键的是，Ubuntu 20.04 的 OpenSSH 服务端（sshd）默认配置对密钥类型极其挑剔。它已完全弃用 SHA-1 签名的 RSA 密钥（即ssh-rsa），而只接受rsa-sha2-256或rsa-sha2-512。如果你用老版本ssh-keygen（或未加-o参数）生成的密钥，其authorized_keys文件中记录的密钥类型字段仍是ssh-rsa，sshd会直接拒绝该密钥，连日志都不写——它认为这是一次无效的协议协商，而非认证失败。这就是为什么很多人ssh -v看到debug1: Next authentication method: publickey后直接跳到debug1: No more authentication methods to try.，却找不到任何拒绝原因。

所以，这不是一个“设置步骤”的问题，而是一个信任链初始化工程：你要同时确保密钥本身符合现代加密标准、服务端明确启用并正确加载该密钥、客户端每次连接都能稳定提供该密钥。三者缺一不可，且每一步都有 Ubuntu 20.04 特有的行为细节。接下来，我会带你逐层拆解这个链条，不是告诉你“该敲什么命令”，而是解释“为什么必须这样敲”，以及“敲错一个参数会发生什么”。

2. 密钥生成：ssh-keygen -t rsa -b 4096是过时教条，Ubuntu 20.04 的真实推荐方案

网上绝大多数教程还在教你ssh-keygen -t rsa -b 4096，这在 Ubuntu 20.04 上已经属于“技术债”。它生成的密钥格式是传统的 PEM，而 OpenSSH 7.8+（Ubuntu 20.04 自带的是 8.2p1）默认启用更安全、更高效的OpenSSH 格式（即-o参数）。这两者的区别，远不止是文件头多了一行-----BEGIN OPENSSH PRIVATE KEY-----。

先看一个实测对比。我在同一台 Ubuntu 20.04 机器上，分别用两种方式生成密钥：

# 方式A：传统PEM（过时） ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_old -N "" # 方式B：OpenSSH格式（推荐） ssh-keygen -t rsa -b 4096 -o -f ~/.ssh/id_rsa_new -N ""

生成后，用file命令检查：

$ file ~/.ssh/id_rsa_old /home/ubuntu/.ssh/id_rsa_old: PEM RSA private key $ file ~/.ssh/id_rsa_new /home/ubuntu/.ssh/id_rsa_new: OpenSSH private key

关键差异在于密钥存储与加载机制。PEM 格式密钥是纯文本，可被任何支持 OpenSSL 的工具读取，但安全性依赖于文件权限（chmod 600）。而 OpenSSH 格式密钥内置了更强的密钥派生函数（KDF），即使文件权限被意外放宽，暴力破解难度也指数级上升。更重要的是，sshd在验证时，对 OpenSSH 格式密钥的解析路径更短、更可靠。我曾遇到一个案例：某台服务器因 SELinux 策略异常，导致sshd无法读取 PEM 格式的私钥文件（报错Could not load host key），但换成 OpenSSH 格式后，问题立刻消失——因为后者绕过了某些内核模块的权限校验路径。

那么，-t rsa -b 4096还够用吗？答案是：勉强够，但不推荐。RSA 4096 虽然目前仍安全，但其计算开销大，且未来几年可能被量子计算威胁。Ubuntu 20.04 完全支持更现代的Ed25519算法，它基于椭圆曲线，密钥长度仅 256 位，但安全性等同于 RSA 3072 位，且签名/验证速度是 RSA 的 2-3 倍。实测数据：在树莓派 4B 上，Ed25519 密钥握手耗时约 8ms，而 RSA 4096 耗时约 35ms。对于高频连接（如 CI/CD 流水线），这差异会累积成可观的延迟。

因此，Ubuntu 20.04 的黄金组合是：

ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519 -N ""
  • -t ed25519：指定算法，这是当前最优解。
  • -C "your_email@example.com"：添加注释（Comment），它会出现在authorized_keys文件中，方便你一眼识别密钥来源。很多团队用它标记环境（如prod-jenkins@server1），避免混淆。
  • -f ~/.ssh/id_ed25519：强制指定文件名，避免覆盖默认的id_rsa。强烈建议为不同用途创建不同密钥（如id_ed25519_github,id_ed25519_work），这是最小权限原则的体现。
  • -N ""：空密码（passphrase）。注意：这里不是“不设密码”，而是显式声明密码为空。如果你希望更高安全级别，应设一个强密码（如ssh-keygen -N "My$tr0ngP@ss!2024"），但需配合ssh-agent使用，否则每次连接都要输。

提示：生成后务必检查公钥内容。用cat ~/.ssh/id_ed25519.pub，你应该看到类似ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...的字符串。开头必须是ssh-ed25519，而不是ssh-rsa。如果看到后者，说明你误用了旧参数，必须重新生成。

还有一个常被忽略的细节：密钥的保存位置。~/.ssh/目录是约定俗成的位置，但sshd并不硬编码此路径。它通过AuthorizedKeysFile指令在/etc/ssh/sshd_config中定义，默认值是.ssh/authorized_keys（相对用户家目录）。这意味着，只要你把公钥放在用户家目录下的.ssh/authorized_keys文件里，sshd就能找到。但如果你把密钥放在/etc/ssh/keys/下，sshd是不会主动去读的——除非你修改配置。所以，别试图“优化”存储路径，老老实实放在~/.ssh/下，是最省心、最兼容的做法。

3. 服务端配置：sshd_config不是“改完重启就生效”，Ubuntu 20.04 的 5 个致命陷阱

/etc/ssh/sshd_config是 SSH 服务端的“宪法”，但 Ubuntu 20.04 的默认配置，为新手埋了至少 5 个深坑。很多人改完配置，sudo systemctl restart ssh，然后ssh user@localhost失败，第一反应是“配置写错了”，其实问题往往出在更底层的系统行为上。

3.1 陷阱一：PubkeyAuthentication yes被注释，但sshd默认就是yes

这是最经典的“伪问题”。打开/etc/ssh/sshd_config，你会发现这一行：

#PubkeyAuthentication yes

很多人会把它取消注释，改成PubkeyAuthentication yes，然后重启服务。但这是多余的。Ubuntu 20.04 的 OpenSSH 8.2p1，其编译时默认值就是PubkeyAuthentication yes。sshd -T | grep pubkeyauthentication的输出永远是pubkeyauthentication yes，无论配置文件里是否写这一行。所以，如果你的密钥登录失败，问题绝不在这里。盲目修改反而可能引入语法错误（比如多了一个空格），导致sshd启动失败。

3.2 陷阱二：AuthorizedKeysFile的路径权限，比你想象的更苛刻

默认配置是：

AuthorizedKeysFile .ssh/authorized_keys

这看起来很直白：每个用户的.ssh/authorized_keys文件。但sshd在读取这个文件前，会进行三级权限校验：

  1. 用户家目录（/home/ubuntu）：权限不能大于755（即drwxr-xr-x）。如果它是777，sshd会直接拒绝读取，日志里只有一句Authentication refused: bad ownership or modes for directory /home/ubuntu。
  2. .ssh目录：权限必须是700（drwx------）。755都不行，因为其他用户可能有读权限。
  3. authorized_keys文件：权限必须是600（-rw-------）。644会失败。

我见过最离谱的案例：一位同事为了“方便”，把家目录权限设为777，结果整个 SSH 密钥登录失效。他花了两天时间排查sshd_config，最后才发现是家目录权限问题。修复方法极其简单：

chmod 755 /home/ubuntu chmod 700 /home/ubuntu/.ssh chmod 600 /home/ubuntu/.ssh/authorized_keys

注意：chmod 755 /home/ubuntu是安全的，因为other权限只是r-x，无法写入或删除文件。真正的风险在于777。

3.3 陷阱三：PasswordAuthentication no的时机——必须在密钥验证成功后才关闭

很多教程一上来就教你把PasswordAuthentication设为no，以“增强安全”。但在 Ubuntu 20.04 上，这是一个高危操作。sshd的认证流程是顺序执行的：它先尝试PubkeyAuthentication，失败后再尝试PasswordAuthentication。如果你在密钥还没 100% 验证成功前就关掉密码登录，你就把自己锁在了服务器外面。

正确的节奏是：

  1. 先确保PubkeyAuthentication yes（默认已开启）。
  2. 用ssh-copy-id或手动复制公钥到authorized_keys。
  3. 新开一个终端窗口，用ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no user@host测试。这个命令强制只用公钥认证，如果成功，说明密钥链通了。
  4. 只有此时，才能编辑/etc/ssh/sshd_config，将PasswordAuthentication改为no，并重启sshd。

3.4 陷阱四：UsePAM yes与ChallengeResponseAuthentication的隐性冲突

Ubuntu 20.04 默认启用 PAM（Pluggable Authentication Modules），配置为UsePAM yes。PAM 是一个强大的认证框架，但它会接管部分认证逻辑。如果你同时设置了ChallengeResponseAuthentication yes（默认是no），PAM 可能会尝试调用pam_google_authenticator.so等模块，导致公钥认证被绕过或干扰。

最稳妥的做法是：保持ChallengeResponseAuthentication no。如果你需要双因素认证（2FA），应该使用pam_u2f或pam_totp，并确保它们与PubkeyAuthentication正确集成，而不是依赖ChallengeResponseAuthentication这个老旧接口。

3.5 陷阱五：sshd的日志级别太低，/var/log/auth.log里全是“无用信息”

默认的LogLevel是INFO，它只会记录“用户登录成功”或“密码错误”这类摘要信息。当密钥登录失败时，你看到的可能是：

Failed password for ubuntu from 192.168.1.100 port 54322 ssh2

这明明是公钥认证，为什么显示“Failed password”？因为sshd在内部把所有失败的认证方法都归类为“密码失败”，直到它找到一个成功的。要看到真正的密钥验证细节，必须临时提高日志级别：

# 临时修改（重启后恢复） sudo sed -i 's/^#*LogLevel.*/LogLevel VERBOSE/' /etc/ssh/sshd_config sudo systemctl restart ssh

然后复现问题，再看/var/log/auth.log。你会看到类似：

debug1: Offering public key: /home/ubuntu/.ssh/id_ed25519 ED25519 SHA256:xxx agent debug1: Server accepts key: /home/ubuntu/.ssh/id_ed25519 ED25519 SHA256:xxx debug1: Authentication succeeded (publickey).

或者失败时：

debug1: key_parse_private_pem: invalid format debug1: Trying private key: /home/ubuntu/.ssh/id_rsa_old debug1: key_load_public: No such file or directory

这才是真正有用的诊断信息。问题解决后，记得把LogLevel改回INFO，避免日志文件爆炸式增长。

4. 客户端部署：ssh-copy-id不是万能胶，VS Code Remote-SSH 的 3 个隐藏开关

ssh-copy-id是一个非常方便的工具，它能自动完成“把公钥追加到远程authorized_keys”这件事。但它的便利性背后，藏着三个 Ubuntu 20.04 特有的限制，一旦触发，你的密钥就永远无法抵达目标。

4.1 限制一：ssh-copy-id默认只处理id_rsa和id_dsa，对id_ed25519视而不见

这是ssh-copy-id脚本的一个硬编码逻辑。它在查找本地密钥时，只检查~/.ssh/id_rsa.pub和~/.ssh/id_dsa.pub。如果你生成的是id_ed25519.pub，ssh-copy-id user@host会静默失败，然后提示Number of key(s) added: 0，但不会告诉你为什么。

解决方案有两个：

  • 显式指定公钥文件：ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host
  • 创建符号链接（不推荐，但简单）：ln -sf id_ed25519.pub id_rsa.pub，让ssh-copy-id“以为”你在用 RSA。

我推荐第一种，因为它清晰、无副作用。记住，-i参数后面跟的是公钥文件（.pub），不是私钥。

4.2 限制二：ssh-copy-id无法处理非标准 SSH 端口或自定义用户家目录

如果你的服务器 SSH 端口不是 22（比如2222），或者你用的是一个非标准用户名（比如deploy），ssh-copy-id的默认行为会出错。例如：

ssh-copy-id -p 2222 deploy@host # 报错：/usr/bin/ssh-copy-id: ERROR: No identities found

这是因为ssh-copy-id在内部调用ssh时，没有正确传递-p参数。正确做法是：

# 方法1：用 ssh 命令行参数 ssh-copy-id -i ~/.ssh/id_ed25519.pub "deploy@host -p 2222" # 方法2：配置 ~/.ssh/config（推荐，一劳永逸） echo -e "Host myserver\n HostName host\n User deploy\n Port 2222" >> ~/.ssh/config ssh-copy-id -i ~/.ssh/id_ed25519.pub myserver

~/.ssh/config是 SSH 客户端的“个人字典”，它让ssh命令变得像ssh myserver这样简洁。VS Code Remote-SSH 也完全遵循这个配置文件，所以一次配置，处处受益。

4.3 限制三：VS Code Remote-SSH 的“连接复用”与ssh-agent的微妙关系

这是 VS Code 用户最常踩的坑。你明明在终端里ssh user@host成功了，但 VS Code 的 Remote-SSH 却一直卡在“Setting up SSH Host”或报错Could not establish connection to "host"。

根本原因在于：VS Code Remote-SSH 插件启动时，并不继承你终端里的ssh-agent环境变量（SSH_AUTH_SOCK）。它会尝试自己启动一个ssh-agent，但如果没有密钥被添加进去，它就只能干瞪眼。

解决方法分两步：

  1. 确保ssh-agent已运行并加载密钥：
    # 启动 agent（如果未运行） eval $(ssh-agent -s) # 添加密钥（-k 表示不提示输入 passphrase） ssh-add ~/.ssh/id_ed25519
  2. 让 VS Code 能“看到”这个 agent。最可靠的方式是，在 VS Code 的启动脚本中注入环境变量。编辑~/.profile，添加：
    # 如果 agent 已运行，则导出其 socket if [ -z "$SSH_AUTH_SOCK" ] && [ -S "$(pgrep -u $USER ssh-agent | xargs -I {} cat /proc/{}/environ | tr '\0' '\n' | grep SSH_AUTH_SOCK | cut -d= -f2-)" ]; then export SSH_AUTH_SOCK=$(pgrep -u $USER ssh-agent | xargs -I {} cat /proc/{}/environ | tr '\0' '\n' | grep SSH_AUTH_SOCK | cut -d= -f2-) fi
    然后重启 VS Code（不是窗口，是整个应用）。

更简单的办法是：在 VS Code 的命令面板（Ctrl+Shift+P）中，输入Remote-SSH: Kill VS Code Server on Host...，然后重新连接。这会强制它重建连接环境。

注意：如果你的密钥设置了 passphrase，ssh-add时会要求你输入。你可以用ssh-add -K ~/.ssh/id_ed25519（macOS）或ssh-add --apple-use-keychain ~/.ssh/id_ed25519（如果安装了openssh-client的 macOS 版本）来将其存入系统钥匙串，实现“一次输入，永久免输”。

5. 故障排查实战：从Connection refused到Permission denied的完整诊断链路

当 SSH 密钥登录失败时，错误信息往往模棱两可。Connection refused、Permission denied (publickey)、No route to host……这些词组背后，指向完全不同的故障层级。下面是我总结的 Ubuntu 20.04 下，一套可复用的、从外到内的 5 层诊断链路。它不是“试错列表”，而是一个逻辑树，每一步的结论都决定下一步的方向。

5.1 第一层：网络与服务可达性（L3/L4）

这是最基础的。ssh user@host报Connection refused，首先排除网络问题。

  • 检查目标主机是否在线：ping host。如果ping不通，问题在 DNS 或网络路由。
  • 检查 SSH 服务端口是否开放：telnet host 22或nc -zv host 22。如果连接被拒绝（Connection refused），说明sshd进程根本没在监听 22 端口。
  • 确认sshd服务状态：在目标主机上执行sudo systemctl status ssh。正常状态是active (running)。如果显示inactive (dead)，则sudo systemctl start ssh。
  • 检查sshd是否监听了正确地址：sudo ss -tlnp | grep :22。你应该看到类似LISTEN 0 128 *:22 *:* users:(("sshd",pid=1234,fd=3))。如果显示127.0.0.1:22，说明它只监听本地回环，外部无法访问。这时需要检查/etc/ssh/sshd_config中的ListenAddress，确保没有被设为127.0.0.1。

5.2 第二层：用户与认证上下文（L7）

如果网络通畅，但ssh user@host报Permission denied (publickey)，问题就进入了应用层。

  • 确认你连接的是正确的用户：ssh -l user host和ssh user@host是等价的，但ssh @host（空用户名）会尝试用当前本地用户名登录。Ubuntu 20.04 默认不允许root用户直接 SSH 登录（PermitRootLogin no），所以如果你ssh root@host，必然失败。
  • 确认用户家目录和.ssh目录存在且权限正确（见第3节陷阱二）。
  • 确认authorized_keys文件存在且包含你的公钥：cat /home/user/.ssh/authorized_keys。公钥必须是一行，不能换行，末尾不能有多余空格。可以用ssh-keygen -lf ~/.ssh/id_ed25519.pub生成指纹，然后在远程authorized_keys里搜索这个指纹，确保它被正确添加。

5.3 第三层：密钥格式与算法兼容性（L7 加密层）

这是 Ubuntu 20.04 最具迷惑性的故障点。

  • 检查sshd日志：sudo tail -f /var/log/auth.log，然后在另一台机器上ssh -v user@host。观察日志中是否有Unable to negotiate with或no mutual signature algorithm。如果有，说明客户端和服务器支持的签名算法不匹配。
  • 强制客户端使用特定算法：ssh -o PubkeyAcceptedKeyTypes=+ssh-ed25519 user@host。如果加上这个参数后成功，说明服务器sshd_config中的PubkeyAcceptedKeyTypes设置过于严格，需要放宽。
  • 检查服务器支持的算法：sshd -T | grep -E "(pubkey|kex)"。重点关注pubkeyacceptedkeytypes和kexalgorithms。Ubuntu 20.04 默认支持ssh-ed25519、ecdsa-sha2-nistp256、rsa-sha2-512等。如果你的密钥是ssh-rsa，它会被拒绝。

5.4 第四层：SELinux/AppArmor 强制访问控制（Ubuntu 20.04 的 AppArmor）

Ubuntu 20.04 默认启用 AppArmor，它是一个 Linux 内核安全模块，可以限制程序能访问的文件和资源。sshd的 AppArmor 配置文件（/etc/apparmor.d/usr.sbin.sshd）如果被意外修改，可能导致sshd无法读取authorized_keys。

  • 临时禁用 AppArmor 测试：sudo systemctl stop apparmor，然后sudo systemctl restart ssh。如果此时密钥登录成功，问题就出在 AppArmor。
  • 检查 AppArmor 日志：sudo dmesg | grep -i avc或sudo journalctl | grep -i apparmor。你会看到类似avc: denied { read } for pid=1234 comm="sshd" name="authorized_keys" ...的拒绝记录。
  • 修复方法：编辑/etc/apparmor.d/usr.sbin.sshd，在#include <abstractions/nameservice>下面添加：
    /home/*/ssh/authorized_keys r, /home/*/.ssh/authorized_keys r,
    然后sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.sshd重载策略。

5.5 第五层：ssh-agent与连接复用（客户端状态）

如果以上都正常，但 VS Code 或git仍然失败，问题就在客户端。

  • 检查ssh-agent状态：echo $SSH_AUTH_SOCK。如果为空，说明 agent 没运行或没被继承。
  • 检查密钥是否已加载：ssh-add -l。它会列出所有已加载的密钥指纹。如果列表为空，执行ssh-add ~/.ssh/id_ed25519。
  • 检查ssh命令是否启用了连接复用：ssh -O check user@host。如果报错Control socket connect failed，说明复用 socket 不存在，但这不影响首次连接。真正的问题是，VS Code Remote-SSH 默认启用复用，所以它需要一个稳定的ssh-agent。

这张诊断链路图，不是让你按顺序“试一遍”，而是让你根据错误信息，精准定位到哪一层。比如，Connection refused直接跳到第一层；Permission denied (publickey)则从第二层开始，逐层向下。每一次sudo journalctl -u ssh --since "1 minute ago"的日志输出，都是一个明确的信号，告诉你该往哪个方向走。

6. 生产环境加固：超越“免密登录”的 4 个进阶实践

当你已经能稳定地用 Ed25519 密钥登录 Ubuntu 20.04，下一步就是把它变成一个真正健壮、可审计、可管理的生产级访问通道。这不再是“怎么连上”，而是“怎么连得更安全、更可控、更可追溯”。

6.1 实践一：为不同场景创建专用密钥对，实施最小权限原则

不要用同一对密钥登录所有服务器。这是最大的安全疏忽。你应该为每个高价值目标创建独立密钥：

  • id_ed25519_prod_db：仅用于连接生产数据库服务器，且该密钥的authorized_keys条目应附加command="psql -U dbuser"限制，使其只能执行psql命令。
  • id_ed25519_ci_cd：用于 Jenkins/GitLab Runner，其authorized_keys条目应附加no-port-forwarding,no-X11-forwarding,no-agent-forwarding，彻底禁用所有危险的转发功能。
  • id_ed25519_backup：用于备份脚本，附加from="192.168.10.0/24"，只允许来自内网备份服务器的连接。

如何为密钥添加这些限制？编辑远程服务器上的~/.ssh/authorized_keys，找到你的公钥行，在开头添加：

command="rsync --server --sender",no-port-forwarding,no-X11-forwarding,from="10.0.0.5" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

这些限制由sshd在认证后强制执行，无法被客户端绕过。这是 SSH 协议原生支持的、最轻量级的访问控制。

6.2 实践二：用Match块在sshd_config中实现细粒度策略

/etc/ssh/sshd_config的Match指令，允许你为特定用户、组、IP 地址段定义专属规则。这比在authorized_keys里加限制更强大，因为它在认证前就生效。

例如，你想让admin组的所有用户，只能从公司内网（192.168.1.0/24）登录，且必须使用密钥：

Match Group admin AllowUsers * AllowGroups admin PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes Match Address 192.168.1.0/24 # 这里是内网规则 Match Address *,!192.168.1.0/24 # 这里是外网规则，可以设为 DenyUsers *

更实用的例子是：为git用户启用ForceCommand，将其锁定在git-shell环境中，防止其获得一个完整的交互式 shell：

Match User git ForceCommand /usr/bin/git-shell -c "$SSH_ORIGINAL_COMMAND" AllowTcpForwarding no X11Forwarding no

6.3 实践三：启用sshd的登录审计与失败告警

Ubuntu 20.04 的rsyslog默认会将sshd日志写入/var/log/auth.log。但你需要主动配置，才能让它成为有效的安全监控源。

  • 增强日志详细度：在/etc/ssh/sshd_config中，设置LogLevel VERBOSE（生产环境可设为INFO，但保留Authentication相关日志）。
  • 分离 SSH 日志：创建/etc/rsyslog.d/50-ssh.conf：
    if $programname == 'sshd' then /var/log/sshd.log & stop
    然后sudo systemctl restart rsyslog。这样，/var/log/sshd.log就成了纯粹的 SSH 审计日志，方便用grep或awk分析。
  • 设置失败登录告警：用faillog工具监控。sudo faillog -u ubuntu查看用户失败次数。结合cron，每天执行sudo faillog -a | awk '$3 > 5 {print $1}'，如果输出用户名，就发邮件告警。

6.4 实践四：定期轮换密钥，建立密钥生命周期管理

密钥不是“一次生成，永久有效”。你应该像管理密码一样管理密钥。

  • 设定轮换周期：建议 Ed25519 密钥每 12 个月轮换一次，RSA 密钥每 6 个月。
  • 自动化轮换脚本：编写一个 Bash 脚本，它会：
    1. 生成新密钥对。
    2. 将新公钥追加到所有目标服务器的authorized_keys。
    3. 记录旧密钥的指纹和过期时间到一个 CSV 文件。
    4. （可选）在authorized_keys中为旧密钥添加expire-after="2024-12-31"注释（需要自定义脚本解析）。
  • 密钥吊销：如果某台开发机丢失，立即从所有服务器的authorized_keys中删除其对应的公钥行。这是最快速的“吊销”方式。

这些实践，不是锦上添花的“高级技巧”，而是 Ubuntu 20.04 上构建一个可持续、可信赖的 SSH 基础设施的必经之路。它们把一个简单的“免密登录”，升级为一个有策略、有审计、有弹性的企业级访问控制体系。我见过太多团队，前期图省事，用一个密钥打天下，结果在一次安全审计中，被要求在 48 小时内完成全部密钥轮换，手忙脚乱，漏洞百出。提前规划，才是真正的效率。

我在实际运维中发现，最有效的习惯是：每次生成新密钥，都立刻在密钥文件名里加上日期和用途，比如id_ed25519_2024_q3_prod_api。这样，一年后你看到这个文件，不用打开就知道它是什么、什么时候该退役。技术细节会遗忘，但命名规范留下的线索，永远清晰。