In my environment, actual .ssh directory exists on external device and links from it to ~/.ssh with a symbolic link. Using openssh as client is working without problem, but sshd does not allow to authentication with public key inside it.Is there any method to use .ssh directory on external device?journalctl -u sshdAuthentication refused: bad ownership or modes for directory /pool/secure/sshpermissions$ ls -ld ~/.sshlrwxrwxrwx. 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/sshdrwx------. 2 foobar foobar 8 Jun 29 15:01version$ ssh -V       OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017Added at 2017-06-29 (Tips)OpenBSD and FreeBSD can modify access permission of symlink by chmod. But Linux does not have system call doing that operation.stat(2) follow the link.Base Specifications Issue 7 unspecified the value of the file mode bits returned in the st_mode field.Solved at 2017-06-30auth_secure_path have the answer. This function check permissions of file and directory, the range include parent directory. It continues to check if correct permissions (only owner can write) are set, until passing the home or 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!
OpenSSH refused .ssh directory with a symbolic link
symlink;openssh
It is a permissions issue.You need to check permissions for all directories above and including foobar's home, and also all directories above the target .ssh directory on your external device. Apart from foobar and the target .ssh directories, all others must be owned by root and not writeable by anyone else.You may also have an SELinux issue. You can check the SELinux security context of files and directories with the -Z flag:[sheepd0g@dogpound ~]$ ls -ZAdrwxr-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.datdrwx------. sheepd0g sheepd0g unconfined_u:object_r:ssh_home_t:s0 .sshA couple things to note:The period at the end of the permission mode fields means SELinux context is active for that file.Notice the Type field for the .ssh folder is different (ssh_home_t).SELinux objects, types, policies, and settings may not be the same across distributions, or even major versions. What works for RHEL6 may not for, say SUSE 10 or Debian 6 (I'm not sure Debian 6 even has SELinux enforcing, out of the box...)Regardless, this is a good place to look if all else fails. You can check if SELinux is in enforcing mode easily enough with the following:[sheed0g@dogpound ~]$ sudo getenforceEnforcingIf you suspect SELinux us the issue, you can switch SELinux to Permissive mode (policies are enabled, but no action is taken -- just logging/auditing of actions):[sheepd0b@dogpound ~]$ sudo setenforce 0[sheepd0b@dogpound ~]$ sudo getenforcePermissiveIf your issue goes away, this is likely the problem.Please note, there is A LOT more complexity to SELinux than what is represented here. If your .ssh/ is on an NFS share you will be required to make more changes with boolean settings for SELinux.Here are two good references for SELinux:CentOS wiki entry on SELinuxRed Hat Enterprise Linux 7 SELinux guide