Meu VPS não foi reiniciado por cerca de 3 meses. Está hospedado em um servidor com o tipo de virtualização OpenVZ e o sistema operacional é o Ubuntu 16.04. Por alguma razão, reiniciei o VPS e, depois disso, não consegui me conectar ao servidor através do ssh, a mensagem que recebi é:
ssh: connect to host srvname.com port 22: Connection refused
Então, eu abri um console serial no VPS e comecei a investigar ... Eu limpei e reinstalei o openssh-server
sem sucesso. Passei duas horas lendo artigos, perguntas e respostas sobre problemas semelhantes na Internet.
Finalmente, consegui entender que o diretório /var/run/sshd
não é criado durante a inicialização do sistema. E depois que eu o crio manualmente, posso iniciar o serviço SSH sem nenhum problema, mas na próxima reinicialização o problema permanece. Então, minhas perguntas são:
Qual poderia ser a causa desse problema? Por que
/var/run/sshd
não é criado durante a inicialização do sistema?Como posso resolver o problema de maneira adequada? Encontrei uma solução temporal mencionada no final deste post.
O problema pode estar relacionado ao host OpenVZ do VPS? Devo pedir ao provedor de hospedagem para resolvê-lo?
A saída de systemctl status ssh.service
, sshd -Ddp 22
e journalctl -xe
é:
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: failed (Result: start-limit-hit) since вт 2019-01-15 12:58:08 EET; 22s ago
Process: 407 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255)
яну 15 12:58:07 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
яну 15 12:58:07 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 12:58:07 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 12:58:08 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Start request repeated too quickly.
яну 15 12:58:08 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Failed with result 'start-limit-hit'.
# $(which sshd) -Ddp 22
debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: private host key #0: ssh-rsa SHA256:...
debug1: private host key #1: ssh-dss SHA256:...
debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:...
debug1: private host key #3: ssh-ed25519 SHA256:...
Missing privilege separation directory: /var/run/sshd
# journalctl -xe
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit ssh.service has begun starting up.
яну 15 13:21:21 srvname sshd[1688]: Missing privilege separation directory: /var/run/sshd
яну 15 13:21:21 srvname systemd[1]: ssh.service: Control process exited, code=exited status=255
яну 15 13:21:21 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit ssh.service has failed.
--
-- The result is failed.
яну 15 13:21:21 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:21 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 13:21:22 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit ssh.service has finished shutting down.
яну 15 13:21:22 srvname systemd[1]: Starting OpenBSD Secure Shell server...
-- Subject: Unit ssh.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit ssh.service has begun starting up.
яну 15 13:21:22 srvname sshd[1691]: Missing privilege separation directory: /var/run/sshd
яну 15 13:21:22 srvname systemd[1]: ssh.service: Control process exited, code=exited status=255
яну 15 13:21:22 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit ssh.service has failed.
--
-- The result is failed.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 13:21:22 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit ssh.service has finished shutting down.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Start request repeated too quickly.
яну 15 13:21:22 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit ssh.service has failed.
--
-- The result is failed.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Failed with result 'start-limit-hit'.
O conteúdo de /usr/lib/tmpfiles.d/sshd.conf
e /etc/init/ssh.conf
é:
# cat /usr/lib/tmpfiles.d/sshd.conf
d /var/run/sshd 0755 root root
# cat /etc/init/ssh.conf | sed '/^#/ d'
description "OpenSSH server"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
respawn limit 10 5
umask 022
env SSH_SIGSTOP=1
expect stop
console none
pre-start script
test -x /usr/sbin/sshd || { stop; exit 0; }
test -e /etc/ssh/sshd_not_to_be_run && { stop; exit 0; }
mkdir -p -m0755 /var/run/sshd
end script
exec /usr/sbin/sshd -D
Informações adicionais sobre o sistema:
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.5 LTS
Release: 16.04
Codename: xenial
# uname -a
Linux srvname 2.6.32-042stab127.2 #1 SMP Thu Jan 4 16:41:44 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux
# apt show openssh-server | grep 'Version'
Version: 1:7.2p2-4ubuntu2.6
A solução temporal:
descobri que /var/run
é um link simbólico para /run
, não sei por que isso é necessário, mas quando modifiquei o conteúdo do arquivo /usr/lib/tmpfiles.d/sshd.conf
de:
d /var/run/sshd 0755 root root
para:
d /run/sshd 0755 root root
tudo corre bem na inicialização do sistema, o serviço SSH é iniciado normalmente e eu consigo fazer login via SSH.
Respostas:
Descobri que esse é um erro da versão atual do systemd e dos kernels antigos que são usados por alguns privilégios do VPS, como no meu caso. Este bug aparece de tempos em tempos, como podemos ver no Launchpad: Bug # 45234 , Bug # 1811580 ; ou no ServerFault: Por que estou ausente / var / run / sshd após cada inicialização?
Existem algumas soluções alternativas para esse problema, todas elas se reúnem para criar formas alternativas
/var/run/sshd
antes de executar o servidor SSH. Aqui estão três soluções possíveis.Solução alternativa 1: modifique
/usr/lib/tmpfiles.d/sshd.conf
da seguinte maneira:Como é mencionado na pergunta,
/var/run
é um link simbólico para/run
, o resultado final é idêntico:/var/run/sshd
é criado. Não sei por que, mas isso funciona.Solução 2: use o trabalho Cron que criará
/var/run/sshd
e reiniciará o servidor SSH; você pode usar o rootcrontab
para esse fim - executesudo crontab -e
e adicione a seguinte entrada:Atualmente estou usando esta solução, por isso também é testada.
Solução alternativa 3: use
/etc/rc.local
o mesmo procedimento acima, conforme mostrado neste comentário no relatório de bug # 45234.fonte
systemd-tmpfiles --create
mostram, porque no momento não há nenhum mau funcionamento sensível no servidor. Em geral, o A pergunta atual é sobre como obter o serviço SSH operacional após a reinicialização enquanto o problema está envolvido.Se desejar, você pode/usr/lib/tmpfiles.d/sshd.conf
do que modificá-lo diretamente, pois esse arquivo é gerenciado pelo gerenciador de pacotes. Para fazer isso, basta fazer a alteração/etc/tmpfiles.d/sshd.conf
; isso terá precedência sobre osshd.conf
in/usr/lib
. Veja esta seção em tmpfiles.d (5) . Ótima resposta, independentemente de estar em um OpenVZ VPS é exatamente a situação em que encontrei isso./var/run
link simbólico, que é o quesystemd-tmpfiles
está com problemas e o motivo pelo qual o diretório PrivSep não está sendo criado. A quarta quarta mensagem deste tópico lança alguma luz sobre isso. É verdade,systemd-tmpfiles-clean
mas tenho a sensação de que a mesma coisa se aplica aqui.Você poderia verificar se suas
/
permissões (sistema de arquivos raiz) não foram alteradas? Tem que serroot:root
como as duas linhas abaixo:Se o proprietário for outro usuário (e não root), isso impedirá a criação de todos os arquivos temporários pelo systemd durante a inicialização do sistema. Você também pode verificar com o comando:
Se a pasta raiz (
/
) tiver permissão diferente, altere-a com o seguinte comando:fonte
Obrigado a todos por informações úteis. O problema com o ssh-server no meu Xenial Lubuntu estava de fato relacionado à propriedade '/', como sugerido por Melebius & Stefan.
Criando
/var/run/sshd
e reiniciando manualmente ssh.service temporariamente ssh-server temporariamente. A edição dosshd.conf
não ajudou neste sistema. Depois da última sugestão, verifiquei a propriedade da pasta raiz com:'
ls -alF /
' e, com certeza, foi acidentalmente alterado para um usuário / grupo local. Emissão a partir do terminal: 'sudo chown root:root /
' corrigiu meu sistema, independentemente da edição emsshd.conf
. Então eu restaurei isso ao seu estado original, ied /var/run/sshd 0755 root root
.fonte
Estou tendo esse problema na minha máquina quando estou executando várias instâncias do sshd em uma única máquina (18.04.02 LTS, OpenSSH 7.6p1).
O problema é que não há opções no sshd (ou seja, linha de comando ou
sshd_config
arquivo) provisionadas para alterar a localização do "diretório de separação de privilégios". O diretório deve estar no diretório/var/empty
, de acordo com o código-fonte do OpenSSH 7.6p1.O pacote Ubuntu reformulou isso para
/run/sshd
.Há um problema de "segurança de thread" nos
init.d
scripts na inicialização quando os dois scripts de serviço tentam criar o diretório. Eu pedi ao Ubuntu e ao OpenSSH para resolver a questão dos nomes de caminho codificados no "diretório de separação de privilégios" no sshd. Se eu pudesse fazer upload de arquivos, eu o corrigi com base no código-fonte 8.0p1 OpenSSH.fonte