本文档有助于排查 Google Distributed Cloud Virtual for VMware 中的身份验证问题。其中提供了常规问题排查信息和指南，以及 OpenID Connect (OIDC) 和轻量级目录访问协议 (LDAP) 的特定信息。
OIDC 和 LDAP 身份验证使用 GKE Identity Service。您必须先配置身份提供方，然后才能将 GKE Identity Service 与 Google Distributed Cloud Virtual for VMware 搭配使用。如果您尚未为 GKE Identity Service 配置身份提供方，请按照以下较常见的提供方之一的说明操作：
请参阅 GKE Identity Service 身份提供方问题排查指南，了解如何启用和查看身份日志并测试连接。
如果您需要其他帮助，请与 Cloud Customer Care 联系。常规问题排查
以下问题排查提示有助于解决 Google Distributed Cloud Virtual for VMware 的常规身份验证和授权问题。如果这些问题不适用或您存在 OIDC 或 LDAP 问题，请继续阅读关于 GKE Identity Service 问题排查的部分。
及时更新 gcloud anthos auth
您可以通过验证 gcloud anthos auth 安装的组件处于最新状态，以避免许多常见问题。
有两个部分必须验证。gcloud anthos auth 命令的逻辑存在于 Google Cloud CLI 核心组件以及独立封装的 anthos-auth 组件中。
如需更新 Google Cloud CLI，请运行以下命令：
gcloud components update如需更新
anthos-auth组件，请运行以下命令：gcloud components install anthos-auth
提供商配置无效
如果您的身份提供方配置无效，点击登录后，身份提供方将显示错误屏幕。按照特定于提供方的说明正确配置提供方或您的集群。
配置无效
如果 Google Cloud 控制台无法从集群中读取 OIDC 配置，则登录按钮处于停用状态。如需排查集群 OIDC 配置问题，请参阅本文档中的以下排查 OIDC 问题部分。
权限无效
如果您完成了身份验证流程，但仍看不到集群的详细信息，请确保您已向与 OIDC 搭配使用的账号授予了正确的 RBAC 权限。此账号可能与您用于访问 Google Cloud 控制台的账号不同。
缺少刷新令牌
如果授权服务器提示是否同意，但未提供所需的身份验证参数，就会出现以下问题。
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
要解决此问题，请在 ClientConfig 资源中将 prompt=consent 添加到 authentication.oidc.extraParams 字段。然后重新生成客户端身份验证文件。
刷新令牌已过期
当 kubeconfig 文件中的刷新令牌过期时，会出现以下问题：
Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
certificate signed by unknown authority
如需解决此问题，请再次运行 gcloud anthos auth login 命令。
gcloud anthos auth login 失败并显示 proxyconnect tcp
如果 https_proxy 或 HTTPS_PROXY 环境变量配置出错，就会出现此问题。如果环境变量中指定了 https://，则当代理配置为使用其他协议（如 SOCK5）来处理 HTTPS 连接时，GoLang HTTP 客户端库可能会失败。
可能会返回以下示例错误消息：
proxyconnect tcp: tls: first record does not look like a TLS handshake
如需解决此问题，请修改 https_proxy 和 HTTPS_PROXY 环境变量以省略 https:// prefix。在 Windows 上，修改系统环境变量。例如，将 https_proxy 环境变量的值从 https://webproxy.example.com:8000 更改为 webproxy.example.com:8000。
使用 gcloud anthos auth login 生成的 kubeconfig 时集群访问失败
当 Kubernetes API 服务器无法向用户授权时，就会出现此问题。如果相应的 RBAC 不存在或错误，或者集群的 OIDC 配置存在错误，就可能发生这种情况。系统可能会显示以下示例错误：
Unauthorized
如需解决此问题，请完成以下步骤：
在
gcloud anthos auth login生成的 kubeconfig 文件中，复制id-token的值。kind: Config ... users: - name: ... user: auth-provider: config: id-token: xxxxyyyy安装 jwt-cli 并运行以下命令：
jwt ID_TOKEN验证 OIDC 配置。
ClientConfig资源具有group和username字段。这些字段用于在 Kubernetes API 服务器中设置--oidc-group-claim和--oidc-username-claim标志。当 API 服务器收到令牌时，会将令牌转发到 GKE Identity Service，后者随后会将提取的group-claim和username-claim返回给 API 服务器。API 服务器使用响应来验证对应的组或用户具有正确的权限。验证 ID 令牌中包含
ClientConfig资源中为group和user设置的声明。检查已应用的 RBAC。
针对上一步由
username-claim指定的用户或者group-claim中列出的某个群组，验证是否存在具有正确权限的 RBAC。RBAC 中用户或群组的名称应该带有ClientConfig资源中指定的usernameprefix或groupprefix前缀。如果
usernameprefix为空，并且username的值不是email，则前缀默认为issuerurl#。要停用用户名前缀，请将usernameprefix设置为-。如需详细了解用户和群组前缀，请参阅使用 OIDC 进行身份验证。
ClientConfig资源：oidc: ... username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:"ID 令牌：
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\cluster-developer", "group": [ "Domain Users", "EXAMPLE\developers" ], ... }以下 RBAC 绑定会向此群组和用户授予
pod-reader集群角色。请注意名称字段中应包含单斜杠，而不是双斜杠：群组 ClusterRoleBinding：
apiVersion: kind: ClusterRoleBinding metadata: name: example-binding subjects: - kind: Group name: "oidc:EXAMPLE\developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io用户 ClusterRoleBinding：
apiVersion: kind: ClusterRoleBinding metadata: name: example-binding subjects: - kind: User name: "EXAMPLE\cluster-developer" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io检查 Kubernetes API 服务器日志。
如果 Kubernetes API 服务器中配置的 OIDC 插件未正确启动，则 API 服务器会在收到 ID 令牌时返回
Unauthorized错误。如需检查 API 服务器中的 OIDC 插件是否存在任何问题，请运行以下命令：kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG替换以下内容：
USER_CLUSTER_NAME：要查看其日志的用户集群的名称。ADMIN_CLUSTER_KUBECONFIG：管理员集群 kubeconfig 文件。
gkectl create-login-config 无法获取 clientconfig
如果传递到 gkectl create-login-config 的 kubeconfig 文件不适用于用户集群，或者 ClientConfig 资源在集群创建过程中未出现，则会出现此问题。
Error getting clientconfig using KUBECONFIG
要解决此问题，请确保用户集群具有正确的 kubeconfig 文件。然后检查 ClientConfig 资源是否在集群中：
kubectl get clientconfig default -n kube-public \
--kubeconfig USER_CLUSTER_KUBECONFIG
将 USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。
gkectl create-login-config 由于集群名称重复而失败
如果您尝试写入包含目标文件中已存在的集群名称的登录配置数据，则会出现此问题。每个登录配置文件都必须包含唯一的集群名称。
error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
the same name as the one read from KUBECONFIG. Please write to a new
output file
如需解决此问题，请使用 --output 标志指定新的目标文件。
如果您未提供 --output，此登录配置数据会写入当前目录中名为 kubectl-anthos-config.yaml 的文件。
排查 OIDC 问题
如果 OIDC 身份验证不适用于 Google Distributed Cloud Virtual for VMware，通常 ClientConfig 资源中的 OIDC 规范未正确配置。ClientConfig 资源介绍如何查看日志和 OIDC 规范，以帮助确定 OIDC 问题的原因。
请参阅 GKE Identity Service 身份提供方问题排查指南，了解如何启用和查看身份日志并测试连接。在您确认 GKE Identity Service 按预期运行或识别问题后，请查看以下 OIDC 问题排查信息。
检查集群中的 OIDC 规范
集群的 OIDC 信息在 kube-public 命名空间中的 ClientConfig 资源中指定。
使用
kubectl get输出用户集群的 OIDC 资源：kubectl --kubeconfig KUBECONFIG -n kube-public get \ clientconfig.authentication.gke.io default -o yaml将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。查看字段值，以确认已为您的 OIDC 提供方正确地配置了规范。
如果您在规范中发现配置问题，请重新配置 OIDC。
如果您无法自行诊断和解决问题，请与 Google Cloud 支持团队联系。
Google Cloud 支持团队需要查看 GKE Identity Service 日志和 OIDC 规范，以诊断和解决 OIDC 问题。
验证是否已启用 OIDC 身份验证
在测试 OIDC 身份验证之前，请验证是否已在集群中启用 OIDC 身份验证。
检查 GKE Identity Service 日志：
kubectl logs -l k8s-app=ais -n anthos-identity-service以下示例输出显示 OIDC 身份验证已正确启用：
... I1011 22:14:21.684580 33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started. ...如果 OIDC 身份验证未正确启用，则会显示如下错误示例：
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:查看报告的具体错误并尝试改正。
测试 OIDC 身份验证
如需使用 OIDC 功能，请使用启用了界面和浏览器的工作站。您无法从基于文本的 SSH 会话执行这些步骤。如需测试 OIDC 在您的集群中是否正常运行，请完成以下步骤：
- 下载 Google Cloud CLI。
如需生成登录配置文件，请运行以下
gcloud anthos create-login-config命令：gcloud anthos create-login-config \ --output user-login-config.yaml \ --kubeconfig KUBECONFIG将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。如需对用户进行身份验证，请运行以下命令：
gcloud anthos auth login --cluster CLUSTER_NAME \ --login-config user-login-config.yaml \ --kubeconfig AUTH_KUBECONFIG替换以下内容：
- 将 CLUSTER_NAME 替换为要连接到的用户集群的名称。
- 将 AUTH_KUBECONFIG 替换为要创建的新 kubeconfig 文件，其中包含用于访问集群的凭据。如需了解详情，请参阅向集群进行身份验证。
您应该会收到在本地工作站的默认网络浏览器中打开的登录同意页面。在登录提示中提供用户的有效身份验证信息。
成功完成上一个登录步骤后，当前目录中会生成一个 kubeconfig 文件。
如需测试包含凭据的新 kubeconfig 文件，请列出用户集群中的 Pod：
kubectl get pods --kubeconfig AUTH_KUBECONFIG将 AUTH_KUBECONFIG 替换为上一步中生成的新 kubeconfig 文件的路径。
以下示例消息可能会返回，显示您可以成功进行身份验证，但未为该账号分配基于角色的访问权限控制 (RBAC)：
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
查看 OIDC 身份验证日志
如果您无法通过 OIDC 进行身份验证，则 GKE Identity Service 日志可以提供最相关、最有用的问题调试信息。
使用
kubectl logs输出 GKE Identity Service 日志：kubectl --kubeconfig KUBECONFIG \ -n anthos-identity-service logs \ deployment/ais --all-containers=true将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。查看日志中是否有错误可帮助您诊断 OIDC 问题。
例如，
ClientConfig资源在issuerURL字段中可能有拼写错误，例如htps://accounts.google.com（https中缺少t）。GKE Identity Service 日志会包含类似于以下示例的条目：OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.如果您在日志中发现配置问题，请重新配置 OIDC 并更正配置问题。
如果您无法自行诊断和解决问题，请与 Google Cloud 支持团队联系。Google Cloud 支持团队需要查看 GKE Identity Service 日志和 OIDC 规范，以诊断和解决 OIDC 问题。
常见的 OIDC 问题
如果您在进行 OIDC 身份验证时遇到问题，请查看以下常见问题。请按照有关如何解决问题的任何指导进行操作。
没有可用于服务“ais”的端点
保存 ClientConfig 资源时，系统会返回以下错误消息：
Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
no endpoints available for service "ais"
此错误是由健康状况不佳的 GKE Identity Service 端点引起的。GKE Identity Service Pod 无法响应验证 webhook。
如需确认 GKE Identity Service Pod 健康状况不佳，请运行以下命令：
kubectl get pods -n anthos-identity-service \ --kubeconfig KUBECONFIG将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。以下示例输出意味着您的 GKE Identity Service Pod 崩溃：
NAME READY STATUS RESTARTS AGE ais-5949d879cd-flv9w 0/1 ImagePullBackOff 0 7m14s如需了解 Pod 出现问题的原因，请查看 Pod 事件：
kubectl describe pod -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。以下示例输出报告的是在拉取映像时的权限错误：
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 10m default-scheduler Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5 Normal Pulling 8m23s (x4 over 10m) kubelet Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00" Warning Failed 8m21s (x4 over 10m) kubelet Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized Warning Failed 8m21s (x4 over 10m) kubelet Error: ErrImagePull Warning Failed 8m10s (x6 over 9m59s) kubelet Error: ImagePullBackOff Normal BackOff 4m49s (x21 over 9m59s) kubelet Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"如果 Pod 事件报告问题，请在受影响的范围内继续排查问题。如需额外帮助，请与 Google Cloud 支持团队联系。
从服务器读取响应字节失败
您可能会在 GKE Identity Service 日志中看到以下错误：
E0516 07:24:38.314681 65 oidc_client.cc:207] Failed fetching the Discovery URI
"https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
Failed reading response bytes from server.
E0516 08:24:38.446504 65 oidc_client.cc:223] Failed to fetch the JWKs URI
"https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
Failed reading response bytes from server.
这些网络连接错误在日志中的出现方式可能会是：
稀疏地出现在日志中：稀疏错误可能不是主要问题，并且可能是间歇性网络问题。
GKE Identity Service OIDC 插件具有守护进程，每 5 秒定期同步 OIDC 发现网址。如果网络连接不稳定，则此出站流量请求可能会失败。偶发故障不会影响 OIDC 身份验证。现有的缓存数据可以重复使用。
如果您在日志中遇到稀疏的错误，请继续按照其他问题排查步骤进行操作。
不断出现在日志中，或者 GKE Identity Service 未成功到达已知端点：这些常见问题表示 GKE Identity Service 与您的 OIDC 身份提供方之间的连接有问题。
以下问题排查步骤可帮助诊断这些连接问题：
- 确保防火墙不会阻止来自 GKE Identity Service 的出站请求。
- 检查身份提供方服务器是否正常运行。
- 验证
ClientConfig资源中的 OIDC 颁发者网址是否配置正确。 - 如果您在
ClientConfig资源中启用了代理字段，请查看出站代理服务器的状态或日志。 - 测试 GKE Identity Service Pod 与 OIDC 身份提供方服务器之间的连接。
您必须登录服务器（未经授权）
尝试使用 OIDC 身份验证登录时，您可能会收到以下错误消息：
You must be logged in to the server (Unauthorized)
这是一个常见的 Kubernetes 身份验证问题，不会提供任何其他信息。但是，此错误确实表示存在配置问题。
如需确定此问题，请查看前面的部分以检查集群中的 OIDC 规范并配置 ClientConfig 资源。
未能发出 webhook 身份验证器请求
在 GKE Identity Service 日志中，您可能会看到以下错误：
E0810 09:58:02.820573 1 webhook.go:127] Failed to make webhook authenticator request:
error trying to reach service: net/http: TLS handshake timeout
此错误表示 API 服务器无法与 GKE Identity Service Pod 建立连接。
如需验证是否可以从外部访问 GKE Identity Service 端点，请运行以下
curl命令：curl -k -s -o /dev/null -w "%{http_code}" -X POST \ https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'将
APISERVER_HOST替换为您的 API 服务器的地址。预期响应为
HTTP 400状态代码。如果请求超时，请重启 GKE Identity Service Pod。如果错误仍然存在，则表示 GKE Identity Service HTTP 服务器无法启动。如需更多帮助，请与 Google Cloud 支持团队联系。
未找到登录网址
如果 Google Cloud 控制台无法访问身份提供方，就会出现以下问题。尝试登录时，被重定向到包含 URL not found 错误的页面。
如需解决此问题，请查看以下问题排查步骤。每完成一个步骤后，请再次尝试登录：
如果无法通过公共互联网访问身份提供方，请启用 OIDC HTTP 代理，以使用 Google Cloud 控制台登录。修改
ClientConfig自定义资源并将useHTTPProxy设置为true：kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG将
USER_CLUSTER_KUBECONFIG替换为您的用户集群 kubeconfig 文件的路径。如果 HTTP 代理已启用，但您仍然遇到此错误，则可能是代理启动存在问题。查看代理的日志：
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG将
USER_CLUSTER_KUBECONFIG替换为您的用户集群 kubeconfig 文件的路径。即使您的身份提供方具有众所周知的 CA，您也必须在
ClientConfig自定义资源中为oidc.caPath提供一个值，这样 HTTP 代理才能成功启动。如果授权服务器提示是否同意，并且您未添加
extraparamprompt=consent参数，请修改ClientConfig自定义资源，并将prompt=consent添加到extraparams参数：kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG将
USER_CLUSTER_KUBECONFIG替换为您的用户集群 kubeconfig 文件的路径。如果存储服务的配置设置发生更改，您可能需要明确退出现有会话。在 Google Cloud 控制台中，转到集群详情页面，然后选择退出登录。
排查 LDAP 问题
如果您在进行 LDAP 身份验证时遇到问题，请确保已按照相应的配置文档之一设置环境：
您还需要确保填充 LDAP 服务账号密钥，并且配置了用于启用 LDAP 身份验证的 ClientConfig 资源。
请参阅 GKE Identity Service 身份提供方问题排查指南，了解如何启用和查看身份日志并测试连接。在您确认 GKE Identity Service 按预期工作或识别问题后，请查看以下 LDAP 问题排查信息。
验证 LDAP 身份验证已启用
在测试 LDAP 身份验证之前，请验证是否已在集群中启用 LDAP 身份验证。
检查 GKE Identity Service 日志：
kubectl logs -l k8s-app=ais -n anthos-identity-service以下示例输出显示 LDAP 身份验证已正确启用：
... I1012 00:14:11.282107 34 plugin_list.h:139] LDAP[0] started. ...如果未正确启用 LDAP 身份验证，则会显示类似如下的错误示例：
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:查看报告的具体错误并尝试改正。
测试 LDAP 身份验证
如需使用 LDAP 功能，请使用启用了界面和浏览器的工作站。您无法从基于文本的 SSH 会话执行这些步骤。如需测试 LDAP 身份验证在您的集群中是否正常运行，请完成以下步骤：
- 下载 Google Cloud CLI。
如需生成登录配置文件，请运行以下 gcloud anthos create-login-config 命令：
gcloud anthos create-login-config \ --output user-login-config.yaml \ --kubeconfig KUBECONFIG将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。如需对用户进行身份验证，请运行以下命令：
gcloud anthos auth login --cluster CLUSTER_NAME \ --login-config user-login-config.yaml \ --kubeconfig AUTH_KUBECONFIG替换以下内容：
- 将
CLUSTER_NAME替换为要连接到的用户集群的名称。 - 将
AUTH_KUBECONFIG替换为要创建的新 kubeconfig 文件，其中包含用于访问集群的凭据。如需了解详情，请参阅向集群进行身份验证。
- 将
您应该会收到在本地工作站的默认网络浏览器中打开的登录同意页面。在登录提示中提供用户的有效身份验证信息。
成功完成上一个登录步骤后，当前目录中会生成一个 kubeconfig 文件。
如需测试包含凭据的新 kubeconfig 文件，请列出用户集群中的 Pod：
kubectl get pods --kubeconfig AUTH_KUBECONFIG将 AUTH_KUBECONFIG 替换为上一步中生成的用户集群 kubeconfig 的路径。
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
常见 LDAP 问题
如果您在进行 LDAP 身份验证时遇到问题，请查看以下常见问题。请按照有关如何解决问题的任何指导进行操作。
用户的 CN 包含英文逗号，无法进行身份验证
使用 LDAP 时，如果用户的 CN 包含英文逗号（例如 CN="a,b"），则可能无法进行身份验证。如果您为 GKE Identity Service 启用了调试日志，则系统会报告以下错误消息：
I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
Encountered the following error: Empty entries.
出现此问题的原因是 GKE Identity Service LDAP 插件对英文逗号进行双重转义。此问题仅在 Google Distributed Cloud Virtual for VMware 1.13 及更低版本中发生。
如需解决此问题，请完成以下步骤之一：
- 将集群升级到 Google Distributed Cloud Virtual for VMware 1.13 或更高版本。
- 选择其他
identifierAttribute（例如sAMAccountName），而不要使用 CN。 - 从 LDAP 目录中的 CN 中移除英文逗号。
Google Cloud CLI 1.4.2 身份验证失败
如果使用 Google Cloud CLI anthos-auth 1.4.2，您在运行 gcloud anthos auth login 命令时可能会看到以下错误消息：
Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
ERROR: Configuring Anthos authentication failed
在 GKE Identity Service 日志中，您还会看到以下错误：
I0728 12:43:01.980012 26 authentication_plugin.cc:79] Stopping STS authentication, unable to decrypt the STS token:
Decryption failed, no keys in the current key set could decrypt the payload.
要解决此错误，请完成以下步骤：
检查您使用的是否为 Google Cloud CLI
anthos-auth1.4.2 版：gcloud anthos auth version以下示例输出显示版本为 1.4.2：
Current Version: v1.4.2如果您运行的是 Google Cloud CLI
anthos-auth1.4.2 版，请升级到 1.4.3 版或更高版本。
常见问题
本部分详细介绍了常见的身份验证问题以及解决方法。
由于 SSH 密钥 permission denied 错误，无法访问管理员工作站
当您尝试连接到管理员工作站并收到类似于以下示例的 "Permission denied" 消息时，会发生以下错误：
Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).
发生此错误的原因是，在使用 SSH 连接到管理员工作站时，使用的私钥有误或无密钥。
如需解决此问题，请找到并使用正确的 SSH 密钥。如果找不到正确的 SSH 密钥，请按照以下步骤为管理员工作站生成新的 SSH 密钥对：
创建临时救援虚拟机。此救援虚拟机必须与当前管理员工作站虚拟机连接到同一网络和 Datastore。
关闭管理员工作站虚拟机和救援虚拟机。
将管理员工作站虚拟机的数据磁盘挂接到救援虚拟机。数据磁盘通常为 512 MB，除非您在管理员工作站配置文件中指定了其他磁盘大小（与启动磁盘不同）。
开启救援虚拟机。
使用 SSH 连接到救援虚拟机。
在本地计算机上，生成新的 SSH 密钥对。
在本地计算机上，使用
ssh-copy-id命令将新的 SSH 公钥复制到救援虚拟机：ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM替换以下内容：
- 将
NEW_SSH_KEY替换为您在上一步中创建的新 SSH 密钥的名称。 - 将
RESCUE_VM替换为您的救援虚拟机的 IP 地址或 FQDN。
- 将
在救援虚拟机上，将数据磁盘装载到救援虚拟机上：
sudo mkdir -p /mnt/ext-disk sudo mount DEVICE /mnt/ext-disk将
DEVICE替换为您自己的磁盘的唯一标识符，例如/dev/sdb1。在救援虚拟机上，将新的 SSH 公钥复制到管理员工作站虚拟机已装载的数据磁盘上的
authorized_keys文件中。查看救援虚拟机上
authorized_keys文件的内容，其中包括在上一步中使用ssh-copy-id命令复制的新 SSH 公钥：ls ~/.ssh/authorized_keys从
authorized_keys文件中复制最后一个 SSH 公钥条目，然后关闭该文件。通过管理员工作站虚拟机修改已装载的数据磁盘上的
authorized_keys文件：vi /mnt/ext-disk/.ssh/authorized_keys粘贴救援虚拟机的
authorized_keys文件中的 SSH 公钥内容。在管理员工作站虚拟机已装载的数据磁盘上保存并关闭
authorized_keys文件。验证
/mnt/ext-disk/.ssh/中的文件是否应用了正确的权限：chown -R ubuntu /mnt/ext-disk/.ssh/* chmod -R 600 /mnt/ext-disk/.ssh/*退出与救援虚拟机的 SSH 连接。
关停救援虚拟机。
将数据磁盘与救援虚拟机分离，然后将该磁盘重新挂接到管理员工作站虚拟机。
启动管理员工作站。
虚拟机成功运行后，使用 SSH 和新的 SSH 密钥对连接到管理员工作站。
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM替换以下内容：
- 将
NEW_SSH_KEY替换为您在上一步中创建并复制到管理员工作站虚拟机的新 SSH 密钥的名称。 - 将
RESCUE_VM替换为您的管理员工作站虚拟机的 IP 地址或 FQDN。
验证您是否可以使用 SSH 成功连接。
- 将
删除救援虚拟机。