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

15

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.

Tom Brossman
fonte
Eu tenho um problema semelhante, mas em um contexto muito diferente. Parece que algo mudou, mas não consigo descobrir o que. Sei que há mudanças no udev, mas não vejo exatamente como isso importaria, porque a rede parece estar funcionando corretamente de outra forma. Apenas sshd é problemático.
Jo-Erlend Schinstad
11
@ Jo-ErlendSchinstad Passei duas horas hoje testando isso com servidores da AWS, DigitalOcean e OVH e posso reproduzi-lo 100% do tempo. 12.04 = ok, 14.04 = sem SSH após a reinicialização. Se isso fosse um bug, espero que possamos ouvir muitos outros bloqueados em seus servidores! Espero estar ignorando algo, mas com uma nova instalação + login SSH único para reiniciar, não há muito espaço para erro humano aqui. Acabei de testá-lo agora no meu laptop 14.04 (caso isso fosse uma coisa de 12.04) e nenhuma alteração, mesmo resultado. Realmente espero que descobrir isso em breve ...
Tom Brossman
11
Ah, eu tenho muitos servidores executando o sshd sem nenhum problema. Este é o problema ao qual me referi: askubuntu.com/questions/479448/…
Jo-Erlend Schinstad

Respostas:

17

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.

Benoit
fonte
Obrigado por esta resposta mais interessante! Vou testar tudo isso agora, pois estou em um servidor dedicado (não um VPS), mas tive o problema nos dois tipos - desde que 14.04 e 12.04 não. sudo reboot nowfunciona perfeitamente em 12.04 e uptimecorresponde à última vez que o faço. Mudança muito interessante para 14.04.
18714 Tom Brossman
11
tendo exatamente o mesmo problema após a atualização do servidor para 14.04.1, e a reinicialização não resolve.
precisa
Isso consertou para mim. Teve que reiniciar manualmente o servidor. Uau, isso é super chato! Por que diabos agora seria igual ao modo de usuário único? Que escolha idiota. Por que não sudo reboot --single-userobter essa funcionalidade ???
Jcollum
2

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.

tama
fonte
Muito útil - no meu caso, eu digitei um caractere incorreto no início do arquivo. Muito misterioso, como nenhum erro é gerado se houver um problema na configuração e tudo parece começar, mesmo que não haja nenhum processo em execução.
Andrew Mao
2

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)
John Rix
fonte
-1

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.

Michal Ambroz
fonte