在我的环境中,实际的 .ssh 目录存在于外部设备上,并~/.ssh
通过符号链接从该目录链接。作为客户端使用openssh
没有问题,但sshd
不允许使用其中的公钥进行身份验证。
有什么方法可以使用.ssh
外部设备上的目录吗?
journalctl -u sshd
Authentication refused: bad ownership or modes for directory /pool/secure/ssh
权限
$ ls -ld ~/.ssh
lrwxrwxrwx. 1 foobar foobar 28 Mar 7 19:59 .ssh -> /pool/secure/ssh
$ ls -l /pool/secure/ssh
-rw------- 1 foobar foobar 381 Jun 29 15:01 authorized_keys
-rw------- 1 foobar foobar 292 Jun 29 15:01 config
-rw-------. 1 foobar foobar 5306 Jun 23 02:16 known_hosts
$ ls -ld /pool/secure/ssh
drwx------. 2 foobar foobar 8 Jun 29 15:01
版本
$ ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
添加于2017-06-29(提示)
- OpenBSD和FreeBSD可以通过chmod修改符号链接的访问权限。但 Linux 没有系统调用来执行该操作。
- stat(2) 点击链接。
- 基本规范第 7 期未指定 st_mode 字段中返回的文件模式位的值。
已于2017-06-30解决
auth_secure_path有答案了。该函数检查文件和目录的权限,范围包括父目录。它继续检查是否设置了正确的权限(只有所有者可以写入),直到传递 home 或 root 。
ex) general environment
/home/foobar/.ssh (raise error if group and other can write)
/home/foobar (same)
break!
ex) special environment (like me)
/home/foobar/.ssh -> /pool/secure/ssh
/pool/secure/ssh (raise error if group and other can write)
/pool/secure (same)
/pool (same)
/ (same)
break!
答案1
这是一个权限问题。
您需要检查上面所有目录(包括foobar
's home)的权限,以及.ssh
外部设备上目标目录上面的所有目录的权限。除了foobar
目标.ssh
目录之外,所有其他目录都必须由 root 用户拥有,并且其他任何人都不可写入。
您可能还遇到 SELinux 问题。您可以使用以下标志检查文件和目录的 SELinux 安全上下文-Z
:
[sheepd0g@dogpound ~]$ ls -ZA
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 ..
drwxrwxr-x. sheepd0g sheepd0g unconfined_u:object_r:user_home_t:s0 20170620-auditlogs
-rw-rw-r--. sheepd0g sheepd0g unconfined_u:object_r:user_home_t:s0 random.dat
drwx------. sheepd0g sheepd0g unconfined_u:object_r:ssh_home_t:s0 .ssh
有几点需要注意:
- 权限模式字段末尾的句点表示 SELinux 上下文对该文件处于活动状态。
- 请注意,.ssh 文件夹的类型字段不同 (ssh_home_t)。
- SELinux 对象、类型、策略和设置在各个发行版甚至主要版本之间可能不相同。适用于 RHEL6 的方法可能不适用于 SUSE 10 或 Debian 6(我不确定 Debian 6 是否具有开箱即用的 SELinux 强制执行...)
不管怎样,如果其他方法都失败了,这是一个值得一看的好地方。您可以使用以下命令轻松检查 SELinux 是否处于强制模式:
[sheed0g@dogpound ~]$ sudo getenforce
Enforcing
如果您怀疑 SELinux 存在问题,您可以将 SELinux 切换到许可模式(启用策略,但不采取任何操作 - 仅记录/审核操作):
[sheepd0b@dogpound ~]$ sudo setenforce 0
[sheepd0b@dogpound ~]$ sudo getenforce
Permissive
如果您的问题消失了,这可能就是问题所在。
请注意,SELinux 比此处描述的复杂得多。如果您的 .ssh/ 位于 NFS 共享上,您将需要对 SELinux 的布尔设置进行更多更改。
以下是关于 SELinux 的两个很好的参考:
答案2
就我而言(在 Lenovo NAS 上),更改权限没有帮助,但绑定安装解决了问题。
代替
ln -s /pool/secure/ssh .ssh
我做到了
mkdir -m 700 .ssh
mount --bind /pool/secure/ssh .ssh
答案3
SSH 的抱怨是有原因的。该~/.ssh/
目录是世界可写的,因此任何人都可以修改它。
如果这对您来说不是问题,您可以设置StrictModes no
,sshd_config
无论如何它都会被使用。sshd
更改后不要忘记重新启动服务。