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

33

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?

user666412
źródło
1
Czy skrypt inicjujący sshd robi coś interesującego? (Czy powinno być /etc/init.d/sshd?), Którego nie robisz w wierszu poleceń? Zamiast „service sshd start” spróbuj „sh -x /etc/init.d/ssh start”.
PT

Odpowiedzi:

42

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.

Mark Wagner
źródło
1
Tak, SELinux był przyczyną: type = AVC msg = audit (1318597097.413: 5447): avc: denied {read} for pid = 19849 comm = "sshd" name = "managed_keys" dev = dm-0 ino = 262398 scontext = unconfined_u : system_r: sshd_t: s0-s0: c0.c1023 tcontext = unconfined_u: object_r: admin_home_t: s0 tclass = plik Działa po uruchomieniu polecenia „restorecon -r -vv /root/.ssh”. Wielkie dzięki.
user666412,
1
dzięki DZIĘKUJEMY za poprawkę wiersza polecenia selinux, którą od wieków próbowałem znaleźć, dlaczego mogłem ssh jako root na moim serwerze redhat Enterprise 6.2 przy użyciu uwierzytelniania za pomocą klucza ssh, ale nie mogłem ssh jako użytkownik inny niż root bez konieczności wprowadzania hasła. „ssh -v” wcale nie wskazuje na nic niezwykłego. Sprawdziłem i ponownie sprawdziłem zabezpieczenia plików na /home/example/.ssh Dopiero po uruchomieniu „/ usr / sbin / sshd -d” i z jakiegoś powodu działającego normalnie zdałem sobie sprawę, że dzieje się coś innego, i spróbowałem innej wyszukiwarki google i znalazłem to. Tak więc symptomy były takie, że mogłem ssh jako ro
Paul M
1
Musiałem to zrobić na całym systemie plików, tj restorecon -r /. YMMV.
Irfy,
1
Próbowałem tego - ale nadal nie działa. w dzienniku kontroli mam 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 znaczy
Yehosef
1
Odpowiedź brzmiała name="/"- musiałem uruchomić restorecon -r /zgodnie z sugestią @Irfy.
Yehosef,
3

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.

Gerard
źródło
1

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
DavidArndt
źródło
Jeśli korzystasz z CentOS, musisz uruchomić to, aby semanage:sudo yum install policycoreutils-python
sm4rk0
0

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”.

Johan Nilsson
źródło
Tak, były id_rsa i id_dsa. Klucz DSA zniknął i powtórzę test.
user666412,
Wspomniana wartość debug3: mm_answer_keyallowed: key 0xFFFFFFFFFFzmienia 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_keyalloweda 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.
Stefan Lasiewski