SSH redefine a porta padrão na reinicialização

8

Mudei minha porta SSH padrão no meu servidor doméstico (no arquivo /etc/ssh/sshd_config ) para a porta 54747, em seguida, reiniciei os serviços ssh e sshd (nunca tenho certeza de qual deles, portanto, fiz os dois apenas para garantir) . Para testar minha configuração, eu saí e depois voltei sem nenhum problema.

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

Por alguma razão, eu tentei SSH na porta padrão, e funcionou! Voltei para verificar o sshd_config, mas ainda tinha a porta personalizada. Então eu reiniciei os serviços ssh e 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 é usado com um HTPC, com uma sessão aberta (mesmo usuário como SSH) na minha TV
  • I SSH usando a chave RSA do meu laptop e desabilitei a senha auth
  • Eu costumava reiniciar com sudo reboot -h now , mas depois de pesquisar, descobri que ele foi desencorajado por algumas pessoas, então tentei sudo reboot , mas sem diferenças

EDITAR Sequência de eventos:

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

EDIT 1: netstat output

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 hostname 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
    
O
por 3rgo 14.06.2017 / 21:45

4 respostas

1

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

    
por Marco 15.06.2017 / 10:22
0

Verifique suas configurações de porta no arquivo /etc/ssh/sshd_config . Certifique-se de estar editando como sudo ou 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. Reinicializar e testar.

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

    
por G_Style 14.06.2017 / 22:36
0

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

cp /etc/ssh/sshd_config $HOME
sudo apt-get --reinstall install openssh-server
    
por pa4080 14.06.2017 / 23:20
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 sudo para editar) é

/etc/ssh/sshd_config

O serviço deve começar fora de

/etc/systemd/system/sshd.service

Para reiniciar o sshd, o que envolveria a releitura do arquivo sshd_config

sudo service sshd restart

Para ver qual porta o daemon sshd está escutando, bem como outras informações úteis, no tipo de servidor ssh

sudo service sshd status

Siga estas etapas na ordem especificada:

Reinicie o servidor ssh

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

Digite hostname

Se hostname não retornar o nome do servidor ssh (Atlas neste caso) refaça o passo 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 informa que está ativo, em execução e em escuta na porta personalizada especificada, você é bom nesse aspecto. 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 começou (diz morto e não está ativo e em execução, então este é um problema diferente do que você perguntou.

Estas etapas provavelmente identificarão a causa raiz do problema sobre o qual você está perguntando.

Para propósitos de teste e para simplicidade: No lado do cliente, a partir de uma sessão de terminal, você faria ssh no servidor ssh da seguinte forma

ssh -l username -p 54747 hostname

Com base no feedback do OP, suspeito que o sshd não esteja sendo inicializado na inicialização, mas é iniciado corretamente quando invocado manualmente. Conexões ssh bem-sucedidas através da porta 22 podem não ser conectadas ao servidor ssh, mas a outra coisa (por exemplo, localhost). Para provar ou desbancar isso, depois de conectar via ssh type

hostname

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

Para isolar ainda mais isso, após reinicializar o servidor ssh, mas antes de fazer qualquer outra coisa , a partir de uma sessão de terminal no tipo ssh server (Atlas)

ssh localhost

Se isso falhar, como deveria,

ssh -p 54747 localhost

Se isso não funcionar, isso confirmará os resultados obtidos durante a execução

sudo service sshd status
    
por jones0610 14.06.2017 / 22:14