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

1. 为什么 Ubuntu 20.04 上的 SSH 密钥不是“配个钥匙就完事”——它本质是一套身份信任链的初始化你可能刚在终端里敲下ssh-keygen -t rsa -b 4096回车三次然后ssh-copy-id userhost接着就以为“免密登录成功了”。但现实是第二天你发现 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 gitgithub.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-rsasshd会直接拒绝该密钥连日志都不写——它认为这是一次无效的协议协商而非认证失败。这就是为什么很多人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.8Ubuntu 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 # 方式BOpenSSH格式推荐 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_emailexample.com -f ~/.ssh/id_ed25519 -N -t ed25519指定算法这是当前最优解。-C your_emailexample.com添加注释Comment它会出现在authorized_keys文件中方便你一眼识别密钥来源。很多团队用它标记环境如prod-jenkinsserver1避免混淆。-f ~/.ssh/id_ed25519强制指定文件名避免覆盖默认的id_rsa。强烈建议为不同用途创建不同密钥如id_ed25519_github,id_ed25519_work这是最小权限原则的体现。-N 空密码passphrase。注意这里不是“不设密码”而是显式声明密码为空。如果你希望更高安全级别应设一个强密码如ssh-keygen -N My$tr0ngPss!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 userlocalhost失败第一反应是“配置写错了”其实问题往往出在更底层的系统行为上。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在读取这个文件前会进行三级权限校验用户家目录/home/ubuntu权限不能大于755即drwxr-xr-x。如果它是777sshd会直接拒绝读取日志里只有一句Authentication refused: bad ownership or modes for directory /home/ubuntu。.ssh目录权限必须是700drwx------。755都不行因为其他用户可能有读权限。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% 验证成功前就关掉密码登录你就把自己锁在了服务器外面。正确的节奏是先确保PubkeyAuthentication yes默认已开启。用ssh-copy-id或手动复制公钥到authorized_keys。新开一个终端窗口用ssh -o PreferredAuthenticationspublickey -o PasswordAuthenticationno userhost测试。这个命令强制只用公钥认证如果成功说明密钥链通了。只有此时才能编辑/etc/ssh/sshd_config将PasswordAuthentication改为no并重启sshd。3.4 陷阱四UsePAM yes与ChallengeResponseAuthentication的隐性冲突Ubuntu 20.04 默认启用 PAMPluggable Authentication Modules配置为UsePAM yes。PAM 是一个强大的认证框架但它会接管部分认证逻辑。如果你同时设置了ChallengeResponseAuthentication yes默认是noPAM 可能会尝试调用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.pubssh-copy-id userhost会静默失败然后提示Number of key(s) added: 0但不会告诉你为什么。解决方案有两个显式指定公钥文件ssh-copy-id -i ~/.ssh/id_ed25519.pub userhost创建符号链接不推荐但简单ln -sf id_ed25519.pub id_rsa.pub让ssh-copy-id“以为”你在用 RSA。我推荐第一种因为它清晰、无副作用。记住-i参数后面跟的是公钥文件.pub不是私钥。4.2 限制二ssh-copy-id无法处理非标准 SSH 端口或自定义用户家目录如果你的服务器 SSH 端口不是 22比如2222或者你用的是一个非标准用户名比如deployssh-copy-id的默认行为会出错。例如ssh-copy-id -p 2222 deployhost # 报错/usr/bin/ssh-copy-id: ERROR: No identities found这是因为ssh-copy-id在内部调用ssh时没有正确传递-p参数。正确做法是# 方法1用 ssh 命令行参数 ssh-copy-id -i ~/.ssh/id_ed25519.pub deployhost -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 userhost成功了但 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但如果没有密钥被添加进去它就只能干瞪眼。解决方法分两步确保ssh-agent已运行并加载密钥# 启动 agent如果未运行 eval $(ssh-agent -s) # 添加密钥-k 表示不提示输入 passphrase ssh-add ~/.ssh/id_ed25519让 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 的命令面板CtrlShiftP中输入Remote-SSH: Kill VS Code Server on Host...然后重新连接。这会强制它重建连接环境。注意如果你的密钥设置了 passphrasessh-add时会要求你输入。你可以用ssh-add -K ~/.ssh/id_ed25519macOS或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 userhost报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,pid1234,fd3))。如果显示127.0.0.1:22说明它只监听本地回环外部无法访问。这时需要检查/etc/ssh/sshd_config中的ListenAddress确保没有被设为127.0.0.1。5.2 第二层用户与认证上下文L7如果网络通畅但ssh userhost报Permission denied (publickey)问题就进入了应用层。确认你连接的是正确的用户ssh -l user host和ssh userhost是等价的但ssh host空用户名会尝试用当前本地用户名登录。Ubuntu 20.04 默认不允许root用户直接 SSH 登录PermitRootLogin no所以如果你ssh roothost必然失败。确认用户家目录和.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 userhost。观察日志中是否有Unable to negotiate with或no mutual signature algorithm。如果有说明客户端和服务器支持的签名算法不匹配。强制客户端使用特定算法ssh -o PubkeyAcceptedKeyTypesssh-ed25519 userhost。如果加上这个参数后成功说明服务器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 的 AppArmorUbuntu 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 pid1234 commsshd nameauthorized_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 userhost。如果报错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条目应附加commandpsql -U dbuser限制使其只能执行psql命令。id_ed25519_ci_cd用于 Jenkins/GitLab Runner其authorized_keys条目应附加no-port-forwarding,no-X11-forwarding,no-agent-forwarding彻底禁用所有危险的转发功能。id_ed25519_backup用于备份脚本附加from192.168.10.0/24只允许来自内网备份服务器的连接。如何为密钥添加这些限制编辑远程服务器上的~/.ssh/authorized_keys找到你的公钥行在开头添加commandrsync --server --sender,no-port-forwarding,no-X11-forwarding,from10.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环境中防止其获得一个完整的交互式 shellMatch User git ForceCommand /usr/bin/git-shell -c $SSH_ORIGINAL_COMMAND AllowTcpForwarding no X11Forwarding no6.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.confif $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 脚本它会生成新密钥对。将新公钥追加到所有目标服务器的authorized_keys。记录旧密钥的指纹和过期时间到一个 CSV 文件。可选在authorized_keys中为旧密钥添加expire-after2024-12-31注释需要自定义脚本解析。密钥吊销如果某台开发机丢失立即从所有服务器的authorized_keys中删除其对应的公钥行。这是最快速的“吊销”方式。这些实践不是锦上添花的“高级技巧”而是 Ubuntu 20.04 上构建一个可持续、可信赖的 SSH 基础设施的必经之路。它们把一个简单的“免密登录”升级为一个有策略、有审计、有弹性的企业级访问控制体系。我见过太多团队前期图省事用一个密钥打天下结果在一次安全审计中被要求在 48 小时内完成全部密钥轮换手忙脚乱漏洞百出。提前规划才是真正的效率。我在实际运维中发现最有效的习惯是每次生成新密钥都立刻在密钥文件名里加上日期和用途比如id_ed25519_2024_q3_prod_api。这样一年后你看到这个文件不用打开就知道它是什么、什么时候该退役。技术细节会遗忘但命名规范留下的线索永远清晰。