47秒崩溃：一个权限数字如何让SSH集体罢工

你输入完那串命令，按下回车。47秒后，屏幕弹出那行字：

Permission denied (publickey).

没有更多解释，没有错误代码，没有下一步指引。这就是AWS EC2的SSH拒绝——全球开发者周五晚上最熟悉的噩梦。但真相是：问题几乎从不在AWS，而在一个被忽略的数字。

SSH的偏执：为什么644权限会被直接拉黑

EC2实例不认密码，只认密钥对。这是AWS的基础设计——你的私钥文件（.pem）和实例里预置的公钥必须匹配。

但匹配只是第一步。SSH客户端有个硬规则：私钥文件权限必须严格受限。如果权限是644（即所有用户可读），SSH会立即拒绝连接，连尝试验证的机会都不给。

作者第一次踩这个坑，是把.pem文件通过共享驱动复制到另一台机器。文件权限在传输中变成了644——世界可读。SSH看到之后直接说"nope"，没有任何商量余地。

修复只需要一行命令：

chmod 400 your-key.pem

400意味着只有文件所有者能读取，其他任何人无任何权限。这是SSH唯一接受的设置。

~/Downloads文件夹尤其危险。这个目录默认权限开放，把私钥放在这里等于主动暴露。正确做法是把密钥移到~/.ssh/目录，再执行权限修复。作者见过这个细节浪费掉数小时的排查时间。

密钥丢失的救急方案：不用重建实例

最坏的情况：.pem文件彻底丢失——删除、格式化、旧电脑报废。AWS不存储私钥，无法重新下载。

但实例不必重建。核心思路是利用EBS卷的独立性：

第一步，关停问题实例（不是终止，是停止）。把它的根卷分离出来。

第二步，启动一个"救援实例"——同可用区的任意EC2机器。将分离的卷作为辅助磁盘挂载上去。

第三步，在救援实例上访问挂载卷的/home/ubuntu/.ssh/authorized_keys文件，追加新的公钥。

第四步，卸载卷，重新挂回原实例，启动。新密钥立即生效。

作者去年用这个方法帮团队救回一个误删密钥的实例，省了6小时重建时间。操作不优雅，但确实可行。

用户名陷阱：ubuntu还是ec2-user？

另一个高频错误：用户名写错。Ubuntu官方AMI默认用户是ubuntu，Amazon Linux是ec2-user。混用直接导致认证失败，和密钥本身无关。

AWS控制台提供的"Connect → SSH"功能看似省事，实际走的是EC2 Instance Connect——通过AWS API推送临时密钥，完全不使用你的.pem文件。如果习惯用命令行SSH，这个功能帮不上忙。

为什么这些细节值得较真

SSH权限问题表面是技术故障，底层是安全设计的严格性在"惩罚"粗心。644到400的改动，本质是开发者从"能用就行"转向"按规则办事"的思维切换。

EC2的密钥机制把身份验证完全交给用户本地管理，AWS不保管、不干预、不兜底。这种设计减少了平台方的安全责任，也把风险转移给了使用者。

对于25-40岁的技术从业者，这个案例的价值在于：基础设施的"简单"操作背后，往往有不可妥协的约束条件。知道这些约束的存在，比记住具体命令更重要。