亚马逊云企业实名 AWS亚马逊云SSH连接失败解决

你盯着终端里那行冰冷的 ssh: connect to host 3.123.45.67 port 22: Connection refused，手边咖啡凉了三回，监控面板上CPU空载如荒原，而你的上线 deadline 正在倒计时——别慌，这不是世界末日，只是 AWS 在用它特有的方式，温柔地提醒你：「亲，你的 SSH 不是挂了，是迷路了。」

作为在 AWS 上摔过七次跟头、修过三百台 EC2 的老运维，我敢拍胸脯说：92% 的 SSH 连接失败，根本不是云服务出问题，而是你和服务器之间，缺了一次「心平气和的对话」。今天这篇，不堆概念，不甩文档链接，就拿你刚遇到的报错当靶子，一枪一枪打穿真相。

第一枪：密钥文件，不是「有就行」，是「对得严丝合缝」

先别急着查安全组！打开你的终端，敲：
ls -l ~/.ssh/my-key.pem

如果看到 -rw-r--r--（也就是 644 权限），立刻停下所有操作——你的私钥正在裸奔。SSH 协议会直接拒收，连握手都不给你机会。正确姿势：
chmod 400 ~/.ssh/my-key.pem

顺手验证下路径拼写有没有手滑：
ssh -i "~/Downloads/ec2-key.pem" [email protected] —— 注意，波浪号 ~ 在引号里可能失效！改成绝对路径更稳：
ssh -i "/Users/you/Downloads/ec2-key.pem" [email protected]

第二枪：安全组？它不是装饰画，是门禁卡

登录控制台 → EC2 → 实例 → 点开你的实例 → 往下拉到「安全组」→ 点进去。重点看两列：入站规则 和 应用到。

常见翻车现场：
• 规则写了 SSH (22)，但源 IP 是 0.0.0.0/0 —— 听起来很开放，但如果你在公司内网，真实出口 IP 可能是 10.x.x.x 或 172.x.x.x，被防火墙挡了；
• 安全组绑错了实例（比如你改了实例，但忘了更新关联）；
• 规则看似生效，但「应用到」显示 已应用 实际却是灰色小字 未应用（刷新页面再确认）。

终极检验法：临时把源 IP 改成 0.0.0.0/0，测试通不通。通了？说明是你本地网络限制；不通？继续往下挖。

第三枪：实例没「醒」，你却在敲门

控制台里状态是「运行中」≠ 实例真醒了。点开实例详情页，看「状态检查」两项：
• 实例状态检查：检测底层硬件/虚拟化层；
• 系统状态检查：检测操作系统是否响应。

如果「系统状态检查」失败（红叉），大概率是 OS 卡死、OOM、内核 panic 或磁盘满。这时候 SSH 进不去，但你可以：① 停止再启动实例（注意：这会换新公网 IP，除非你用了弹性 IP）；② 或者启用「EC2 Serial Console」（需提前开启）直连控制台。

第四枪：公钥没塞进家门，你拿钥匙也白搭

如果你用的是 Amazon Linux 2 / AL2023 或 Ubuntu，且启动时选了「新建密钥对」，公钥通常由 CloudInit 自动注入到 /home/ec2-user/.ssh/authorized_keys（或 /home/ubuntu/.ssh/authorized_keys）。但如果手动重装系统、用自定义 AMI 或跳过了密钥注入步骤——恭喜，门锁是新的，旧钥匙打不开。

验证方法：用 Session Manager（无需 SSH）登录，执行：
sudo cat /home/ec2-user/.ssh/authorized_keys | head -n1
看输出是否匹配你本地公钥的开头（ssh-rsa AAAA...）。不匹配？重新注入或改用密码登录（需提前配置）。

第五枪：SELinux：那个默默关灯的「守夜人」

Amazon Linux 默认开启 SELinux。某次内核升级后，它可能悄悄把 sshd 的上下文搞乱，导致服务启动但拒绝连接。症状：systemctl status sshd 显示 active，但 journalctl -u sshd -n 50 里刷屏 setcontext: permission denied。

临时解法（验证用）：
sudo setenforce 0
再试 SSH。如果通了，就是它。永久修复：
sudo restorecon -Rv /etc/ssh /var/empty/sshd

第六枪：网络 ACL —— 安全组的沉默双胞胎

安全组管「实例级别」，网络 ACL 管「子网级别」。很多人只改安全组，忘了 ACL 默认拒绝所有入站。去 VPC 控制台 → 网络 ACL → 找到实例所在子网关联的 ACL → 检查入站规则第 100 条是不是写着 Deny All？

加一条显式允许：
规则编号：90
类型：SSH
源：0.0.0.0/0
允许/拒绝：ALLOW

第七枪：DNS？别信它，用 IP 直连

亚马逊云企业实名 你输的是 ssh [email protected]，结果超时。先执行：
nslookup ec2-3-123-45-67.compute-1.amazonaws.com
如果返回「server can't find…」，说明 DNS 解析失败。此时立刻切 IP：
ssh -i key.pem [email protected]

根源可能是：本地 hosts 写了错误映射、路由器 DNS 被污染、或区域 DNS 服务暂抖。别折腾，IP 最可靠。

第八枪：用户被锁了？试试 root 或 ubuntu

某些 AMI 默认禁用 root 密码登录，但允许 ec2-user（AL）或 ubuntu（Ubuntu）。如果你改过用户名、删过默认用户、或启用了 PAM 锁定策略，ec2-user 可能已失效。

用 Session Manager 登录后，查用户是否存在：
getent passwd | grep -E "(ec2-user|ubuntu)"
再看其 shell 是否为 /bin/bash（不是 /sbin/nologin）。

第九枪：CloudInit 还在「装修」，你已按响门铃

新建实例后立刻 SSH？小心！CloudInit 可能还在初始化用户、写入密钥、配置网络。此时 ss -tlnp | grep :22 可能显示 sshd 已监听，但 /home/ec2-user/.ssh/authorized_keys 还是空的。等 60–90 秒再试，或看控制台「系统日志」末尾是否有 Cloud-init v.* finished。

第十枪：IP 换了？你还在拨旧号码

停止/启动实例后，公有 IPv4 地址会变（除非绑了弹性 IP）。你 Ctrl+V 的还是上次的 IP？去控制台实例页，看「IPv4 公有地址」栏——别信记忆，信屏幕。

终极口诀送给你：
一查权限二看组，三验实例四核钥，五问 SELinux 六 ACL，七弃 DNS 八换用户，九等 CloudInit 十盯 IP。

最后说句掏心窝的：AWS 的错误从不撒谎，它只是把「哪里错了」藏在了十层套娃里。而你唯一要做的，就是一层一层剥开，像拆快递一样耐心。毕竟，当 Last login: Mon Jun 10 14:22:18 2024 from 112.65.33.12 终于跳出来时，那种爽感，比抢到演唱会门票还上头。