SELinux zapobiega ssh z kluczem RSA

Question

Zapomniałem, że uruchomiłem SELinux na jednym z moich serwerów. Więc kiedy poszłam zalogować się do hosta z moim kontem użytkownika i kluczem ssh, otrzymywałem błędy odmowy uprawnień.

[TimothyDunphy@JEC206429674LM:~] #ssh bluethundr@web1.somedomain.com 
Permission denied (publickey,gssapi-keyex,gssapi-with-mic). 

Hmmm ... Więc pocieszałem się do serwera i mogłem się zalogować. I ogonami dzienniki kontroli, a to co widziałem:

type=USER_LOGIN msg=audit(1429981690.809:394593): pid=17074 uid=0  auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023  msg='op=login acct="bluethundr" exe="/usr/sbin/sshd" hostname=? addr=47.18.111.100 terminal=ssh res=failed' 

W googlowania na odpowiedź na to mam radę uruchomić polecenie:

[root@web1:~] #restorecon -R -v /home/bluethundr/.ssh 
[root@web1:~] # 

Ale kiedy idę ponownie zalogować , po zrobieniu tego, otrzymuję ten sam rezultat. Odmowa uprawnień i ten sam błąd w dziennikach.

Jedyna rzecz, o której mogę myśleć to to, że katalog domowy użytkownika jest podłączony z udziału NFS. Może istnieje inkantacja SELinuksa, której mogę użyć, aby umożliwić SSH do katalogu domowego w udziale NFS?

A może brakuje mi czegoś innego?

Dzięki Tim

Answer 1

Jeśli restorecon nie działa, ja generalnie starają audit2why i/lub audit2allow znaleźć to polityka jest naruszone. Nie oznacza to, że stosuję generowane sugestie dotyczące zmiany polityki, tylko że prowadzą one do bardzo dobrych informacji w celu rozwiązania problemu.

Answer 2

Bingo !!

Kiedy wpadłem audit2why -w to było wyjście widziałem:

[root@web1:~] #grep ssh /var/log/audit/audit.log | audit2why -w 
Was caused by: 
    The boolean use_nfs_home_dirs was set incorrectly. 
    Description: 
    Allow use to nfs home dirs 

    Allow access by executing: 
    # setsebool -P use_nfs_home_dirs 1 
    type=AVC msg=audit(1429983513.529:394784): avc: denied { read } for pid=19748 comm="sshd" name="authorized_keys" dev="0:40" ino=275968 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nfs_t:s0 tclass=file 

Tak wygląda moje przeczucie, że był o NFS i sugestię korzystać audit2why pozwala mi pęka sprawę!

[TimothyDunphy@JEC206429674LM:~/creds] #ssh bluethundr@web1.jokefire.com 
Last login: Sat Apr 25 13:41:02 2015 from ool-2f126f64.dyn.optonline.net 
[bluethundr@web1 ~]$ 

Bam! To działa. Dzięki za pomoc!