Google Cloud VM SSH 没有支持的身份验证方法可用

Question

我有一个使用 Debian 操作系统的 Google 云虚拟机实例。我已经托管了 Wordpress 网站。升级操作系统版本后一切正常，我可以使用“在浏览器中打开 SSH”选项通过 SSH 连接。

现在我尝试使用“在浏览器中打开 SSH”连接我的虚拟机实例，它只是不断重试。我检查了串行控制台输出，但没有错误消息。请参考以下

但是，我可以使用相同的密钥通过 FTP 进行连接，但是当我尝试通过 SSH 连接时遇到了问题。我检查了该实例和项目的端口 22，它是打开的

以下是我重新启动虚拟机后串行控制台日志的最后几行，

Dec  6 09:01:20 localhost sendmail[383]: Starting Mail Transport Agent (MTA): sendmail.
Dec  6 09:01:20 localhost systemd[1]: Started LSB: powerful, efficient, and scalable Mail Transport Agent.
Dec  6 09:01:21 localhost systemd[1]: Started MariaDB 10.3.31 database server.
Dec  6 09:01:21 localhost systemd[1]: Reached target Multi-User System.
Dec  6 09:01:21 localhost systemd[1]: Reached target Graphical InterfacDec  6 09:01:21 localhost systemd[1]: Startup finished in 4.063s (kernel) + 9.852s (userspace) = 13.915s.
Dec  6 09:01:21 localhost /etc/mysql/debian-start[567]: Upgrading MySQL tables if necessary.
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: Looking for 'mysql' as: /usr/bin/mysql
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: Version check failed. Got the following error when calling the 'mysql' command line client
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: FATAL ERROR: Upgrade failed
Dec  6 09:01:21 localhost /etc/mysql/debian-start[580]: Checking for insecure root accounts.
Dec  6 09:01:21 localhost debian-start[564]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Debian GNU/Linux 10 localhost ttyS0

localhost login: Dec  6 09:01:28 localhost systemd[1]: Stopping User Manager for UID 110...
Dec  6 09:01:28 localhost systemd[497]: Stopped target Default.
Dec  6 09:01:28 localhost systemd[497]: Stopped target Basic System.
Dec  6 09:01:28 localhost systemd[497]: Stopped target Timers.
Dec  6 09:01:28 localhost systemd[497]: Stopped target Paths.
Dec  6 09:01:28 localhost systemd[497]: Stopped target Sockets.
Dec  6 09:01:28 localhost systemd[497]: gpg-agent-browser.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Dec  6 09:01:28 localhost systemd[497]: dirmngr.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG network certificate management daemon.
Dec  6 09:01:28 localhost systemd[497]: gpg-agent-ssh.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Dec  6 09:01:28 localhost systemd[497]: gpg-agent.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache.
Dec  6 09:01:28 localhost systemd[497]: gpg-agent-extra.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Dec  6 09:01:28 localhost systemd[497]: Reached target Shutdown.
Dec  6 09:01:28 localhost systemd[497]: systemd-exit.service: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Started Exit the Session.
Dec  6 09:01:28 localhost systemd[497]: Reached target Exit the Session.
Dec  6 09:01:28 localhost systemd[1]: user@110.service: Succeeded.
Dec  6 09:01:28 localhost systemd[1]: Stopped User Manager for UID 110.
Dec  6 09:01:28 localhost systemd[1]: Stopping User Runtime Directory /run/user/110...
Dec  6 09:01:28 localhost systemd[1]: run-user-110.mount: Succeeded.
Dec  6 09:01:28 localhost systemd[1]: user-runtime-dir@110.service: Succeeded.
Dec  6 09:01:28 localhost systemd[1]: Stopped User Runtime Directory /run/user/110.
Dec  6 09:01:28 localhost systemd[1]: Removed slice User Slice of UID 110.

尝试了我从谷歌搜索获得的以下解决方案

解决方案 1：使用 PuTTYGen 和 Putty

使用 PuttyGen 生成密钥并将公钥放在元数据下，并尝试在实例下添加。我已将enable-oslogin 设置为FALSE。 但收到以下错误消息。

解决方案 2：使用串行端口

当我尝试使用差异串行端口进行连接时，它只是在连接屏幕上堆叠，我检查了该串行端口的控制台日志，但它是空白的。

解决方案 3：带有磁盘映像的新实例

创建当前磁盘的映像，然后使用该映像创建新实例。当我尝试连接到那个新实例时，我遇到了同样的问题。

解决方案 4：使用 diff 机器设置 CLI

我在新机器上设置了新的 Google Cloud CLI 并尝试连接但没有成功。我遇到了同样的错误。

解决方案 5：增加磁盘空间

将磁盘空间从 20GB 增加到 35GB，但没有用。通常如果存在磁盘空间错误，我们会将其写入串行控制台日志。但就我而言，串行控制台日志中没有错误消息。

如果需要任何其他信息，请提供帮助并告诉我。 谢谢

Answer 1

在浏览器中启动 SSH 时，请遵循一些故障排除步骤：

1. 等待几分钟，然后重试。有可能：

• 实例尚未完成启动。

• SSH 密钥的元数据尚未完成传播到
  项目或实例。

• Google 代理尚未读取 SSH 密钥元数据

1. 验证对实例的 SSH 访问没有被防火墙阻止。

2. 确保根卷没有超出磁盘空间。

3. 验证尝试 SSH 的用户是否拥有 compute 实例 管理员角色或服务帐户用户角色（如果设置了实例 最多作为服务帐户运行）。这些角色需要更新 实例或项目的 SSH 密钥元数据。

4. 验证是否为以下任一设备设置了临时 SSH 密钥元数据 项目或实例。

5. 验证 Linux Google Agent 脚本是否已安装并且 正在运行。如果未安装 Linux Google Agent，请重新安装。

6. 验证 google-guest-agent.service 已启用并启动。这些可能 需要在串口控制台中执行。

          systemctl status google-guest-agent.service
   

如果服务被禁用，启用并启动服务

   systemctl enable google-guest-agent.service
   systemctl start google-guest-agent.service

8.验证是否存在通往 Internet（或 堡垒主机）。

某些网络配置可能会阻止SSH from the browser 正常工作。如果 HTTPS 代理或安全设备干扰发送到 Google API 和服务的流量，来自浏览器的 SSH 可能无法正常工作。如果来自浏览器的 SSH 不起作用，请检查使用来自浏览器的 SSH 的系统使用的网络是否满足以下要求：

• HTTPS 代理和安全设备不得解密和重新加密 使用自己的 TLS 证书的流量，例如，执行 TLS 检查。
• 系统的网络必须允许进出主机名的流量 在 google.com、gstatic.com 或 googleapis.com 中。
• 系统的网络必须允许将数据包发送到 IP 默认域的地址。

查看doc 以了解 ssh 故障排除。

#6。请查看以下文档安装Linux Guest Agent。

#8 检查路线：

SSH 需要一种在连接上进行回传的方法。有时出于安全考虑，默认的 Internet 路由会被删除，或者以其他方式错误地配置它，从而拒绝从受影响的机器输出。

• 先查看VPC Network > Routes，然后按VPC网络过滤 由实例使用。

• system-generated default route 有一个描述“默认路由 到 Internet。”，目的地为 0.0.0.0/0，优先级为 1000 和 “默认互联网网关”作为下一跳。

• 如果您使用的是堡垒主机，那么应该有一条路线 到同一网络中的堡垒主机。验证是否存在 连接使用例如telnet [host-ip] 22（假设 SSH 在 [host-ip] 在端口 22 上运行）。这应该与 SSH 一起呈现 横幅。 （按 Ctrl+] 然后退出退出 telnet。）

• 您还可以使用 gcloud 工具列出路线。例如

  gcloud 计算路由列表 --filter="network="| grep "默认互联网网关"