Zagwarantowanie dostępu SSH na obciążonym serwerze

Jakiś czas temu miałem problem z serwerem, na którym Apache i Snort zajmowali 100% procesora, przez co sshd nie reagował na dostęp zdalny. Musiałem udać się fizycznie na serwer, aby zalogować się do lokalnego TTY, a następnie zatrzymać apache / snort.

Zastanawiam się, czy istnieje sposób na zagwarantowanie łączności ssh w przypadku 100% obciążenia procesora / pamięci. Czy wystarczyłoby ustawić „miły” priorytet?

Dziękuję Ci!

linux ssh process-priority Renato Todorov
źródło

Odpowiedzi:

Poza wykorzystaniem metody pozapasmowej nie ma możliwości zagwarantowania, że SSH będzie dostępny na w pełni załadowanym serwerze. Jeśli twoja usługa jest tak załadowana, że nie może ci nawet obsługiwać podstawowego terminala SSH, masz inne problemy.

Tak, renicea nadanie jej niższej nicewartości poprawi wydajność przy dużych obciążeniach, ale zamiast tego użycie czegoś takiego jak pam_security (przykład pokazany tutaj ) zapobiegnie niemożności zarządzania Apache / cokolwiek na początku.

Nathan C.
źródło

Dobrze. Stara się wyleczyć objaw, a nie prawdziwy problem.

ewwhite

@ewwhite Dokładnie. Leczenie tego objawu spowoduje po prostu ściganie ogona, próbując dowiedzieć się, dlaczego w wyniku tego psują się inne rzeczy. :)

Nathan C

Szukam sposobu na ugaszenie ognia, ale oczywiście ustalę granice dla innych demonów. To jest sytuacja nadzwyczajna, muszę mieć spokój, aby wiedzieć, że zawsze będę mieć sshd reagujący na zdalny dostęp.

Renato Todorov

@RenatoTodorov w tym przypadku nie można wyleczyć objawu. Jeśli twój system ma niekontrolowany proces, który pochłania wszystkie {procesor, pamięć RAM, gniazda, identyfikatory PID}, nie możesz zagwarantować, że nawet nicewinowajca zostanie uruchomiony z procesora wystarczająco szybko, aby zapewnić dostęp do SSH (lub w tym przypadku każdy dostęp do konsoli byłby użyteczny). Należy rozwiązać zasadniczy problem (wieprz zasobów). Gaszenie pożarów to złe zarządzanie systemem.

voretaq7

Przekonaliście mnie, że będę korzystał z iDRAC 7 Express, o ile już go mam. Dziękuję wam wszystkim!

Renato Todorov

Rozwiązaniem tego ogólnego zastosowania jest pozapasmowe narzędzie do zarządzania, takie jak Dell iDRAC, IBM Remote Supervisor lub HP iLO. Zawsze może prezentować konsolę (czy system operacyjny może na nią zareagować, zależy od konkretnej sytuacji) i zastosować pożądane stany zasilania w razie potrzeby.

mfinni
źródło

Ok, iDRAC jest dobrą opcją, ponieważ używam serwerów Dell, ale myślałem o prostszym rozwiązaniu, może coś w rodzaju zarezerwowania procesora dla sshd (w tym jego potomków spawnowanych), jakiegoś rodzaju „QoS” dla lokalnych usług.

Renato Todorov

Niektóre firmy są spłukane lub chciwe: w takim przypadku sysrqd może być tanią alternatywą dla iDRAC, iLO, KVM ...

bgtvfr

Odniosłem pewien sukces, nadając sshd przywilej w czasie rzeczywistym, jednak wiąże się to z koniecznością ponownego uruchomienia komputera, jeśli jeden z procesów w czasie rzeczywistym ucieka.

Jeśli więc chcesz zejść tą drogą, uruchom drugiego demona ssh, który jest przeznaczony tylko na wypadek awarii. :)

Simon Richter
źródło

realtimeing sshd wydaje mi się niebezpieczny, szczególnie na porcie 22 (skan SSH może stać się atakiem DoS - uruchomienie na alternatywnym porcie może to złagodzić, ale nadal bym się bał ...)

voretaq7

nie stanowi problemu, jeśli zablokuję dostęp z Internetu, właściwie moją jedyną drogą do tego serwera jest VPN. dziękuję za sugestię!

Renato Todorov