tunnel-bastion-client服务无法启动 隧道堡垒机连通故障排查求助

从你提供的服务日志可以直接定位核心错误是Host key verification failed，属于SSH连接校验失败，和你已经验证正常的RDS侧无关，故障完全出在客户端EC2到服务端EC2的SSH隧道建立阶段。
SSH默认会对连接的远程主机做密钥校验，只有远程主机的公钥已经存储在本地~/.ssh/known_hosts文件中，才会允许连接，非交互模式下不会弹出确认提示，直接校验失败退出，导致服务启动失败。

• 场景1：首次部署未预先配置主机密钥信任
  你通过Terraform部署时没有提前将服务端EC2的主机指纹写入客户端EC2对应服务用户的known_hosts文件，首次连接时校验不通过。
  修复方式：
  1. 手动临时修复：登录客户端EC2，切换到运行tunnel-bastion-client服务的用户，手动执行一次SSH连接服务端EC2的命令，确认主机密钥后即可自动写入缓存。
  2. Terraform自动化适配：在客户端EC2的userdata配置中添加命令，部署时自动拉取服务端主机密钥写入配置，示例命令：

  ssh-keyscan -H <替换为服务端EC2的内网IP/访问域名> >> ~/.ssh/known_hosts
  

• 场景2：服务端EC2密钥变更导致缓存不匹配
  如果服务端EC2曾经重新创建、重装系统，IP复用但主机公钥更新，客户端缓存的旧公钥和新公钥不一致，触发安全校验拦截。
  修复方式：
  登录客户端EC2，先执行命令删除旧的密钥缓存：

  ssh-keygen -R <替换为服务端EC2的内网IP/访问域名>
  

  再按照场景1的方法添加新的主机公钥即可。
• 场景3：服务运行用户和手动测试用户不一致
  如果你用ubuntu/ec2-user等普通用户手动测试SSH连接正常，但tunnel-bastion-client服务是通过root或者其他专用服务用户运行，普通用户的known_hosts配置不会对服务用户生效，依旧会校验失败。
  修复方式：
  查看tunnel-bastion-client的systemd配置文件，确认User参数指定的运行用户，切换到对应用户后再执行上述的密钥配置操作。

配置完成后执行命令重启服务验证：

sudo systemctl restart tunnel-bastion-client.service
sudo systemctl status tunnel-bastion-client.service

服务启动成功后，再测试客户端EC2的隧道转发端口是否能正常连通RDS即可。

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