Uwierzytelnianie za pomocą klucza publicznego kończy się niepowodzeniem TYLKO wtedy, gdy sshd jest demonem

Nie mam pojęcia, jak to się dzieje. Distro to Scientific Linux 6.1 i wszystko jest skonfigurowane do przeprowadzania uwierzytelnienia za pomocą klucza publicznego. Jednak gdy sshd działa jako demon (uruchomienie sshd usługi), nie akceptuje kluczy publicznych. (Aby uzyskać ten dziennik, zmieniłem skrypt sshd, aby dodać opcję -ddd)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

Jeśli sshd działa w trybie debugowania /usr/sbin/sshd -ddd, uwierzytelnianie działa jak urok:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

Jakieś pomysły?? Czy ktoś widział coś takiego?

Uwagi:

Uprawnienia do plików zostały dwukrotnie sprawdzone:

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

Zapytano mnie, czy sshd może uzyskać dostęp do plików roota w „trybie demona”. Najbliższa odpowiedź na to pytanie brzmi:

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

Jeśli sshd działa jako root, nie wiem, w jaki sposób nie można uzyskać dostępu do własnych plików. Czy przyczyną może być SELinux?

Tak, prawdopodobnie przyczyną jest SELinux. Katalog .sshjest prawdopodobnie źle oznakowany. Patrzeć /var/log/audit/audit.log. Powinien być oznaczony ssh_home_t. Sprawdź za pomocą ls -laZ. Uruchom w restorecon -r -vv /root/.sshrazie potrzeby.

Miałem ten sam problem. W moim przypadku restorecon i chcon nie działały.

Nie chciałem wyłączać selinux. Po wielu badaniach w końcu doszedłem do wniosku, że mój katalog domowy został zamontowany z innego miejsca (NFS). Znalazłem ten raport o błędzie, który mnie wkurzył.

Prowadziłem:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

aby potwierdzić, że katalog use_nfs_home_dirs jest wyłączony, a następnie:

sudo setsebool -P use_nfs_home_dirs 1

żeby to włączyć.

Teraz mogę ssh do mojego komputera za pomocą mojego klucza i bez podawania hasła. Przełączanie wartości logicznej use_home_nfs_dirs było tym, czego potrzebowałem.

Aby dodać do odpowiedzi Marka Wagnera, jeśli używasz niestandardowej ścieżki do katalogu domowego (tzn. Nie /home), musisz upewnić się, że ustawiłeś kontekst bezpieczeństwa SELinux. Aby to zrobić, jeśli na przykład masz katalogi domowe użytkowników /myhome, uruchom:

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

Wygląda na to, że używasz różnych kluczy podczas testowania połączeń, 0x7f266e1a8840 vs 0x7f85527ef230. Spróbuj połączyć się za pomocą „ssh -v example.com” z sshd działającym jako demon i w trybie debugowania i poszukaj kluczy używanych przez ssh wokół ciągu „Oferowanie klucza publicznego RSA”.