O que causa problemas de SSH após reinicializar um servidor 14.04?

Question

Por que reiniciar um servidor executando o Ubuntu 14.04 me fornece erros de 'Conexão recusada'?

Eu vejo ssh: connect to host <IP-address-here> port 22: Connection refused , mas apenas para 14.04 e somente após a reinicialização. Estou usando 12.04 Desktop em casa. Como faço para solucionar isso?

Para tornar a questão mais clara, veja o que funciona ou não para mim:

• SSH em uma nova instalação de 12.04 > logout > SSH novamente > trabalha
• SSH em uma nova instalação de 12.04 > reboot > SSH novamente > trabalha
• SSH em uma nova instalação de 14.04 > logout > SSH novamente > trabalha
• SSH em uma nova instalação de 14.04 > reboot > SSH novamente > Conexão recusada

O problema que estou tendo é exclusivo para o 14.04, e só acontece após a reinicialização. Eu tenho vários servidores rodando 12.04 antes disso e tudo ainda funciona perfeitamente. Eu tenho um novo servidor que eu quero usar 14.04 e eu quero entender o que está errado. Alguma sugestão?

Veja o que tentei até agora:

sudo traceroute -p 22 -T <IP-address-here>

Traceroute funciona bem, recebo uma resposta do servidor na porta 22 do SSH.

initctl list
...
ssh start/running, process 23371
...

Parece que o ssh no servidor 14.04 está configurado para iniciar na inicialização (conforme esperado).

tom@Desktop:~$ ssh -vvv root@<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to host <IP-address-here> port 22: Connection refused

Edit: Aqui está o syslog inteiro de uma máquina recém-criada . Eu criei, SSH em & amp; Emitiu o comando reboot now , em seguida, obteve um erro de conexão recusada depois de esperar pela reinicialização e pela tentativa de SSH na segunda vez. Hard reboot via painel de controle de hospedagem e agora a conexão SSH funciona novamente.

    

Answer 1

Resposta rápida:

O SSH não é o problema. O comando que você usa para reinicializar é o problema: não use reboot now , do reboot ou shutdown -r now para reinicializar o sistema.

A sintaxe do comando ( desde 13.04 ) foi:

reboot [OPTION]...  [REBOOTCOMMAND]

O REBOOTCOMMAND nunca existiu antes. Em 12.04, seu now foi ignorado, mas agora está sendo usado ... E está quebrando tudo.

Resposta longa, com os resultados e a explicação dos meus testes:

Eu tenho um problema semelhante com alguns servidores rodando 14.04 AND em VPS (hospedado no provedor francês OVH - rodando o OpenVZ) E ao fazer reboot now dentro do próprio servidor.

Como você, eu emiti o comando reboot now do console (conectado usando SSH). Alguns segundos depois que pressionei RETURN , minha sessão será desconectada automaticamente. Como você, nunca consegui me reconectar ao servidor via SSH depois de emitir este comando.

Por isso, decidi abrir a consola KVM fornecida pela OVH. (emulando o acesso direto usando teclado e tela em um servidor físico para esse tipo de servidor virtual).

Consegui conectar-me a minha máquina e vi que ela estava entrando no modo de usuário único, esperando que eu pressionasse CTRL + D para continuar ou para entrar a senha do root para entrar no modo de manutenção. Pressionei a combinação de teclas para deixar o processo continuar e depois consegui acessar o SSH no meu sistema novamente. Qual foi o meu surpise para ver, depois de executar uptime , que o tempo de atividade não foi 2 ou 3 minutos, mas ainda um monte de dia: reboot now executado dentro de um Ubuntu 14.04 VPS não está realmente reiniciando mas está apenas pedindo para entrar em Single Modo de usuário!

A partir disso, aprendi a nunca pedir uma reinicialização de dentro do meu VPS, mas solicitá-lo a partir do comando fornecido na interface de gerenciamento do hoster.

Portanto, não há problemas com a sua instalação do SSH. O problema é quando você digita reboot now . Na verdade, eu testei depois também, se você tivesse digitado reboot (apenas a palavra, nenhuma opção), ele teria feito o que você pretendia fazer: reinicializar o servidor.

Usando reboot com um argumento (da página man) chame o comando shutdown com os argumentos dados. E, de fato, se eu executar shutdown now , eu tenho o mesmo comportamento: o sistema não é reinicializado, ele entra no modo de usuário único.

Observação: parece que é o comportamento pretendido quando a mensagem que aparece na tela depois de executar esse comando diz algo como:

% bl0ck_qu0te%

Modo de manutenção ou modo de usuário único, isso representa o mesmo, um nível de execução com mais de um shell, nenhuma rede, nenhum processo de rede, ...

Isso pode ser confuso, mas observe que o uso correto de shutdown é, por exemplo: shutdown -h now para interromper o sistema agora ou shutdown -r now para reinicializá-lo agora. Eu não sabia que shutdown now só traria o sistema para o modo de usuário único. Eu costumo fazer init S para conseguir isso.

    

Answer 2

Eu posso estar atrasado, e isso pode ser óbvio, mas o que funcionou para mim foi verificar o arquivo de configuração /etc/ssh/sshd_config : a execução do daemon com /etc/init.d/ssh start ou qualquer outra combinação mostrou que o serviço estava em execução, embora fosse não, mas se eu lanço o executável com seu caminho absoluto (no meu caso /usr/sbin/sshd ) eu vi que havia um "0B" anexado no final do arquivo de configuração que causou um erro ao iniciar, removendo-o resolveu o problema.

    

Answer 3

Outra causa potencial é ufw perder a configuração da regra de porta SSH. Isso me ocorreu em pelo menos uma ou duas ocasiões, onde depois de aplicar atualizações e reinicializar, a configuração do firewall estava me impedindo de acessar o servidor. Usar o recurso de console VPS do provedor de hospedagem permitiu que eu entrasse na máquina e diagnosticasse o problema. Exemplo abaixo mostrando o problema (ou seja, nenhuma entrada para a porta 22):

user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
    Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
143                        ALLOW IN    Anywhere
110                        ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
143 (v6)                   ALLOW IN    Anywhere (v6)
110 (v6)                   ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)

Ativar novamente a porta da seguinte maneira:

user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)

    

Answer 4

Para o meu sistema, o problema era que o script de inicialização ssh /etc/init.d/ssh era o único que verificava a presença da versão inicial do init.

Portanto, /etc/init.d/ssh não inicia ssh, porque acredita que será iniciado por upstart .

No meu caso, o upstart não inicia devido à minha configuração específica:

Havia uma configuração correta em /etc/init/ssh.conf , mas também havia um arquivo /etc/init/ssh.override contendo manual , o que significa que ssh deve ser iniciado manualmente.

Este arquivo foi criado pelo script de instalação get-remnux.sh .

Iniciar manualmente ou remover o arquivo /etc/init/ssh.override resolve o problema.