Mam problem z CentOS 6.7, w którym logowanie SSH jest o 1 s większe niż w przypadku innych komputerów w wersji innej niż 6.7 w tej sieci (np. 7.2, 5.11). Uruchomienie debugowania po stronie klienta pokazało zawieszenie się podczas „Wprowadzania sesji interaktywnej”.
Polecenie, którego używam do oparcia tego testu, pochodzi time ssh <host> truez mojego laptopa, używając kluczy SSH.
Dwie rzeczy, które już sprawdziłem / zmodyfikowałem, to UseDNSi GSSAPIAuthentication, i obie są wyłączone.
Uruchomiłem osobnego demona na innym porcie z włączonym debugowaniem i znalazłem, gdzie występuje krótkie zawieszenie:
debug1: SELinux support enabled
debug3: ssh_selinux_setup_exec_context: setting execution context
{1s hang}
debug3: ssh_selinux_setup_exec_context: done
SELinux jest ustawiony na „permissive”. Nie jestem pewien, dlaczego miałoby to nawet przeszkadzać w „ustawianiu kontekstów”. Czy jest jakiś sposób, aby te dwa poradziły sobie lepiej bez całkowitego wyłączenia SELinux? Zdaję sobie sprawę, że 1s nie jest wiele, ale używam tej konkretnej maszyny jako bramy SSH do hostów z białymi listami IP (jest to statyczna maszyna IP) i sumuje się przez cały dzień.
Po uruchomieniu ciągu zawieszenie jest nieco bardziej szczegółowe:
22:16:05.445032 open("/selinux/user", O_RDWR|O_LARGEFILE) = 4 <0.000090>
22:16:05.445235 write(4, "unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 unconfined_u", 56) = 56 <0.334742>
22:16:05.780128 read(4, "18\0unconfined_u:system_r:prelink_mask_t:s0-s0:c0.c1023\0unconfined_u:system_r:unconfined_mount_t:s0-s0:c0.c1023\0unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023\0unconfined_u:system_r:oddjob_mkhomedir_t:s0-s0:c0.c1023\0unconfined_u:system_r:unconfined_notrans_t:s0-s0:c0.c1023\0unconfined_u:system_r:unconfined_execmem_t:s0-s0:c0.c1023\0unconfined_u:system_r:unconfined_java_t:s0-s0:c0.c1023\0unconfined_u:system_r:unconfined_mono_t:s0-s0:c0.c1023\0unconfined_u:system_r:chkpwd_t:s0-s0:c0.c1023\0unconfined_u:system_r:passwd_t:s0-s0:c0.c1023\0unconfined_u:system_r:updpwd_t:s0-s0:c0.c1023\0unconfined_u:system_r:mount_t:s0-s0:c0.c1023\0unconfined_u:system_r:rssh_t:s0-s0:c0.c1023\0unconfined_u:system_r:xauth_t:s0-s0:c0.c1023\0unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023\0unconfined_u:system_r:openshift_t:s0-s0:c0.c1023\0unconfined_u:unconfined_r:oddjob_mkhomedir_t:s0-s0:c0.c1023\0unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023\0", 4095) = 929 <0.000079>
/selinux/userSamo pisanie zajmuje 350 ms.
Aktualizacja 1 - rzeczy, które od tamtej pory próbowałem :
- Aktualizacja Wiele skrzynek wymagało aktualizacji. Nie miało to żadnego istotnego wpływu na czasy logowania.
semodule -d unconfined- To miało pozytywny efekt, skracając czas logowania o około 500 ms. Jednak moje urządzenia C7 i C5.11 (które od tego czasu (ponownie) nauczyłem się mają wyłączony SELinux) średnio ~ 525 ms- Porównywanie moich maszyn C6.7 - Okazuje się, że 64-bitowe urządzenia są szybsze niż moje 32-bitowe urządzenia. Może dla niektórych jest to moment „duh”, ale ponieważ żadne z tych urządzeń nie jest szczególnie opodatkowane, nie spodziewałem się wariancji 100–300 ms. Udało mi się przełamać znak 1s (850 ms) na jednym z 64-bitowych hostów. Najniższy na 32bit to 1.085s
Czy pytam za dużo? Czy 10-1200 ms to akceptowalny czas logowania dla maszyn dopuszczających selinux? Ciekawe, jakie są wskaźniki innych ludzi.
messageslubsecurestracei zobaczyć, jakie połączenie jest zawieszone.Odpowiedzi:
To może nie być powiązane, ale powolność związana z selinux została zgłoszona dla kont opartych na IPA tutaj: https://access.redhat.com/discussions/3499951
Rozwiązaniem tego przypadku jest:
źródło