+86 189 8218 1436 周一至五 10:00-22:00

谷歌GCP云服务器代维护

问题与解决 2026年11月13日

GCP 无法连线 SSH 排查指南

TL;DR：面向小白梳理 GCP 无法连线 SSH 的常见原因、排查顺序、控制台与 gcloud 用法，以及预防断连的运维习惯。

它是什么

「無法連線 SSH」不是一种单独故障，也不是「服务器一定宕机」。更准确地说，是客户端到 VM 的 SSH 通路没走通：默认要连 22 端口，还要身份验证通过，并且 VM 内的 SSH 服务正常接着。门牌找不到、门没开、钥匙不对、屋里没人接，任何一处失败都会连不上；实例显示 RUNNING 只代表机器开着。

在 GCP 里，这条链路包含：项目和外部 IP、项目防火墙、VPC 路由、实例状态、SSH 密钥或账号权限（含 IAM、OS Login），以及 VM 内的 SSH 服务（sshd）。先别急着重启或重装，打开控制台右上角的 Cloud Shell，复制下面只读命令；它们只列信息，不会改配置。这样做是为了先确认「看的是不是同一台 VM」，小白常在多项目、外部 IP 为空、规则属于别的 VPC 上踩坑。

gcloud config get-value project
gcloud compute instances list
gcloud compute firewall-rules list --format="table(name,network,direction,priority,allowed,sourceRanges,targetTags)"

第一条看当前项目；第二条看实例状态、区域和外部 IP；第三条看 allowed 有没有 tcp:22、sourceRanges 是否包含你的来源 IP、规则是否套到正确网络或 targetTags。注意，看到一条放行 22 的规则也不等于一定生效，它可能没绑定到这台 VM。

  • 连接超时：多半是包没到端口，常见是防火墙、路由、没有外部 IP，或公司/家用网络封了 22。
  • 拒绝连接：通常网络到了 VM，但 22 端口没人听，可能是 sshd 没启动、改了端口或系统防火墙拦截。
  • 权限被拒绝：更偏身份问题，如用户名写错、密钥没注入、OS Login/IAM 权限没配好。
  • 浏览器 SSH 卡住：控制台 SSH 也走同一链路，可能与授权、元数据、启动脚本或 VM 内服务有关，不一定是浏览器坏了。

所以这些提示指向不同原因，先分清「卡在哪一段」，后面排错才不会越修越乱。

解决什么问题

这一节先不“修”，而是把「無法連線 SSH」变成能判断的问题。连不上不是一种故障，先拆成四类，避免把重启当万能药：

  • 网络不通：到 VM 外部 IP 都到不了，多为 IP 看错、无外网 IP、路由或地区异常。
  • 端口未放行：机器在跑，但 TCP 22 被 VPC 防火墙、目标标签或优先级挡住。
  • 认证失败：用户名、密钥、OS Login、IAM 权限不对，常见是 Permission denied。
  • 系统内服务异常：sshd 没起、磁盘满、系统防火墙改坏；“运行中”不代表能登录。

这样分，是因为超时、拒绝连接、密码被拒不是同一层问题。重启会冲掉现场，也可能让配置错继续存在。

再看影响范围，范围决定优先级：

  1. 单台 VM：查状态、外部 IP、串行日志。
  2. 某个账号：查 IAM、OS Login、项目级 SSH 密钥、本地用户名。
  3. 某个地区多台：查该地区网络、共享 VPC、路由和云状态。
  4. 整个项目：查项目、配额、组织策略、防火墙批量变更，别逐台乱改。

常见坑是没证据就反复试密码，或把防火墙改成 0.0.0.0/0 全端口；前者可能触发锁定，后者扩大风险。先在控制台只看不改：Compute Engine → VM 实例，记状态、区域、外部 IP；VPC 网络 → 防火墙，看是否有允许 TCP 22 的入站规则；日志浏览器和串行端口日志，看启动、sshd、登录失败。

也可打开控制台右上角 Cloud Shell，复制下面命令保存输出；不用替换参数，可确认账号、项目、实例和防火墙现状：

gcloud auth list
gcloud config list
gcloud projects list
gcloud compute instances list
gcloud compute project-info describe
gcloud compute firewall-rules list

若提示未设置项目，先回控制台确认项目名，别随便选。证据齐了，后面只验证一层：到不到 IP、到不到 22、账号过不过、sshd 活不活，能少走弯路，也少误改防火墙。

怎么上手

遇到「无法连线 SSH」（搜索里也常写成「無法連線 SSH」）先别急着重装，按下面四步走，基本都能找到原因。顺序很重要：先确认机器自己没问题，再怪网络，最后才查账号。

  1. 先看 VM 活没活。进 GCP 控制台 → Compute Engine → 虚拟机实例，状态要是 RUNNING；再点「监控」看 CPU，如果长期贴着 100%，sshd 根本排不上队，表现很像超时。顺手打开「日志 / 串行端口输出」看启动阶段有没有报错。命令整段复制，只改前两行，别删引号：

    VM="my-vm"
ZONE="asia-east1-b"
gcloud compute instances describe "$VM" --zone="$ZONE" 
  --format="value(status)"
gcloud compute instances get-serial-port-output "$VM" --zone="$ZONE" 
  | tail -n 50

    小白常踩的坑：ZONE 要写 asia-east1-b 这种带后缀的，不是只写 asia-east1；实例名也不是项目名。日志里出现磁盘满、挂载失败、SSH 服务没起来，就先别动防火墙了。

  2. 再看门开没开。防火墙要允许「你当前的公网 IP」访问 TCP 22。填的是宽带公网地址，不是电脑上的 192.168 开头内网地址；家里宽带重拨后 IP 会变，所以昨天能连今天不一定。用 IAP 时改成放行 35.235.240.0/20，并给账号加「IAP-secured Tunnel User」权限：

    gcloud compute firewall-rules list 
  --format="table(name,sourceRanges,allowed)"
gcloud projects get-iam-policy "$(gcloud config get-value project)" 
  --flatten="bindings[].members" 
  --filter="bindings.role:roles/iap.tunnelResourceAccessor" 
  --format="table(bindings.role,bindings.members)"

    坑：用了 IAP 却还在放行自己家 IP，或者顺手把 22 开给 0.0.0.0/0，既不安全也可能被优先级更高的拒绝规则盖掉。

  3. 试着连一次，看它怎么拒绝你。控制台实例列表点「SSH」→「在浏览器窗口中打开」，或者用命令：

    VM="my-vm"
ZONE="asia-east1-b"
gcloud compute ssh "$VM" --zone="$ZONE"

    一直转圈、报超时，回第 2 步；报 Connection refused，说明机器通了但 22 没人听，去第 4 步；报 Permission denied (publickey)，说明网络和端口都是好的，是用户名或密钥不对，这时候再改防火墙就是白忙活。另一个坑：浏览器 SSH 和 gcloud 用的不是同一把本地密钥，一个能连一个不能连很正常，用户名也不一定叫 root。

  4. 最后进串口看系统内部。控制台勾选「启用连接到串行端口」再进去，也可以先拉日志：

    VM="my-vm"
ZONE="asia-east1-b"
gcloud compute instances get-serial-port-output "$VM" --zone="$ZONE" 
  | grep -Ei "ssh|sshd|no space|failed" | tail -n 30

    能进串口会话后，直接复制这段：

    sudo systemctl status ssh || sudo systemctl status sshd
df -h
ls -ld "$HOME" "$HOME/.ssh" "$HOME/.ssh/authorized_keys"

    为什么查这三样：不同系统服务名可能是 ssh 或 sshd，所以写了二选一；磁盘用到 100% 会连上就断；家目录别是 777，.ssh 建议 700、authorized_keys 建议 600，而且属主得是本人。只补了密钥内容却没改属主，还是会一直报权限被拒绝。

与替代方案对比

遇到無法連線 SSH，别反复点「连接」，也别一上来把防火墙全网开放。替代方案不是谁更好，而是用途不同：救急、日常登录、团队协作、排障。先在控制台右上角打开 Cloud Shell，复制下面几行，确认工具、账号和密钥目录；它们不碰云服务器，只排除「没工具、没登录」这种假故障。

gcloud --version
gcloud auth list
ssh -V
mkdir -p ~/.ssh; ls -la ~/.ssh

为什么先查？浏览器 SSH、IAP、串口都要控制台权限，本地 SSH 还要私钥。如果复制到自己电脑后看到 command not found，就换 Cloud Shell 或装 SDK；账号列表没有 ACTIVE，网页按钮常会转圈；密钥目录空，多半是换了环境或没上传私钥，不是实例坏了。

  • 浏览器 SSH：最省事，点一下就开窗口，适合临时救急。原因是 GCP 帮你临时建连接；但依赖控制台权限和 GCP 连接服务。坑：只有查看权限、组织策略拦截或服务异常时，容易误以为机器关机。
  • 本地 SSH 加固定密钥：可控性高，适合日常登录。原因是公钥固定、私钥自己保管；代价是要管理密钥、来源 IP 和防火墙。坑：私钥发群里、只放在 Cloud Shell 没带回本机、换网络后 IP 变了、22 没放行，却以为密码错。
  • IAP 隧道：不必公开 22 端口，安全性更好，适合团队环境。原因是流量先过 Identity-Aware Proxy 再进实例；但初始权限配置略复杂，要有隧道权限、登录权限，防火墙也要允许 IAP 转发网段。
  • 串口控制台：适合 SSH 服务坏掉或网络配置错误时看日志、改配置。原因是它不依赖 sshd 和正常网卡；但慢、复制粘贴差，不是完整 SSH，别当日常远程终端。

一句话：临时救急用浏览器 SSH，稳定办公用固定密钥，多人协作优先 IAP，服务起不来再看串口。比把 22 开给 0.0.0.0/0 安全得多。

最佳实践

常见问题（FAQ）

GCP 无法连线 SSH 时先重启 VM 吗？

不建议先重启。先看实例状态、防火墙和日志，重启可能掩盖根因。

浏览器 SSH 也打不开怎么办？

多半是实例、权限或系统内服务异常，可用串口控制台看启动日志。

开放 22 端口给所有人可以吗？

不建议。只放行可信来源 IP，或用 IAP 隧道减少暴露面。

为什么密码对了仍提示权限被拒绝？

常见原因是用户名、密钥、目录权限或项目账号权限不匹配。

不想自己折腾 GCP？我们提供云平台代维护、上云迁移与账单代付服务，一对一技术支持。

查看代维服务 →

发表评论