Just a short story after resolving a recently encountered problem: all our machines that are in the cloud, have SELinux enabled by default. Normally not a problem, but I found one interesting nuisance: one user could not log on using ssh key authentication.
It would have been found faster, but the developers stated, that _some_ users can’t use the key authentication method; had they told me from the get-go that they meant one user, I’d have been faster with the resolution.
First I confirmed the problem by adding my own ssh key to the .ssh/authorized_keys file in the affected user’s home directory, I checked all directory and file owners and permissions (644 on the .ssh, and 600 on the keyfile) – problem confirmed, I’m getting prompted for a password.
Using ssh -vvv I got this difference in logging in:
Unaffected user:
debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279
Affected user:
debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex, gssapi-with-mic,password
My key is obviously denied, but without message? Why? Let’s look in the system’s logfiles.
In the audit.log is a hint at the culprit:
Nov 18 11:51:43 sa1ha2l kernel: type=1400 audit(1384771903.411:62597): avc:
denied { search } for pid=14683 comm="sshd" name="/" dev=dm-3 ino=2 scontext=
system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0
tclass=dir
My old “friend” the AVC denial, we meet again. At first I did a simple restorecon -v -R, but no luck, still got an AVC denied message. There was no difference in the SELinux permissions on the affected user’s and a random unaffected user’s .ssh directory, still a tclass=dir denial? What the …? Let’s look up one level!
[root@localhost ~]# ls -lZ /var/local/ | grep sa1user drwx------. sai1usr sa1grp system_u:object_r:var_t:s0 sa1user [root@localhost ~]# ls -lZ /home drwxr-xr-x. root root unconfined_u:object_r:home_root_t:s0 chroot drwx------. test1 test1 unconfined_u:object_r:user_home_dir_t:s0 test1
Gotcha! Although both users were created with the adduser command, the user in the nonstandard /var/local location did not have the user_home_dir context on its homedir.
Repair was easy:
chcon -v --type=user_home_dir_t /usr/local/sa1user
SSH key login began functioning immediately.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
