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?
Odpowiedzi:
Tak, prawdopodobnie przyczyną jest SELinux. Katalog
.ssh
jest prawdopodobnie źle oznakowany. Patrzeć/var/log/audit/audit.log
. Powinien być oznaczonyssh_home_t
. Sprawdź za pomocąls -laZ
. Uruchom wrestorecon -r -vv /root/.ssh
razie potrzeby.źródło
restorecon -r /
. YMMV.type=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
- nie jestem pewien, co to znaczyname="/"
- musiałem uruchomićrestorecon -r /
zgodnie z sugestią @Irfy.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:
aby potwierdzić, że katalog use_nfs_home_dirs jest wyłączony, a następnie:
ż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.
źródło
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:źródło
semanage
:sudo yum install policycoreutils-python
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”.
źródło
debug3: mm_answer_keyallowed: key 0xFFFFFFFFFF
zmienia się za każdym razem, gdy sshd otrzymuje nowe połączenie. Aby to potwierdzić, znajdź serwer, na którym działa SSH, podkręć sshd LOGLEVEL w celu debugowania3, zrestartuj sshd, uruchom,tail -f /var/log/secure |grep mm_answer_keyallowed
a następnie zaloguj się kilka razy, czekając kilka sekund (lub minut) między każdym połączeniem. Zobaczysz, że wartość zmienia się za każdym razem. I właściwie to wygląda dla mnie na przeciwnika.