在 RHEL 6.1 上，使用公钥以 root 身份进行 SSH 仍会提示输入密码

Question 1

在 RHEL 6.5 上安装 Gitlab 6.4 后，我遇到了同样的问题。无论我做什么，我都无法使用主系统用户 (git) 的公钥进行 SSH。SSH 密钥再次正常，~/.ssh (700) 和 ~/.ssh/authorized_keys (600) 上的权限也是如此。问题是 seliunx 正在“强制执行”，并且 .ssh 目录中的上下文错误，可能是因为用户是作为系统用户创建的。您可以像 @Dean-Schulze 那样通过将用户更改为普通用户来修复，但我设法使用 restorecon 命令修复了受影响用户的上下文，这可能会解决您遇到的问题。

检查 selinux 是否正在强制执行

sestatus

使用以下方式检查上下文

ls -laZ ~/.ssh

我发现“类型”上下文需要是“ssh_home_t”

要修复 ssh 目录，请以受影响的用户身份登录/su，然后运行

restorecon -R -v ~/.ssh

如果这不起作用，您可能需要修复用户主目录上的上下文

restorecon -R -v ~/

我发现更多信息很有用http://themattreid.com/wordpress/2012/11/02/selinux-solutions-fixing-a-newly-provisioned-server-that-refuses-ssh-key-based-login/

Answer

在 RHEL 6.5 上安装 Gitlab 6.4 后，我遇到了同样的问题。无论我做什么，我都无法使用主系统用户 (git) 的公钥进行 SSH。SSH 密钥再次正常，~/.ssh (700) 和 ~/.ssh/authorized_keys (600) 上的权限也是如此。问题是 seliunx 正在“强制执行”，并且 .ssh 目录中的上下文错误，可能是因为用户是作为系统用户创建的。您可以像 @Dean-Schulze 那样通过将用户更改为普通用户来修复，但我设法使用 restorecon 命令修复了受影响用户的上下文，这可能会解决您遇到的问题。

检查 selinux 是否正在强制执行

sestatus

使用以下方式检查上下文

ls -laZ ~/.ssh

我发现“类型”上下文需要是“ssh_home_t”

要修复 ssh 目录，请以受影响的用户身份登录/su，然后运行

restorecon -R -v ~/.ssh

如果这不起作用，您可能需要修复用户主目录上的上下文

restorecon -R -v ~/

我发现更多信息很有用http://themattreid.com/wordpress/2012/11/02/selinux-solutions-fixing-a-newly-provisioned-server-that-refuses-ssh-key-based-login/

Question 2

~./ssh 的拒绝在 /var/log/audit/audit.log 中如下所示：

type=AVC msg=audit(1355348670.326:87): avc:  denied  { read } for  pid=1490 comm="sshd"    name="authorized_keys" dev=dm-1 ino=277466 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

SELinux 是否启用了？

getenforce

~/.ssh 上的上下文是什么？在手动创建的目录中，它可能不正确。

# ls -alZd .ssh/
drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 .ssh/

但在您重新标记或设置适当的上下文之后应该可以。

# ls -alZd .ssh/
drwx------. root root system_u:object_r:ssh_home_t:s0  .ssh/

或者禁用 SELinux / 设置宽容 :)

Answer

~./ssh 的拒绝在 /var/log/audit/audit.log 中如下所示：

type=AVC msg=audit(1355348670.326:87): avc:  denied  { read } for  pid=1490 comm="sshd"    name="authorized_keys" dev=dm-1 ino=277466 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

SELinux 是否启用了？

getenforce

~/.ssh 上的上下文是什么？在手动创建的目录中，它可能不正确。

# ls -alZd .ssh/
drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 .ssh/

但在您重新标记或设置适当的上下文之后应该可以。

# ls -alZd .ssh/
drwx------. root root system_u:object_r:ssh_home_t:s0  .ssh/

或者禁用 SELinux / 设置宽容 :)

Question 3

公钥失效通常是由于 authorized_keys 文件的文件权限错误造成的。请确保该文件的权限被修改为 644。

我多次遇到过这个“问题”。问题不仅在于文件 authorized_keys 的权限，还在于目录“.ssh”和“..” (用户主目录) 的权限也应正确设置。通过设置权限如下，可以解决问题：.ssh 的权限为 700，“..”的权限至少为 754，文件 authorized_keys 的权限为 600：

# ls -lah .ssh
drwx------. 2 root root 4.0K Dec 11 14:09 .
drwxr-xr--. 3 root root 4.0K Dec 11 14:08 ..
-rw-------. 1 root root  399 Dec 11 14:09 authorized_keys

Answer

公钥失效通常是由于 authorized_keys 文件的文件权限错误造成的。请确保该文件的权限被修改为 644。

我多次遇到过这个“问题”。问题不仅在于文件 authorized_keys 的权限，还在于目录“.ssh”和“..” (用户主目录) 的权限也应正确设置。通过设置权限如下，可以解决问题：.ssh 的权限为 700，“..”的权限至少为 754，文件 authorized_keys 的权限为 600：

# ls -lah .ssh
drwx------. 2 root root 4.0K Dec 11 14:09 .
drwxr-xr--. 3 root root 4.0K Dec 11 14:08 ..
-rw-------. 1 root root  399 Dec 11 14:09 authorized_keys

Question 4

我通过添加另一个用户，然后将 Tomcat webapp/ 目录更改为由该普通用户拥有来解决这个问题。该普通用户使用密钥进行身份验证没有问题，并且该用户可以通过 ssh 和 scp 执行命令（远程重新部署到 Tomcat）。

RHEL 采取的另一项安全预防措施是禁用 Tomcat 管理器应用程序，这样我就无法通过 Tomcat 管理器进行远程部署。（我尝试重新添加管理器应用程序并设置管理员和管理器用户，但管理器应用程序无法运行）。

Answer

我通过添加另一个用户，然后将 Tomcat webapp/ 目录更改为由该普通用户拥有来解决这个问题。该普通用户使用密钥进行身份验证没有问题，并且该用户可以通过 ssh 和 scp 执行命令（远程重新部署到 Tomcat）。

RHEL 采取的另一项安全预防措施是禁用 Tomcat 管理器应用程序，这样我就无法通过 Tomcat 管理器进行远程部署。（我尝试重新添加管理器应用程序并设置管理员和管理器用户，但管理器应用程序无法运行）。

在 RHEL 6.1 上，使用公钥以 root 身份进行 SSH 仍会提示输入密码

答案1

答案2

答案3

答案4

相关内容