Eu configurei um servidor SSH online que pode ser acessado publicamente por qualquer pessoa. Portanto, recebo muitas conexões de IPs de todo o mundo. Estranhamente, nenhum realmente tenta autenticar para abrir uma sessão. Eu mesmo posso me conectar e autenticar sem nenhum problema.
De vez em quando, recebo os error: kex_exchange_identification: Connection closed by remote hostlogs do servidor. O que causa isso?
Aqui estão 30 minutos de logs SSH (os IPs públicos foram redigidos):
# journalctl SYSLOG_IDENTIFIER=sshd -S "03:30:00" -U "04:00:00"
-- Logs begin at Fri 2020-01-31 09:26:25 UTC, end at Mon 2020-04-20 08:01:15 UTC. --
Apr 20 03:39:48 myhostname sshd[18438]: Connection from x.x.x.207 port 39332 on 10.0.0.11 port 22 rdomain ""
Apr 20 03:39:48 myhostname sshd[18439]: Connection from x.x.x.207 port 39334 on 10.0.0.11 port 22 rdomain ""
Apr 20 03:39:48 myhostname sshd[18438]: Connection closed by x.x.x.207 port 39332 [preauth]
Apr 20 03:39:48 myhostname sshd[18439]: Connection closed by x.x.x.207 port 39334 [preauth]
Apr 20 03:59:36 myhostname sshd[22186]: Connection from x.x.x.83 port 34876 on 10.0.0.11 port 22 rdomain ""
Apr 20 03:59:36 myhostname sshd[22186]: error: kex_exchange_identification: Connection closed by remote host
E aqui está minha configuração SSH:
# ssh -V
OpenSSH_8.2p1, OpenSSL 1.1.1d 10 Sep 2019
# cat /etc/ssh/sshd_config
UsePAM yes
AddressFamily any
Port 22
X11Forwarding no
PermitRootLogin prohibit-password
GatewayPorts no
PasswordAuthentication no
ChallengeResponseAuthentication no
PrintMotd no # handled by pam_motd
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 /etc/ssh/authorized_keys.d/%u
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]
LogLevel VERBOSE
UseDNS no
AllowUsers root
AuthenticationMethods publickey
MaxStartups 3:100:60
Depois de pesquisar na web, vi referências MaxStartupsindicando que poderia ser o motivo desse erro, mas depois de alterar o valor padrão conforme mostrado no meu sshd_confige tentar mais de 3 conexões, o servidor indica inequivocamente o problema
Apr 20 07:26:59 myhostname sshd[31468]: drop connection #3 from [x.x.x.226]:54986 on [10.0.0.11]:22 past MaxStartups
Então, o que causa error: kex_exchange_identification: Connection closed by remote host?
Alguns spiders e serviços, como o Shodan , verificam endereços IPv4 públicos em busca de serviços abertos, por exemplo, mestres de sal, servidores ftp, RDPs e também serviços SSH. Esses spiders geralmente só se conectam aos serviços sem realizar nenhuma etapa de autenticação válida.
Eu não encontrei respostas conclusivas sobre isso, então... hora de navegar na fonte então.
No código fonte do OpenSSH,
kex_exchange_identificationé uma função para trocar a identificação do servidor e do cliente (duh) , e o erro especificado aconteceu se a conexão do socket entre o servidor OpenSSH e o cliente for interrompida ( vejaEPIPE), ou seja, o cliente já fechou sua conexão.Acabei de ter esse problema exato, e a causa foi que eu tinha uma tradução de porta acontecendo internamente no balanceador de carga, o que significa que minhas
sshconexões estavam chegando ao host em port em80vez de port22.O host estava terminando corretamente as conexões, e a mensagem de erro retornada ao meu terminal foi a seguinte;
Corrigida a tradução da porta interna e agora o problema desapareceu.
Resolvi meu problema com 'kex_exchange_identification: conexão fechada por host remoto' quando percebi que estava tentando me conectar usando o IP do servidor quando deveria estar usando o IP privado.
Minha configuração pode estar a mundos à parte de todos vocês, apenas pensando em transmitir minha própria descoberta.
EDITAR :
Com alguns provedores de hospedagem você terá dois IPs, um é público, um é privado, o privado é o que você deve usar nesta instância.
Você sabe ou não, eu aprecio que isso não se aplica a todos, e é por isso que digo que pode ser uma configuração diferente.
Nenhuma outra resposta funcionou para mim, até que usei a chave privada.
No meu caso, usei entradas /etc/hosts manuais e fiz proxy por meio de um bastião. O bastião não tinha as mesmas entradas /etc/hosts, então recusou o túnel.
Percebi que isso aconteceu comigo (no arquivo auth.log) depois que instalei e configurei o fail2ban hoje. Então pode ser esse o motivo.
No meu caso estava criando a chave ssh de uma variável protegida no Gitlab CI, tive que remover a proteção dessa variável para que ela funcionasse.
Você pode estar apenas se conectando ao
wrong port.Verifique a porta exata!
Você pode especificar uma porta personalizada usando
ssh -p port user@hostNo meu caso, eu estava tentando ssh para uma VM do Ubuntu em execução no VirtualBox. Eu tinha esquecido de instalar
openssh-serverna VM.consertou.
Desconecte-se da conexão VPN.
No meu caso isso resolveu.
Eu tinha a porta não padrão especificada com
-p, chaves adicionadas ao servidor e meu gerenciador de credenciais e estava recebendo esse erro.Eu encontrei com meu problema específico, eu precisava colocar meu IP na lista de permissões no painel de controle do servidor do serviço de hospedagem para meu ID de login SSH.