Garantizar el acceso SSH en un servidor estresado

Hace un tiempo tuve un problema con un servidor en el que Apache y Snort ocupaban el 100% del procesador, lo que hacía que el sshd no respondiera a través del acceso remoto. Tuve que ir físicamente al servidor para iniciar sesión en un TTY local y luego detener apache / snort.

Me pregunto si hay una manera de garantizar la conectividad ssh en una situación de CPU / memoria 100% cargada. Establecer una "buena" prioridad sería suficiente?

¡Gracias!

linux ssh process-priority Renato Todorov
fuente

Respuestas:

Aparte de usar un método fuera de banda, no hay forma de garantizar que SSH estará disponible en un servidor completamente cargado. Si su servicio está tan cargado que ni siquiera puede servirle un terminal SSH básico, entonces tiene otros problemas.

Sí, renicey darle un nicevalor más bajo mejorará el rendimiento en cargas pesadas, pero en cambio usar algo como pam_security (ejemplo mostrado aquí ) evitará que Apache / lo que sea sea inmanejable para empezar.

Nathan C
fuente

Derecha. Él está tratando de tratar el síntoma, no el verdadero problema.

ewwhite

@ewwhite Exactamente. Y tratar el síntoma solo resultará en perseguir tu cola tratando de descubrir por qué otras cosas se rompen como resultado. :)

Nathan C

Estoy buscando una manera de extinguir el fuego, pero por supuesto estableceré límites para los otros demonios. Esto es para una situación de emergencia, necesito tener la tranquilidad de saber que siempre tendré sshd receptivo para el acceso remoto.

Renato Todorov

@RenatoTodorov en este caso no puede tratar el síntoma. Si su sistema tiene un proceso descontrolado que consume todos los {CPU, RAM, Sockets, PID}, no puede garantizar que incluso un niceculpable sea arrancado de la CPU lo suficientemente rápido como para garantizar que tenga acceso SSH (o para el caso cualquier acceso a la consola que tenga sería utilizable). El problema subyacente (recurso-cerdo) necesita ser abordado. La lucha contra incendios es una mala gestión del sistema.

voretaq7

Bueno, ustedes me convencieron, usaré iDRAC 7 Express siempre que ya lo tenga. ¡Gracias a todos!

Renato Todorov

Su solución de uso general para esto es una herramienta de administración fuera de banda, como Dell iDRAC, IBM Remote Supervisor o HP iLO. Siempre puede presentar una consola (si el sistema operativo puede responder o no depende de su situación específica) y aplicar los estados de potencia deseados según sea necesario.

mfinni
fuente

Ok, iDRAC es una buena opción ya que estoy usando servidores Dell, pero estaba pensando en una solución más simple, tal vez algo como reservar CPU para sshd (incluidos sus hijos engendrados), algún tipo de "QoS" para servicios locales.

Renato Todorov

Algunas empresas están en quiebra o avaricia: en tal caso, sysrqd puede ser una alternativa barata a iDRAC, iLO, KVM ...

bgtvfr

He tenido cierto éxito al otorgar privilegios en tiempo real al sshd, sin embargo, eso tiene el costo de reiniciar la máquina si uno de los procesos en tiempo real se escapa.

Entonces, si desea seguir esta ruta, comience un segundo demonio ssh que sea solo para emergencias. :)

Simon Richter
fuente

realtimeInsh sshd me parece peligroso, particularmente en el puerto 22 (un escaneo SSH podría convertirse en un ataque DoS; ejecutarlo en un puerto alternativo puede mitigar eso, pero aún estaría asustado ...)

voretaq7

No es un problema si bloqueo el acceso desde Internet, en realidad mi única ruta a este servidor es a través de VPN. ¡Gracias por la sugerencia!

Renato Todorov