Google Cloud SSH 登录失败怎么办，从权限到网络逐项检查

在Google Cloud中，SSH登录失败并不一定意味着SSH服务本身出现故障。从用户身份认证、IAM权限，到VM实例状态、VPC防火墙、SSH密钥，再到虚拟机内部的sshd服务，任何一个环节出现问题，都可能导致连接失败。

排查这类问题不能一上来修改sshd_config或者重新生成密钥。更有效的方法是从外到内逐层检查，先判断问题发生在Google Cloud控制层、网络层还是虚拟机操作系统内部。

第一步应该确认Google Cloud身份和目标项目

如果使用gcloud命令行，首先确认当前登录的是正确的Google账号：

`gcloud auth list`

然后检查当前项目：

`gcloud config get-value project`

如果当前项目不是目标项目，可以使用：

`gcloud config set project PROJECT_ID`

随后列出虚拟机：

`gcloud compute instances list`

确认目标VM确实存在，并且状态为RUNNING。

这一步看似简单，却可以排除一个非常常见的问题：用户实际上连接的是另一个Google Cloud项目，或者当前账号没有目标项目的访问权限。

第二步检查IAM权限和SSH方式

Google Cloud的SSH访问并不只是“拥有一个私钥”这么简单。现代Compute Engine环境可以通过OS Login、项目或实例元数据中的SSH密钥，以及Google Cloud控制台提供的SSH连接机制进行身份验证。

如果项目启用了OS Login，用户是否拥有相应的IAM权限就会直接影响SSH登录。例如用户可能能够查看VM，却没有通过OS Login登录操作系统的权限。

因此，遇到SSH失败时，需要先确认实例是否启用了OS Login，以及当前账号是否具有相应权限。

可以查看实例元数据：

`gcloud compute instances describe INSTANCE_NAME --format="get(metadata.items)"`

也可以检查项目级元数据：

`gcloud compute project-info describe`

如果使用的是SSH密钥，还需要确认本地私钥文件能够被当前SSH客户端正常读取。例如Linux或macOS通常可以检查：

`ls -l ~/.ssh/id_ed25519`

或者：

`ls -l ~/.ssh/id_rsa`

常见权限设置是只有当前用户可以读取私钥，例如600。Windows环境则采用NTFS权限控制，不能简单套用Linux的chmod规则。

还需要注意，OpenSSH并不要求私钥必须使用所谓“PEM格式”。现代OpenSSH默认使用自己的私钥格式，ED25519等密钥也非常常见。遇到密钥问题时，应该根据实际报错判断，而不是为了所谓兼容性强行转换密钥格式。

第三步检查VPC防火墙

如果账号和密钥没有问题，下一层就是网络。

Google Cloud使用VPC防火墙规则控制VM的网络流量。对于传统公网SSH连接，需要存在允许进入TCP 22端口的INGRESS规则，并且该规则需要作用于目标VM。

可以查看防火墙规则：

`gcloud compute firewall-rules list`

重点检查三个地方：规则方向、允许的协议和端口，以及目标范围。

例如规则可能允许：

`tcp:22`

但如果目标标签没有应用到对应VM，或者来源IP范围没有包含当前客户端地址，SSH仍然无法连接。

如果为了测试临时开放22端口给所有IPv4地址，可以使用0.0.0.0/0，但生产环境不建议长期这样配置。更合理的做法是限制来源IP，或者通过更安全的管理访问方式减少公网SSH暴露。

第四步确认VM是否具有可达的网络路径

防火墙允许SSH并不代表网络一定能够到达VM。

如果VM没有公网IP，直接从普通互联网环境连接公网SSH自然无法成功。这种情况下通常需要通过VPN、堡垒机、IAP TCP转发等方式进入内部网络。

如果VM拥有公网IP，则需要确认该IP确实属于目标实例，并检查相关路由和防火墙规则。

可以查看网络接口：

`gcloud compute instances describe INSTANCE_NAME --format="get(networkInterfaces)"`

对于使用内部IP的架构，还需要确认客户端所在网络是否能够访问该内部地址。

这里有一个经常出现的误区：Cloud NAT主要用于让没有公网IP的VM访问互联网，它并不是把互联网SSH请求转发到VM的工具。因此，不能把配置Cloud NAT当成解决公网SSH入站连接的方法。

第五步直接测试TCP 22端口

如果怀疑是网络问题，可以从客户端测试目标端口。

Linux或macOS可以使用：

`nc -zv IP_ADDRESS 22`

Windows PowerShell则可以使用：

`Test-NetConnection IP_ADDRESS -Port 22`

如果TCP 22根本无法建立连接，问题更可能位于公网IP、VPC防火墙、路由或者客户端网络。

如果TCP 22能够连接，但SSH随后提示Permission denied，那么网络层大概率已经正常，应该把注意力转向用户名、密钥、OS Login和Linux账户权限。

这种区分非常重要。它可以避免管理员在网络已经正常的情况下反复修改防火墙。

第六步检查虚拟机内部的SSH服务

如果能够进入串口控制台，或者通过其他管理方式进入VM，就可以直接检查Linux系统。

首先检查SSH服务：

`systemctl status ssh`

部分发行版使用：

`systemctl status sshd`

然后检查22端口是否监听：

`ss -lntp | grep :22`

如果SSH服务没有运行，可以查看服务日志：

`journalctl -u ssh --no-pager`

或者：

`journalctl -u sshd --no-pager`

具体服务名称取决于Linux发行版。

同时检查磁盘空间：

`df -h`

如果根分区已经100%占满，SSH服务、用户登录以及系统中的其他服务都可能出现异常。

第七步检查sshd配置，而不是直接修改它

如果SSH服务启动失败，应检查配置文件语法：

`sshd -t`

如果命令返回错误，再针对具体配置项进行修复。

常见问题包括修改了不存在的配置参数、Include文件出现错误、认证方式配置冲突，以及错误设置了AllowUsers、AllowGroups等访问限制。

如果管理员修改了SSH端口，例如从22改成2222，那么Google Cloud VPC防火墙规则和操作系统内部的SSH监听端口必须保持一致。

不能只修改sshd_config中的端口而忘记云端防火墙，也不能只开放云端22端口而让sshd实际监听2222。

第八步查看SSH详细连接过程

在客户端运行：

`ssh -vvv user@IP_ADDRESS`

可以看到SSH连接从网络建立、密钥交换到用户认证的详细过程。

例如，如果日志显示连接阶段就超时，应该继续检查网络。

如果出现Permission denied，则重点检查用户名、SSH密钥和OS Login。

如果出现Connection refused，则通常意味着目标端口可达，但目标主机没有服务监听该端口，或者相关主机防火墙主动拒绝连接。

如果连接建立后突然断开，则需要继续检查sshd日志、系统资源和认证策略。

第九步利用Google Cloud提供的诊断能力

如果普通SSH连接无法建立，可以考虑使用Google Cloud控制台提供的SSH连接选项以及IAP等管理通道。

对于没有公网IP的VM，IAP TCP转发尤其有价值，因为它可以在不直接暴露SSH端口到互联网的情况下建立管理连接。

如果实例本身无法正常启动，则可以通过串行端口输出检查启动过程：

`gcloud compute instances get-serial-port-output INSTANCE_NAME`

不过串行控制台主要用于处理启动、系统级故障等问题，并不能把它当成查看`/etc/ssh/sshd_config`内容的普通命令。

对于需要长期运维的环境，还可以启用Cloud Logging和相关监控功能，将SSH失败、系统日志和基础设施事件集中起来分析。

SSH故障排查应该形成固定顺序

一个比较实用的排查顺序是：

账号和项目 → IAM和OS Login → VM运行状态 → 公网IP或内部网络 → VPC防火墙 → TCP端口 → sshd服务 → SSH密钥 → Linux用户权限 → 系统日志。

这种顺序的价值在于，每一步都在缩小故障范围。

如果TCP端口无法连接，就没有必要先研究SSH密钥；如果TCP连接正常而出现Permission denied，就没有必要反复修改VPC防火墙；如果sshd服务根本没有监听目标端口，那么继续生成SSH密钥同样没有意义。

Google Cloud SSH登录失败，本质上是一个跨层问题。云平台负责身份、网络和VM基础设施，操作系统负责SSH服务、用户账户和文件权限，而SSH客户端负责完成最终的加密连接与身份认证。只有把这几个层级分开检查，才能快速判断问题到底出在哪里。

对于生产环境，更应该避免通过“开放所有IP”“允许root登录”“重新生成一套密钥”这种简单办法解决问题。正确的做法是找到失败发生的具体层级，然后只修改对应配置。这样不仅能够恢复SSH访问，也能避免为了修复一个登录问题而留下新的安全漏洞。