Garantindo o acesso SSH em um servidor estressado

Há algum tempo, tive um problema com um servidor no qual o Apache e o Snort ocupavam 100% do processador, tornando o sshd sem resposta através do acesso remoto. Eu tive que ir fisicamente ao servidor para fazer logon em um TTY local e parar o apache / snort.

Gostaria de saber se existe uma maneira de garantir a conectividade ssh em uma situação de CPU / memória 100% carregada. Definir uma prioridade "boa" seria suficiente?

Obrigado!

linux ssh process-priority

— Renato Todorov
fonte

Respostas:

Além de usar um método fora de banda, não há como garantir que o SSH estará disponível em um servidor totalmente carregado. Se o seu serviço estiver tão carregado que nem sequer lhe servirá um terminal SSH básico, você terá outros problemas.

Sim, renicee atribuir um nicevalor mais baixo melhorará o desempenho em cargas pesadas, mas, em vez disso, usar algo como pam_security (exemplo mostrado aqui ) impedirá que o Apache / o que quer que seja se torne incontrolável para começar.

— Nathan C
fonte

Certo. Ele está tentando tratar o sintoma, não o problema real.

— ewwhite

@ewwhite Exatamente. E tratar o sintoma resultará apenas em perseguir seu rabo, tentando descobrir por que outras coisas quebram como resultado. :)

— Nathan C

Estou procurando uma maneira de extinguir o fogo, mas é claro que vou estabelecer limites para os outros daemons. Isso é para uma situação de emergência, preciso ter a tranqüilidade de saber que sempre terei o sshd responsivo ao acesso remoto.

— Renato Todorov 03/09

@RenatoTodorov, neste caso, você não pode tratar o sintoma. Se o seu sistema possui um processo descontrolado que consome todos os recursos (CPU, RAM, Sockets, PIDs), você não pode garantir que mesmo um niceculpado seja inicializado da CPU com rapidez suficiente para garantir que você tenha acesso SSH (ou, nesse caso, qualquer acesso ao console que você tiver poderá ser utilizado). O problema subjacente (recurso-porco) precisa ser resolvido. Combate a incêndios é uma má gestão do sistema.

— precisa saber é o seguinte

Bem, vocês me convenceram, eu vou usar o iDRAC 7 Express enquanto eu já o tiver. Obrigado a todos!

— Renato Todorov

Sua solução de uso geral para isso é uma ferramenta de gerenciamento fora de banda, como Dell iDRAC, IBM Remote Supervisor ou HP iLO. Ele sempre pode apresentar um console (se o sistema operacional pode ou não responder a ele depende da sua situação específica) e aplicar os estados de energia desejados, conforme necessário.

— mfinni
fonte

Ok, o iDRAC é uma boa opção, pois estou usando servidores Dell, mas estava pensando em uma solução mais simples, talvez algo como reservar CPU para sshd (incluindo filhos gerados), algum tipo de "QoS" para serviços locais.

— Renato Todorov

Algumas empresas estão quebrados ou ganância: neste caso uma, sysrqd pode ser uma alternativa barata para iDRAC, OIT, KVM ...

— bgtvfr

Eu tive algum sucesso ao conceder privilégios em tempo real ao sshd, no entanto, isso implica o custo de ter que reiniciar a máquina se um dos processos em tempo real se esgotar.

Portanto, se você quiser seguir esse caminho, inicie um segundo daemon ssh que seja apenas para emergências. :)

— Simon Richter
fonte

realtimeing sshd parece perigoso para mim, particularmente na porta 22 (uma varredura SSH poderia tornar-se um ataque DoS - rodando em uma porta alternativa pode atenuar isso, mas eu ainda estaria com medo ...)

— voretaq7

não é um problema se eu bloquear o acesso da Internet, na verdade, minha única rota para esse servidor é através da VPN. obrigado pela sugestão!

— Renato Todorov