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 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

Added 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-30

auth_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)

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)
  • 1
    can you set: StrcitModes no then ssh will not check permisions, can you check if is working then? other options is mount --bind Jun 29, 2017 at 6:50

3 Answers 3


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 -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

A couple things to note:

  1. The period at the end of the permission mode fields means SELinux context is active for that file.
  2. Notice the Type field for the .ssh folder is different (ssh_home_t).
  3. 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 getenforce

If 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 getenforce

If 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 SELinux

Red Hat Enterprise Linux 7 SELinux guide

  • In that case, SSH would say what directory is wrong. The error message points directly to the mounted one/symlink and not to any other.
    – Jakuje
    Jun 29, 2017 at 7:32
  • 1
    Also, if you have SELinux in Enforcing mode, the context of the folder needs to be correct. We encountered this with NFS mounted home directories.
    – 0xSheepdog
    Jun 29, 2017 at 16:08
  • 1
    @0xSheepdog ah, yes. I don't use SELinux on a regular basis so I keep forgetting to mention it. Please feel free to update the answer because you'll have more accurate recommendations than me. Jun 29, 2017 at 22:39
  • 1
    Updated. my update is longer than your answer. =) No worries, so long as the OP gets the answer needed.
    – 0xSheepdog
    Jun 30, 2017 at 15:14

In my case (on Lenovo NAS) change the permissions did not help, but a bind mount resolved the problem.

Instead of

ln -s  /pool/secure/ssh  .ssh

I did

mkdir -m 700 .ssh
mount --bind  /pool/secure/ssh  .ssh
  • This should be the accepted answer if you need to symlink your .ssh folder. I cannot find another viable solution. It's also important that files within your symlinked folder have the correct permissions. Example: chmod 600 ~/.ssh/authorized_keys
    – HenryHayes
    Feb 15, 2022 at 8:45

The SSH is complaining for a reason. The ~/.ssh/ directory is world-writable and therefore anyone can modify it.

If it is not an issue for you, you can set StrictModes no in sshd_config and it will get used anyway. Don't forget to restart the sshd service after the change.

  • It's not world writeable. Perhaps you're mis-interpreting the (unused) permissions bits on the symlink? Jun 29, 2017 at 7:07
  • @roaima well ... SSH is using stat and it sees the above. Feel free to correct me if there is other way how to resolve the issue.
    – Jakuje
    Jun 29, 2017 at 7:10
  • 4
    You can't set or change permissions on a symlink because they are meaningless Jun 29, 2017 at 7:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .