Garantir l'accès SSH sur un serveur stressé

Il y a quelque temps, j'ai eu un problème avec un serveur dans lequel Apache et Snort occupaient 100% du processeur, ce qui rend le sshd insensible via l'accès à distance. Je devais me rendre physiquement sur le serveur pour me connecter à un ATS local puis arrêter apache / snort.

Je me demande s'il existe un moyen de garantir la connectivité ssh dans une situation de CPU / mémoire chargée à 100%. Fixer une priorité "sympa" serait-il suffisant?

Je vous remercie!

linux ssh process-priority

— Renato Todorov
source

Réponses:

Outre l'utilisation d'une méthode hors bande, il n'y a aucun moyen de garantir que SSH sera disponible sur un serveur entièrement chargé. Si votre service est tellement chargé qu'il ne peut même pas vous servir un terminal SSH de base, vous avez d'autres problèmes.

Oui, reniceet lui donner une nicevaleur inférieure améliorera les performances dans des charges lourdes, mais à la place, utiliser quelque chose comme pam_security (exemple illustré ici ) empêchera Apache / que ce soit de devenir ingérable pour commencer.

— Nathan C
source

Droite. Il cherche à traiter le symptôme, pas le vrai problème.

— ewwhite

@ewwhite Exactement. Et le traitement du symptôme se traduira simplement par la poursuite de votre queue en essayant de comprendre pourquoi d' autres choses se cassent en conséquence. :)

— Nathan C

Je cherche un moyen d'éteindre le feu mais bien sûr je vais fixer des limites pour les autres démons. C'est pour une situation d'urgence, j'ai besoin d'avoir la tranquillité de savoir que je vais toujours avoir sshd réactif pour l'accès à distance.

— Renato Todorov

@RenatoTodorov dans ce cas, vous ne pouvez pas traiter le symptôme. Si votre système a un processus galopant qui consomme tout {CPU, RAM, Sockets, PID}, vous ne pouvez pas garantir que même un nicecoupable sera démarré du CPU assez rapidement pour vous assurer d'avoir un accès SSH (ou d'ailleurs que tout accès à la console dont vous disposez serait utilisable). Le problème sous-jacent (ressource-porc) doit être résolu. La lutte contre les incendies est une mauvaise gestion du système.

— voretaq7

Eh bien, vous m'avez convaincu, je vais utiliser iDRAC 7 Express tant que je l'ai déjà. Merci à tous!

— Renato Todorov

Votre solution polyvalente pour cela est un outil de gestion hors bande, comme Dell iDRAC, IBM Remote Supervisor ou HP iLO. Il peut toujours présenter une console (que le système d'exploitation puisse y répondre ou non dépend de votre situation spécifique) et appliquer les états d'alimentation souhaités selon les besoins.

— mfinni
source

Ok, iDRAC est une bonne option car j'utilise des serveurs Dell mais je pensais à une solution plus simple, peut-être quelque chose comme réserver le CPU pour sshd (y compris ses enfants générés), une sorte de "QoS" pour les services locaux.

— Renato Todorov

Certaines entreprises sont ruinées ou cupides: dans un tel cas, sysrqd peut être une alternative bon marché à iDRAC, iLO, KVM ...

— bgtvfr

J'ai eu un certain succès en accordant des privilèges en temps réel à sshd, mais cela se fait au prix du redémarrage de la machine si l'un des processus en temps réel s'épuise.

Donc, si vous voulez emprunter cette voie, démarrez un deuxième démon ssh uniquement pour les urgences. :)

— Simon Richter
source

realtimeing sshd me semble dangereux, en particulier sur le port 22 (un scan SSH pourrait devenir une attaque DoS - s'exécuter sur un autre port peut atténuer cela, mais j'aurais quand même peur ...)

— voretaq7

ce n'est pas un problème si je bloque l'accès à Internet, en fait mon seul chemin vers ce serveur est via VPN. Merci pour la suggestion!

— Renato Todorov