Servidor remoto aleatoriamente pendurado no login do ssh

Question

Vou tentar usar o ssh no servidor

ssh name@box-a

Nesse ponto, normalmente, serei solicitada uma senha e, em seguida, ela será registrada.

Às vezes, porém, quando tento ssh, ele fica travado depois que eu pressiono enter e não me permite inserir minha senha e acessar o servidor. Não há mensagens de erro, apenas trava. Esse problema ocorre para todos os usuários. O problema se corrige se reiniciarmos o servidor.

ssh -vvv name@box-a

retorna

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to box-a [box-a] port 22.
debug1: connect to address box-a port 22: Operation timed out
ssh: connect to host box-a port 22: Operation timed out

-------------------------------- Respostas -------------- ----------------

Eu adicionei a porta ssh em 6022, e quando eu fui expulso agora, quando eu estava editando um arquivo:

Write failed: Broken pipe

Eu então tentei o ssh de volta em

ssh -vvv -p 6022 name@IP-external
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to IP-external [IP-external] port 6022.
debug1: connect to address IP-external port 6022: No route to host
ssh: connect to host IP-external port 6022: No route to host

Além disso, fiz

lastb

E vimos milhares de tentativas de login nos últimos dois dias. Eu acho que isso poderia ser isso. Estou executando o CentOS 6.5. O fail2ban é a melhor opção para mim?

    

Answer 1

Atualize para novas informações:

Eu não começaria com fail2ban , como se não estivesse configurado corretamente, você pode acabar se trancando fora de sua própria caixa.

Em vez disso, eu apenas começaria mudando sua porta em sshd_config para um número de porta mais alto e mudando a senha de login do seu usuário para algo mais strong de 20 caracteres (não esqueça de reiniciar o sshd). E veja se isso reduz suas conexões de login. Se não, sugiro ir a rota mais extrema e configurar o fail2ban. Mas, novamente, tenha muito cuidado e leia atentamente a documentação de configuração.

Eu criaria um segundo serviço sshd em execução em outro número de porta e o deixaria lá até você começar a ter o problema de login. Em seguida, na próxima vez que ocorrer o problema, tente conectar-se a esse outro sshd e veja se você pode encontrar mais informações sobre seu problema.

Crie o sshd de depuração na porta 6022 (você precisa fazer isso porque o sshd original já está em execução na porta 22).

# nohup /usr/sbin/sshd -p 6022 -ddd > ~/sshd.log 2>&1 &

• nohup : executa um comando imune a restrições, com saída para um não-tty
• -p : define o número da porta (neste caso, 6022)
• > ~ / sshd.log 2 > & 1 : redireciona stdout e stderr para ~ / sshd.log
• & : Se um comando for finalizado pelo operador de controle & amp ;, o shell executará o comando em segundo plano em um subshell. O shell não espera que o comando termine e o status de retorno é 0.

Este novo sshd só aceitará uma conexão e terminará depois que a conexão for bem-sucedida.

# ssh -vvv -p 6022 user@remotehostname
[OR]
# ssh -vvv -p 6022 user@remoteIPaddress

Da próxima vez que você sair, poderá ver se:

1. Foi apenas o sshd em execução na porta 22 que foi o problema? O 6022 teve sucesso?
2. Se 22 e 6022 estiverem suspensos, você poderá comparar os logs da saída do servidor -ddd e da saída -vvv do cliente para ver se é possível descobrir mais informações sobre o problema.

Outra coisa que você pode verificar é MTU, eu experimentei algo semelhante antes, quando havia uma falta de correspondência no tamanho da MTU entre o servidor e o cliente. Você deve comparar os dois para ver se há alguma falta de correspondência.

[root ~]# ifconfig            # I removed sensitive information:
eth0      Link encap:Ethernet
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

    

Answer 2

Eu sugeriria:

1. verifique se os clientes fecham suas conexões corretamente - em algumas situações, o servidor pode manter as conexões não fechadas e atinge seus limites ( netstat é seu amigo)
2. verifique se há tentativas de registro com falha. Pode ser que o seu servidor ssh esteja sobrecarregado com algum ataque de força brutal.
3. instale fail2ban - para proibir IPs que façam essas tentativas (ajuste-o para confiar em seus IPs para evitar o bloqueio de si mesmo)
4. verifique se todos os servidores de nomes definidos em /etc/resolv.conf funcionam bem
5. sintonizar sshd

sshd_config deve ter pelo menos:

 Port 57322 # not 22 and some high one - above 1024
 Protocol 2
 UseDNS no # it'll speed-up the connection process a bit (or even a lot if your DNS doesn't work well)

6. execute ifconfig várias vezes e verifique se não há errors ou dropped crescente
7. como @DevNull advices check MTU ( tcpdump é seu amigo aqui, mas será mais fácil defini-lo abaixo e verificar se ele ajuda ou não com ip link set eth0 mtu 1462 pode ajudá-lo se for a VM em interface em ponte - mas você pode definir muito mais baixo para o teste)