使用Let's Encrypt更新网站后AWS EC2实例SSH连接失败求助

看起来你遇到的是EC2实例本地层面的SSH阻塞问题，你已经排除了安全组的可能性——毕竟新实例用原安全组能正常连接，原实例换任何安全组都不行，所以问题肯定出在实例自身的系统配置或者资源状态上。咱们一步步排查，同时解答你关于无SSH登录的疑问：

一、SSH连接失败的核心排查步骤 #

1. 先检查实例资源是否耗尽 #

首先通过AWS控制台查看实例的监控指标：CPU跑满、内存耗尽或者磁盘空间占满，都会导致SSH服务无法响应，出现「Resource temporarily unavailable」的错误：

• 操作路径：EC2控制台找到目标实例，点击「监控」标签，查看最近的CPU使用率、内存（需启用CloudWatch详细监控）、磁盘IO情况。
• 重点留意磁盘空间：你昨天刚配置了Let's Encrypt，certbot的日志、Nginx的访问日志很容易快速占满小容量的系统盘，尤其是Ubuntu 16的默认系统盘如果没扩容，大概率会出这个问题。

2. 查看系统日志定位sshd相关错误 #

虽然没法SSH，但可以通过AWS控制台直接获取实例的系统日志和控制台输出，这是定位问题的关键：

• 操作路径：EC2控制台 → 目标实例 → 「操作」→ 「实例设置」→ 「获取系统日志」/「获取控制台输出」
• 重点搜索这些内容：
  • sshd服务启动失败的日志（比如端口被占用、配置文件语法错误）
  • 权限相关报错：比如/home/ubuntu目录权限被误改，或者~/.ssh/authorized_keys的权限异常（你配置HTTPS的时候有没有不小心碰过系统权限？）
  • 系统启动时的磁盘挂载错误，这会导致系统初始化异常，SSH服务根本无法启动

3. 排查实例内部防火墙规则 #

Ubuntu 16默认可能启用了UFW防火墙，或者你配置Let's Encrypt的时候有没有修改过iptables规则？安全组开了22端口，但实例内部防火墙如果封禁了22，照样连不上。这个可以后面用无SSH方式进去排查。

4. 检查sshd配置文件是否异常 #

如果系统日志里提到sshd配置错误，比如不小心把AllowUsers设成了不存在的用户，或者禁用了ubuntu用户的登录权限，也会导致连接失败。回忆下之前有没有修改过/etc/ssh/sshd_config？

二、无需SSH就能登录EC2实例的方式 #

AWS确实提供了几种官方方案，不用SSH密钥也能访问实例：

1. EC2串行控制台（Serial Console） #

这是最直接的应急方式，只要你的实例是Ubuntu 16.04及以上版本，并且你给账号开了串行控制台权限，就能直接在控制台打开一个终端：

• 操作路径：EC2控制台 → 目标实例 → 「连接」→ 选择「串行控制台」→ 点击「连接」，然后输入ubuntu用户名和密码（如果没设置过密码，可以先通过实例元数据重置，不过Ubuntu默认用密钥，可能需要先重置密码）。

2. AWS Systems Manager Session Manager #

这是我最推荐的方式，不需要开放22端口，也不用本地存储密钥，只要满足两个条件：

• 实例关联了带有AmazonSSMManagedInstanceCore权限的IAM角色
• 实例能访问SSM服务（可以通过公网或者VPC端点）
• 操作路径：EC2控制台 → 目标实例 → 「连接」→ 选择「Session Manager」→ 点击「连接」，直接在浏览器里打开一个Shell窗口，操作体验和SSH完全一致。

3. 通过用户数据执行修复脚本（紧急情况） #

如果实例能访问公网/VPC端点，可以通过修改实例的用户数据来执行修复脚本，比如重启sshd、清理磁盘、重置配置：

• 比如写个清理日志的脚本：

  #!/bin/bash
  # 清理Nginx旧日志
  rm -rf /var/log/nginx/*.log.old
  # 清理Let's Encrypt旧日志
  rm -rf /var/log/letsencrypt/*.log.old
  # 重启sshd服务
  systemctl restart sshd
  

• 操作路径：EC2控制台 → 目标实例 → 「操作」→ 「实例设置」→ 「修改用户数据」→ 粘贴脚本 → 保存后重启实例，脚本会在启动时自动执行。

三、针对你的场景的快速建议 #

1. 先查实例监控里的磁盘空间——这是最常见的原因，毕竟刚配置了HTTPS，日志量会激增；
2. 查看系统日志里的sshd相关报错，直接定位问题根源；
3. 如果以上都没头绪，赶紧试试Session Manager（如果实例有SSM权限），进去后直接查看/var/log/auth.log（Ubuntu的SSH日志），里面会有每一次连接失败的详细原因。

内容的提问来源于stack exchange，提问作者Jeffery