O SSH é redefinido para a porta padrão na reinicialização


12

Mudei de porta SSH padrão no meu servidor de casa (no /etc/ssh/sshd_configarquivo) para a porta 54747, em seguida, reiniciado o sshe sshdserviços (nunca tem certeza qual deles assim que eu fiz tanto apenas para ser seguro). Para testar minha configuração, efetuei logout e, em seguida, voltei a entrar sem nenhum problema.

Alguns dias depois, instalei as atualizações do apt e reiniciei o servidor. Quando tentei voltar a SSH (na porta 54747), recebi um erro de conexão recusada.

Por alguma razão, tentei fazer o SSH na porta padrão e funcionou! Voltei para verificar o sshd_config, mas ele ainda tinha a porta personalizada. Então, reiniciei os serviços sshe sshd, e ele voltou ao comportamento "regular" (ssh na porta 54747). Tentei reiniciar novamente e a conexão foi recusada novamente ...

Alguém sabe o que eu fiz de errado?

Detalhes adicionais:

  • Ubuntu 16.04.2 LTS
  • O servidor também usa um HTPC, com uma sessão aberta (mesmo usuário que SSH) na minha TV
  • Eu SSH usando a chave RSA do meu laptop e desabilitei a autenticação de senha
  • Eu costumava reiniciar com sudo reboot -h now, mas depois de pesquisar, descobri que isso era desencorajado por algumas pessoas, então tentei sudo reboot, mas não houve diferenças

EDIT Sequência de eventos:

  1. Altere a porta SSH de 22 para 54747 em /etc/ssh/sshd_config
  2. Reinicie os serviços ssh e sshd
  3. Terminar sessão SSH atual
  4. SSH de volta com sucesso na porta 54747
  5. Reiniciar
  6. Erro de conexão SSH na porta 54747, mas com êxito na porta 22
  7. Reinicie os serviços ssh e sshd
  8. SSH de volta com sucesso na porta 54747, erro de conexão na porta 22
  9. Reinicie e volte para 6

EDIT 1: netstat saída

rgo@ATLAS:~$ sudo netstat -lntp | grep :54747
rgo@ATLAS:~$ sudo netstat -lntp | grep :22
tcp6       0      0 :::22                   :::*                    LISTEN      1/init  

EDIT 2: service sshd status

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

EDIT 3: lsof -i | grep ssh

systemd      1     root   46u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
systemd      1     root   49u  IPv6  14641      0t0  TCP *:ssh (LISTEN)
sshd      4088     root    3u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4088     root    4u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4202      rgo    3u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4202      rgo    4u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)

Para referência, ATLAS é o nome do host do servidor remoto, 192.168.1.27 é o IP da LAN do meu laptop e o comando foi executado entre as etapas 6 e 7

ufw status

Status: inactive

EDIT 4: ps -ef |grep sshd

root      4088     1  0 22:40 ?        00:00:00 sshd: rgo [priv]
rgo       4202  4088  0 22:40 ?        00:00:00 sshd: rgo@pts/1 sshd

Não estou menosprezando você. Mas parece-me que você não está inserindo os comandos no servidor ssh conforme solicitado. Você não pode ter conexões ssh ativas quando o daemon ssh está morto ....... no servidor ssh, ps -ef | grep sshd deve retornar o processo / usr / sbin / sshd -D. Existem várias pessoas ajudando, mas enviando você em todas as direções diferentes. É um prazer conversar com você no IM, se isso for útil para você.
jones0610

Talvez seja porque eu já tenho uma sessão com o mesmo usuário aberta e exibida na minha TV com o Kodi?
3rgo

Olá, @ 3rgo, você conseguiu resolver isso?
pa4080 17/06/19

Oi ! Não, eu ainda estou enfrentando esse problema ... Felizmente, eu não tenho que reiniciar o meu servidor de casa de vez em quando, mas ainda é uma dor, porque rompe alguns dos meus processos automatizados ...
3rgo

Eu tenho algumas idéias. (1) Você pode tentar alterar a porta para o valor padrão e reiniciar o sistema inteiro. Em seguida, tente alterá-lo novamente para o valor desejado. (2) Tente com um valor diferente, por exemplo Port 10285. O Google mostra alguns resultados para 54747 ... (3) Além disso, o servidor SSH pode trabalhar com várias portas simultaneamente. Crie duas diretivas separadas para cada porta: Port 22e Port 54747, em seguida, abra apenas a segunda no firewall. (4) Você pode tentar a Match LocalPortdiretiva , colocada no início de sshd_c.
pa4080

Respostas:


2

O ssh pode ser "ativado por soquete" pelo systemd, dependendo da configuração, o que significa que inicialmente é o systemd que configura a porta de atendimento e o sshd é iniciado apenas quando um cliente se conecta pela primeira vez. Isso é para acelerar o tempo de inicialização: os daemons de serviço são iniciados somente sob demanda.

No entanto, isso significa que você também deve configurar o systemd na porta correspondente. Você encontrará a configuração do sistema em /lib/systemd/system/ssh.socketquais listas ListenStream=22. Para substituir isso, crie um arquivo /etc/systemd/system/ssh.socket.d/port.conf(criando o diretório, ssh.socket.dse necessário) que contenha:

[Socket]
ListenStream=
ListenStream=54747

Mude o número para a porta desejada. A primeira entrada em branco apaga o padrão anterior e a entrada subseqüente adiciona a nova. Isso substitui o padrão enviado /lib/systemd/system/ssh.sockete deve ser feito além da alteração /etc/ssh/sshd_config.

Em seguida, execute sudo systemctl daemon-reloadpara informar o systemd sobre suas alterações e sudo systemctl reload sshse o seu daemon ssh estava em execução anteriormente.


Essa resposta parece muito promissora, mas /etc/systemd/system/ssh.socket.d/port.confestá sendo ignorada e a reinicialização ainda redefine a porta para 22. O nome do arquivo é relevante? Não é possível encontrar boa documentação sobre substituições systemd no Ubuntu .
MestreLion 25/07/19

O nome do arquivo não importa, desde que termine .conf. Veja systemd-system.conf (5) para obter detalhes sobre os arquivos de configuração de substituição do systemd.
Robie Basak

Além disso, você pode executar systemctl status ssh.socketpara ver se está ativado e o que está ouvindo.
Robie Basak

2
Isso funciona!!! Finalmente, esse mistério está resolvido! Mas depois percebi que era possível acessar usando as duas portas: a padrão 22 e a personalizada. A adição de uma ListenStream=linha antes da porta personalizada evitou isso, não sei por quê. Talvez isso "limpe" a ListenStream=22configuração no padrão /lib/systemd/system/ssh.socket? Maneira estranha de substituir configurações. Talvez valha a pena adicionar isso à resposta?
MestreLion 25/07/19

@MestreLion ah sim, está correto. Vou atualizar a resposta. Obrigado!
Robie Basak

0

Verifique suas configurações de porta no /etc/ssh/sshd_configarquivo. Certifique-se de editar como sudo ou um usuário no grupo sudo. Tudo o que você precisa fazer para definir a porta é, em um tipo de linha Port 54747.Agora, reinicie o serviço ssh executando: service sshd restart.Em seguida, verifique se o ssh está escutando nessa porta executando sudo netstat -lntp | grep ssh.Reinicialização e teste.

Verifique também suas configurações de rede. Se você estiver em uma rede corporativa, verifique se está na vlan correta.


Fiz um backup e editei o arquivo como sudo e alterei a Port 22linha padrão para Port 54747somente. Além disso, o netstat que você me deu não teve saída. Eu adicionei um modificado no meu OP
3rgo 14/06

Você está se conectando com uma chave correta? Então você deve estar conectando como: ssh -i key.txt user@ipaddress -p 54747. Verifique também se há mais alguma coisa ouvindo nessa porta. Faça sudo lsof -i | grep ssh. Você também pode verificar seu firewall para garantir que não esteja bloqueando nada. Fazer: sudo ufw status.
G_Style

Nenhuma porta usada no 54747 (veja meu OP, eu o adicionei). Eu estou adicionando a saída de seus comandos para isso também
3rgo

Depois de pensar um pouco mais sobre o seu problema, sinto que não é a sua configuração, mas a maneira como você está reiniciando, que está causando o problema que está ocorrendo. Quando você reiniciar você deve usar o comando shutdown -r now. Experimente e informe-nos os resultados. Veja este artigo para referência: askubuntu.com/questions/483670/…
G_Style 15/17

Eu apenas tentei e obtive o mesmo resultado que sudo reboot -h nowou `sudo reboot``
3rgo

0

Às vezes as coisas dão errado. Se eu estivesse no seu lugar, tentaria:

cp /etc/ssh/sshd_config $HOME
sudo apt-get --reinstall install openssh-server

Isso exigirá que eu acesse fisicamente o servidor? Se assim for, só posso fazê-lo amanhã à noite
3rgo

Olá @ 3rgo, acho que você não precisa de acesso físico. Eu apenas experimentei no meu VPS. Também no meu servidor Ubuntu em casa, enquanto eu estava conectado via SSH. Até a conexão não foi interrompida. cpcomando é apenas o caso, normalmente o processo de reinstalação não toca nos arquivos de configuração.
pa4080

Oi! Eu tentei reinstalar, mas nada mudou, eu ainda tenho o mesmo problema ...
3rgo

0

ssh é o processo do cliente que arbitra e mantém uma conexão de sessão do usuário com o servidor ssh. sshd é o daemon que é executado no servidor ssh para escutar e autenticar solicitações de conexão ssh.

O arquivo de configuração no servidor sshd que é lido ao iniciar o serviço sshd (que requer privilégios de sudo para editar) é

/etc/ssh/sshd_config

O serviço deve começar com

/etc/systemd/system/sshd.service

Para reiniciar o sshd, o que envolveria reler o arquivo sshd_config

sudo service sshd restart

Para ver qual porta o daemon sshd está ouvindo, além de outras informações úteis, no tipo de servidor ssh

sudo service sshd status

Execute estas etapas na ordem especificada:

Reinicialize o servidor ssh

Abra uma sessão de terminal no servidor ssh (não uma conexão ssh)

Tipo hostname

Se o nome do host não retornar o nome do servidor ssh (neste caso, o Atlas) refaça a etapa anterior corretamente.

grep Port /etc/ssh/sshd_config - anote o número da porta. Deve ser o que você especificou

sudo service sshd status

Se o status relatar que está ativo, executando e ouvindo na porta customizada especificada, você é bom nesse sentido. Caso contrário, a inicialização do serviço pode não estar chamando o arquivo sshd_config que você modificou, mas outro arquivo de configuração que contém informações padrão. Se o serviço não foi iniciado (diz que está morto e não está ativo e em execução), esse é um problema diferente do que você perguntou.

Essas etapas provavelmente identificarão a causa raiz do problema que você está perguntando.

Para fins de teste e por simplicidade: No lado do cliente, a partir de uma sessão do terminal, você ssh no servidor ssh da seguinte maneira

ssh -l username -p 54747 hostname

Com base no feedback do OP, suspeito que o sshd não esteja inicializando na inicialização, mas é iniciado corretamente quando invocado manualmente. As conexões ssh bem-sucedidas via porta 22 podem NÃO estar conectadas ao servidor ssh, mas a outra coisa (por exemplo, localhost). Para provar ou desmascarar isso, depois de conectar via tipo ssh

hostname

Com base no que o OP está dizendo, acho que o nome do host não será o atlas do servidor ssh.

Para isolar ainda mais isso, depois de reiniciar o servidor ssh, mas antes de fazer mais alguma coisa , em uma sessão de terminal no tipo de servidor ssh (Atlas)

ssh localhost

Se isso falhar, como deveria, então

ssh -p 54747 localhost

Se isso não funcionar, também confirmará os resultados obtidos ao executar

sudo service sshd status

Oi ! Eu adicionei uma sequência de eventos para que você possa entender melhor. Eu SSH usando o comando ssh -p <PORT> <USER>@<IP>, com minha chave privada adicionada ao agente.
3rgo

Muito bom. Execute a etapa 6a: no servidor sshd, status do sudo service sshd. Se ele relatar a porta 22, haverá um arquivo falso sshd_config por aí sendo chamado.
jones0610

Diz, "inativos (mortos)" (ver saída total no meu OP em um segundo)
3rgo

Portanto, se estiver morto (não ativo e em execução), você não estará invadindo a máquina que pensa estar. No servidor sshd, digite ps -ef | grep sshd. Se o daemon sshd no servidor sshd estiver realmente morto, nenhum processo sshd será executado e, portanto, você não poderá fazer o ssh nele, independentemente da porta usada.
jones0610

2 processos sshd encontrado ... Eu adicionei saída detalhada
3rgo

0

Provavelmente você acabou de responder Y quando o apt detectou diferenças entre o sshd_config e o do pacote. Ele pergunta se você deseja instalar a versão do mantainer do pacote ou manter a sua.


1
Não me lembro de ter sido perguntado isso, mas assumindo que é o caso, o que posso fazer para corrigi-lo?
3rgo

0

Possíveis causas em que consigo pensar

  1. Um binário sshd diferente é iniciado na inicialização ou o sshd é iniciado com uma configuração diferente. Talvez o systemd seja o culpado aqui - ele tem uma maneira diferente de alterar a porta, via arquivo, /usr/lib/systemd/system/sshd.socketaparentemente: https://www.vultr.com/docs/how-to-change-ssh-port-on-coreos
  2. O / etc / ou / etc / ssh correto ainda não está montado quando o sshd é iniciado. É um volume separado em sua máquina que é montado posteriormente no processo de inicialização?
  3. O sshd está sem permissões de leitura para o arquivo de configuração no momento da inicialização, embora eu não saiba se o sshd sequer iniciaria.

2
Eu acho que você está nisso. E se é um servidor que passou por muitas atualizações, talvez exista um conjunto de scripts de inicialização (sysv-init, upstart, systemd). Talvez uma simples pesquisa e verifique todos os arquivos em / etc / find /etc/ -iname "*ssh*"para procurar mais pistas.
Bazz
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.