Does sshd do filesystem checks when considering to accept keys?

Question

I know that sshd will refuse connection for bad ownership or modes for directory, but is there some other silent check and failure relating to the location of user's home directory? Or some configuration issue for that partition?

using CentOS release 6.3 (Final)

I'm trying to setup a new user, git, with a home directory on a large partition, but sshd seems to silently fail.

here's my sequence:

1. add new user
2. setup .ssh/authorized_keys with known public key
3. ssh from remote host

If I setup the new user in /home/git, then everything works fine, but if I setup the user with a home folder on a different partition, then sshd seems to silently fail.

# userdel -r git
# useradd -m -d /home/git -c "Git Test" -s /bin/bash -g users git
# su -l git
# mkdir .ssh
# chmod 700 .ssh
# cp /tmp/authorized_keys .ssh

This works just fine, but if I change the useradd line to:

useradd -m -d /space/git -c "Git Test" -s /bin/bash -g users git

With LogLevel Verbose, the only message in auth log is:

Connection from XX.XX.XX.XX port 50774
Failed publickey for git from XX.XX.XX.XX port 50774 ssh2
Connection closed by XX.XX.XX.XX

Passing -vvv to ssh shows:

debug1: Offering public key: <USER>/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

Update: showing ownership:

# ls -l /space/git
drwx------. 5 git  users 4096 Mar  7 17:43 .
drwxr-xr-x. 7 root root  4096 Mar  7 17:39 ..
drwx------. 2 git  users 4096 Mar  7 17:40 .ssh

Ownership on /home is identical

Answer 1

You created a user home directory outside of /home, and so SELinux, knowing nothing about your intentions, denied access to it.

To resolve the issue, set a permanent SELinux context for the home directory and then relabel the files.

semanage fcontext -a -t user_home_t "/space/git(/.*)?"
restorecon -r -v /space/git

(BTW, /srv is the preferred directory for such things, rather than /space.)