Estou tentando conectar-me de um MacBook Air (MacOS 10.14.6) via ssh (sem senha) a uma máquina Ubuntu (16.04.6), usando um comando como
ssh aaa.bbb.ccc.ddd
Sempre funcionou bem, recebi um aviso e pude começar a trabalhar na máquina remota.
Porém, por cerca de uma semana, isso não funciona mais, sem saber de nenhuma alteração que fiz no processo de login, novos usuários, alteração de senha, alteração de qualquer chave, atualização de sistema operacional, alteração .profileou .bashrcetc. , e reiniciei a máquina Ubuntu e o Mac, mas nenhuma alteração./etc/hosts.allow/etc/hosts.deny
No momento em que faço login com sucesso, vejo uma mensagem
Last login: ... from www.xxx.yyy.zzz
Connection to aaa.bbb.ccc.ddd closed
Como posso depurar o que está acontecendo?
Termo aditivo
Ao verificar, /var/log/auth.logvejo as seguintes entradas:
Oct 16 07:02:38 mac353 systemd-logind[1173]: New session 11 of user alex.
Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user
Oct 16 07:02:38 mac353 sshd[11834]: Disconnected from www.xxx.yyy.zzz port 61437
Responder1
Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user
O endereço IP correto www.xxx.yyy.zzzdo seu MacBook Air no momento?
Pode ser que exista outro sistema na rede usando o mesmo endereço IP. Você pode iniciar uma conexão normalmente, mas quaisquer respostas serão entregues aleatoriamente a ambos os sistemas participantes do conflito de endereço IP, portanto, o servidor poderá ter que reenviar alguns de seus pacotes de saída. Normalmente, o sistema que está realmente tentando estabelecer uma conexão responderá mais rapidamente, portanto, para alguns pacotes iniciais, pode parecer que funciona bem.
Mas eventualmente o driver TCP/IP do sistema conflitante pensará "O que é esse tráfego? Não tenho nenhuma conexão TCP ativa no momento." e enviar um pacote TCP Reset de volta à origem do tráfego de aparência falsa, ou seja, o servidor. Como o sistema conflitante tem o mesmo endereço IP do seu MacBook, o servidor não tem como saber que a redefinição de TCP não pertence realmente à sua conexão e, portanto, o servidor assumirá que a redefinição de TCP significavocêqueria desconectar. Isso não acontece imediatamente porque o envio de pacotes de redefinição de TCP geralmente é uma tarefa de baixa prioridade no driver TCP/IP.
Este seria um sintoma muito típico de conflito de endereço IP.
Para encontrar o sistema conflitante, você pode tentar consultar as tabelas de endereços MAC do switch de rede (se for um switch gerenciado) ou do AP WiFi do seu segmento de rede local. Se o seu endereço IP estiver associado a um endereço MAC que não pertence ao seu MacBook, você encontrou o endereço MAC do sistema conflitante. Em uma rede com fio, você pode verificar qual porta do switch viu esse endereço MAC e ver o que há na outra extremidade do cabo.
Se você não possui switches gerenciados ou não tem acesso a eles, tente executar ping em seu próprio endereço IP e ver se obtém respostas duplicadas. Ou você pode tentar a arpingferramenta de linha de comando para fazer o mesmo com pacotes ARP: isso capturará até mesmo sistemas que não respondem a pings.
Responder2
A solução para esse problema foi um set -earquivo /etc/profile.dque foi instalado em um contexto completamente diferente. Depois de renomear esse arquivo, o sshlogin funcionou novamente.
`set -e`
interrompe a execução de um script se um comando apresentar um erro (Veja aqui) e é considerada uma má prática por alguns.