O que causa problemas de SSH após a reinicialização de um servidor 14.04?

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

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

Para tornar a pergunta mais clara, eis o que funciona ou não para mim:

• SSH em uma nova instalação do 12.04> logout> SSH in again> works
• SSH em uma nova instalação do 12.04> reboot> SSH in again> works
• SSH em uma nova instalação do 14.04> logout> SSH in again> works
• SSH em uma nova instalação do 14.04> reiniciar> SSH novamente> Conexão recusada

O problema que estou enfrentando é exclusivo da 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 no qual quero usar o 14.04 e quero entender o que está acontecendo de errado. Alguma sugestão?

Aqui está o que eu tentei até agora:

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

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

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

Parece que o ssh no servidor 14.04 está definido para iniciar na inicialização (conforme o 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 criada recentemente . Eu o criei, SSH'd no reboot nowcomando & emitido , e recebi um erro de conexão recusada depois de esperar pela reinicialização e tentar fazer o SSH pela segunda vez. Reinicialização total via painel de controle de hospedagem e agora a conexão SSH funciona novamente.

Resposta rápida:

SSH não é o problema. O comando que você usa para reiniciar é o problema: não faça reboot now, faça rebootou shutdown -r nowreinicie o sistema.

A sintaxe do comando ( desde 13.04 ) tem sido:

reboot [OPTION]...  [REBOOTCOMMAND]

O REBOOTCOMMANDnunca existiu antes. Na versão 12.04, você nowfoi ignorado, mas agora está sendo usado ... E está quebrando tudo.

Resposta longa, com meus resultados de testes e explicação:

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

Como você, emiti o comando reboot nowdo console (conectado usando SSH). Alguns segundos depois de pressionar RETURN, minha sessão é desconectada automaticamente. Como você, nunca consegui me reconectar ao servidor via SSH depois de emitir este comando.

Então, decidi abrir o console KVM fornecido pela OVH. (emulando o acesso direto usando o teclado e a tela em um servidor físico para esse tipo de servidor virtual).

Consegui conectar-me à minha máquina e vi que ela estava entrando no modo de usuário único, esperando eu pressionar CTRL+ Dpara continuar ou inserir a senha raiz para entrar no modo de manutenção. Eu pressionei a combinação de teclas para continuar o processo e, em seguida, consegui fazer o SSH no meu sistema novamente. Qual foi minha surpresa ao ver, após a execução uptime, que o tempo de atividade não era de 2 ou 3 minutos, mas ainda muito dia: reboot nowexecutado dentro de um Ubuntu 14.04 VPS não está realmente reiniciando, mas apenas pedindo para entrar no modo de Usuário Único!

Com isso, aprendi a nunca solicitar uma reinicialização no meu VPS, mas solicitá-la a partir do comando fornecido na interface de gerenciamento do hoster.

Portanto, não há nenhum problema com a 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, sem opção), teria feito o que você pretendia: reiniciar o servidor.

Usando rebootcom um argumento (na página de manual) chame o comando shutdowncom os argumentos fornecidos. E, de fato, se eu executar shutdown now, tenho o mesmo comportamento: o sistema não é reiniciado, entra no modo de usuário único.

Observação: parece que é o comportamento pretendido, pois a mensagem que aparece na tela depois de pressionar a execução deste comando diz algo como:

O sistema será levado ao modo de manutenção

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 nowinterromper o sistema agora ou shutdown -r nowreiniciá-lo agora. Eu não sabia que shutdown nowapenas traria o sistema para o modo de usuário único. Eu costumo fazer init Spara conseguir isso.

Posso estar atrasado, e 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 startou qualquer outra combinação mostrou que o serviço estava sendo executado mesmo que não estivesse, mas se eu iniciar o executável com seu caminho absoluto (no meu caso /usr/sbin/sshd), vi que havia um "0B" anexado no final do arquivo de configuração que causava um erro ao iniciar, removê-lo resolveu o problema.

Outra causa potencial é ufwperder a configuração da regra de porta SSH. Isso ocorreu-me em pelo menos uma ou duas ocasiões, onde, após aplicar atualizações e reinicializações, a configuração do firewall estava me impedindo de obter acesso ao servidor. Usar o recurso de console VPS do meu provedor de hospedagem me permitiu entrar na máquina e diagnosticar 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)

Reativar a porta da seguinte maneira faz o truque:

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

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

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

No meu caso, o upstart não inicia por causa da minha configuração específica:

Havia uma configuração correta /etc/init/ssh.conf, mas também havia um /etc/init/ssh.overridearquivo contendo manual, o que significa que sshé esperado que seja iniciado manualmente.

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

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