使用Ubuntu私有AMI启动实例后SSH连接超时、实例可达性检查失败

你已经完成了网络层面的基础排查，问题可确定出在实例内部系统配置或AMI制作缺陷上，可按如下步骤排查：

一、先确认AMI制作合规性 #

• 制作AMI前是否执行了磁盘同步操作：Ubuntu系统制作EBS-backed类型的AMI前，建议先执行sudo sync && sudo fsfreeze -f / 确保磁盘数据完全写入，若制作时原生产实例正在跑高IO业务，很容易出现AMI内系统文件损坏、缺失的问题。
• 检查原生产实例的cloud-init配置是否被修改：如果原实例禁用了cloud-init、或者自定义了SSH密钥注入逻辑，新实例启动时无法正确注入你选择的SSH密钥，也会触发可达性检查失败、SSH连接超时。

二、离线救援模式排查方案 #

当前实例状态检查失败无法直接SSH，可通过挂载根卷到正常实例的方式离线排查：

• 先停止当前故障实例（不要终止，避免数据丢失），分离其根卷（默认挂载路径为/dev/sda1的EBS卷）
• 启动一台同可用区的正常Ubuntu临时实例，把刚才分离的故障根卷作为数据卷挂载到临时实例上，挂载路径设置为/mnt/rescue
• 挂载完成后执行如下命令检查系统日志，定位故障点：

  cat /mnt/rescue/var/log/auth.log
  cat /mnt/rescue/var/log/syslog
  cat /mnt/rescue/var/log/cloud-init.log
  

  重点排查四个方向：SSH服务是否启动成功、是否有磁盘挂载错误（比如fstab里配置了原实例的其他EBS卷UUID，新实例没有对应卷导致启动卡挂载流程）、cloud-init是否执行报错、是否有系统内部iptables/ufw规则封禁了22端口（安全组是AWS平台层面的规则，系统内部防火墙拦截的话一样无法连接）
• 检查SSH服务配置：打开/mnt/rescue/etc/ssh/sshd_config，确认是否配置了允许密钥登录、是否修改了SSH默认端口、是否限制了登录IP段。
• 修复完问题后卸载该卷，重新挂载回故障实例作为根卷，启动实例测试即可。

三、高频问题快速修复 #

• 若为fstab配置错误导致启动失败：注释掉fstab里非根卷的挂载项，再重新启动实例
• 若为系统防火墙封禁22端口：在救援模式下执行chroot /mnt/rescue后执行ufw allow 22清空防火墙规则，退出chroot后重新挂载回原实例
• 若为cloud-init配置错误：移除/mnt/rescue/etc/cloud/cloud.cfg.d/下的自定义配置文件，恢复默认cloud-init配置，确保新实例启动时可以正确配置网络和SSH密钥

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