Гарантия доступа по SSH на загруженном сервере

Некоторое время назад у меня возникла проблема с сервером, на котором Apache и Snort занимали 100% процессора, из-за чего sshd не отвечал через удаленный доступ. Мне пришлось физически перейти на сервер, чтобы войти в локальный TTY, а затем остановить apache / snort.

Мне интересно, есть ли способ гарантировать подключение по SSH в ситуации, когда процессор / память загружены на 100%. Установка «хорошего» приоритета будет достаточно?

Спасибо!

linux ssh process-priority

— Ренато Тодоров
источник

Ответы:

Кроме использования внеполосного метода, нет никакого способа гарантировать, что SSH будет доступен на полностью загруженном сервере. Если ваш сервис настолько загружен, что он даже не может обслуживать базовый терминал SSH, у вас есть другие проблемы.

Да, reniceи присвоение ему меньшего niceзначения улучшит производительность при больших нагрузках, но вместо этого использование чего-то вроде pam_security (пример, показанный здесь ) предотвратит невозможность управления Apache / что-либо еще с самого начала.

— Натан С
источник

Правильно. Он пытается вылечить симптом, а не настоящую проблему.

— ewwhite

@ewwhite Точно. А лечение симптома приведет к тому, что вы будете преследовать свой хвост, пытаясь выяснить, почему другие вещи ломаются в результате. :)

— Натан С

Я ищу способ потушить огонь, но, конечно, я установлю ограничения для других демонов. Это для чрезвычайной ситуации, мне нужно иметь спокойствие, чтобы знать, что у меня всегда будет sshd реагировать на удаленный доступ.

— Ренато Тодоров

@RenatoTodorov в этом случае вы не можете лечить симптом. Если в вашей системе запущен процесс, который потребляет все ресурсы {CPU, RAM, Sockets, PID}, вы не можете гарантировать, что даже niceпреступник будет загружен с CPU достаточно быстро, чтобы обеспечить вам доступ по SSH (или что любой доступ к вашей консоли будет пригоден для использования). Основной вопрос (ресурс-боры) необходимо решать. Пожарная безопасность - плохое управление системой.

— voretaq7

Ну, вы, ребята, убедили меня, я буду использовать iDRAC 7 Express, если он у меня уже есть. Спасибо вам всем!

— Ренато Тодоров

Вашим универсальным решением для этого является инструмент внешнего управления, такой как Dell iDRAC, IBM Remote Supervisor или HP iLO. Он всегда может отображать консоль (зависит от того, может ли ОС на нее реагировать, зависит от вашей конкретной ситуации) и при необходимости применять требуемые состояния питания.

— mfinni
источник

Хорошо, iDRAC - хороший вариант, так как я использую серверы Dell, но я думал о более простом решении, возможно, что-то вроде резервирования процессора для sshd (включая порожденных детей), своего рода «QoS» для локальных сервисов.

— Ренато Тодоров

Некоторые компании терпят крах или жадность: в таком случае sysrqd может быть дешевой альтернативой iDRAC, iLO, KVM ...

— bgtvfr

Я добился некоторого успеха в предоставлении привилегий в реальном времени для sshd, однако это происходит за счет необходимости перезагрузки компьютера, если один из процессов реального времени завершается.

Поэтому, если вы хотите пойти по этому пути, запустите второй демон ssh, предназначенный только для экстренных случаев. :)

— Саймон Рихтер
источник

realtimeМне кажется, что использование sshd опасно, особенно для порта 22 (сканирование SSH может стать DoS-атакой - запуск на альтернативном порту может смягчить это, но я все равно буду бояться ...)

— voretaq7

не проблема, если я заблокирую доступ из интернета, фактически мой единственный маршрут к этому серверу через VPN. Спасибо за предложение!

— Ренато Тодоров