谷歌云引擎。权限被拒绝（公钥、gssapi-keyex、gssapi-with-mic）答案

【问题标题】：Google Cloud Engine. Permission denied (publickey,gssapi-keyex,gssapi-with-mic)谷歌云引擎。权限被拒绝（公钥、gssapi-keyex、gssapi-with-mic）
【发布时间】：2013-12-07 10:08:36
【问题描述】：

我无法再通过 ssh 连接，我几乎可以连接 24 小时。突然之间，ssh 停止工作。我有很多用户，我还在那个 VM 中添加了一个新的 (tomcat) 用户。

当我尝试 ssh 到我的实例时收到以下消息：

"Permission denied (publickey,gssapi-keyex,gssapi-with-mic)."

我最终删除了 ~/.ssh/google_compute_engine*

从 Cloud Engine 控制台中移除了“sshKeys”元数据

再次尝试gcutil ssh，这创建了新的~/.ssh/google_compute_engine 文件以及sshKeys metadata。

但我仍然收到该错误。

【问题讨论】：

我最终在 gcutil 中使用 --ssh_user=anotheruser 标志在实例上创建了一个不同的用户，这很有效。
你应该停止使用谷歌云。这是一个永远的 alpha/beta 产品。总是被损坏和臃肿的 SDK 打破
为什么谷歌不告诉我们这个？或者有有效的指导？

标签： google-compute-engine

【解决方案1】：

我遇到了同样的问题，我调试了大约 16 个小时。然而，我找到了解决方案，我希望你能在我的冒险之旅中分享一下。

我在宣传为一键安装的 Google Compute Engine 上运行 GitLab。

好吧，最后当我尝试克隆一个私有存储库时，我收到了错误消息：

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

我查看了私钥/公钥对，没有发现任何异常。

然后当我收到调试消息时，我认为服务器上的 sshd 可能有问题：

debug1: ssh_rsa_verify: signature correct
[...]
debug1: Roaming not allowed by server

所以我检查了许多不同的 sshd 设置，但都没有真正解决问题。

最后我开始在服务器端调试，发现错误：

sshd[7364]: debug1: Could not open authorized keys '/var/opt/gitlab/.ssh/authorized_keys': Permission denied

终于，这是通往幸福的大道。因为该文件存在并且 sshd 知道它必须加载哪个文件。但是，不知何故存在权限问题。

所以我检查了 remote .ssh 文件夹中文件的 chmod 是否正常。我没有发现任何异常。

这是解决方案：

SELinux 确实对 .ssh 文件夹的位置有问题，并且不愿意授予 ssh 守护进程的权限。通过执行命令

restorecon -Rv /var/opt/gitlab/.ssh/

或

semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys"

这两个命令之一解决了这个问题。如果有人可以验证这两者中的哪一个，我会很高兴！

因此您无需停用 SELinux！

【讨论】：

哇，你是救生员。我运行了以下命令来让 GitLab 工作：sudo yum -y install policycoreutils-python && sudo semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys" 你在这里回答了我的问题：stackoverflow.com/questions/26427165/…

【解决方案2】：

这确实是 @sxleixer 对正确解决方案的评论，但我想要格式化。

semanage 工具默认未安装。去拿吧

sudo yum -y install policycoreutils-python

允许非标准的 ssh_home_t

sudo semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys"

要么重启sshd，要么完全重启
```
sudo shutdown -r now
```

测试一切都在本地工作

ssh-keygen -t rsa -C "test@example.com"
cat ~/.ssh/id_rsa.pub # Copy-paste the key to the 'My SSH Keys' section under the 'SSH' tab in your user profile
ssh -T git@localhost  # Should now output "Welcome to GitLab"

这修复了在 Google Compute Engine 上一键安装 GitLab。

确实没有充分的理由关闭 SELinux。

【讨论】：

感谢您格式化并明确定义流程。您在这里帮助回答了我的问题：stackoverflow.com/questions/26427165/…

【解决方案3】：

在这种情况下，您的主要用户的 .ssh/authorized_keys 文件可能配置错误。该文件可能包含错误的数据，但我怀疑您实际上需要修复权限。试试这个：

gcutil ssh --ssh_user=anotheruser <yourinstance>
sudo su - <youruser>
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

然后尝试再次以您的用户身份登录。

【讨论】：

【解决方案4】：

关闭 selinux。

setenforce 0

还要在 /etc/selinux/config 中将 SELINUX 设置为 permissive。

然后去投票这个答案：https://stackoverflow.com/a/24212432/162070

【讨论】：

【解决方案5】：

解决方案：

在实例 1 上将您的私钥权限更改为 0600
ssh -i /home/user/.ssh/id_rsa user2@instance-2

【讨论】：

【解决方案6】：

我尝试了上述所有方法，但仍然收到此错误消息。

这是一个新的 CentOS 8 虚拟机。我对 CentOS 7 虚拟机没有任何问题，它可以正常工作，并且可以继续工作，但问题似乎出在 CentOS 8 上。

我在此处提供了完整的信息和日志（这可能与此处的问题不同，但错误消息相同）：

https://stackoverflow.com/questions/58430955/ssh-stops-working-on-centos-8-gce-vm-permission-denied-publickey-gssapi-keyex

GCE 确实出了点问题，在过去 5 年多的时间里，这似乎一直在发生/关闭，此页面的浏览量已超过 13K。

【讨论】：

【解决方案7】：

尝试这样做，我遇到了同样的问题，以下解决方案运行良好。使用 vi/vim 或任何其他编辑器编辑系统上的“/etc/ssh/sshd_config”文件，并将“PasswordAuthentication”设置为yes

【讨论】：