GCP 开启 SSH 登录

先区分“网络连接失败”与“身份认证失败”。原文记录了 root 密码登录的配置经验，但开启 root 密码并不是所有 GCP SSH 问题的通用修复。

第一阶段：确认连接入口

在 Compute Engine 实例页面 检查实例状态、连接地址、VPC 防火墙及实际 SSH 端口。使用 OS Login 时，还要核对相应 IAM 权限；使用元数据 SSH 密钥时，检查用户名、密钥及项目/实例设置。

可以先尝试控制台的“SSH”按钮或已经配置好的普通用户密钥登录，再通过 sudo 管理系统。浏览器 SSH 也是受认证和连接条件约束的入口，不是绕过故障的“后门”；SSH 服务或相关网络损坏时，它也可能失败，需要按官方恢复流程排查。

第二阶段：检查服务端生效配置

在仍可使用的管理会话中检查：

sudo ss -lntp
sudo sshd -t
sudo sshd -T

查看监听地址、端口，以及 passwordauthentication、permitrootlogin 等实际值。涉及 Match 条件时，还要带上实际连接上下文，例如：

sudo sshd -T -C 'user=root,host=client.example.com,addr=198.51.100.10'

示例域名和地址要改成客户端的实际值。

OpenSSH 对多数配置项采用首先取得的值，但还受 Include 的位置、文件顺序、Match 条件及启动参数影响。01- 文件名只影响相应 include 目录中的排序，不能保证覆盖所有限制。

第三阶段：确实需要 root 密码登录时

先确认这是自己的实例、使用场景允许这种认证，并保留现有管理连接。项目的 OS Login / IAM / 组织策略、PAM 及账号状态不能仅靠一个 sshd 配置文件替代。

在确认当前 Include 会加载的目录中，备份已有配置后编辑专用片段，例如：

sudoedit /etc/ssh/sshd_config.d/01-custom-login.conf

配置内容为：

PasswordAuthentication yes
PermitRootLogin yes

设置密码需要单独执行：

sudo passwd root

这会改变 root 账号密码及后续认证条件。检查实际生效值，而不是假定文件名靠前就一定成功。

先运行 sudo sshd -t。通过后按实际服务名重载；Debian / Ubuntu 常见为：

sudo systemctl reload ssh

其他发行版可能使用 sshd。不要在修改前就关闭当前管理窗口；在第二个终端验证新会话：

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no root@192.0.2.10

替换为实际地址及端口。Permission denied 还可能来自账号、PAM、访问控制和认证组合要求；无法保证上述两项设置适用于所有镜像。

恢复和后续管理

测试结束后，恢复这次修改前记录的配置及认证方式，重新检查并重载，再验证普通用户的密钥登录。仅将 PasswordAuthentication 改回 no 不等于恢复了 PermitRootLogin 的原值；root 密码也不会因此自动恢复为原先的锁定状态。按实际变更逐项核对，避免误锁定正在使用的管理账号。

参考：GCP Linux VM 连接方式、SSH 错误排查。