Problema SSH - Falha na leitura do soquete: redefinição de conexão por ponto

23

Eu posso SSH em uma direção sem problemas:

ESTÁ BEM:

ssh user@computerA

mas de outra maneira:

ssh user@computerB

Eu entendo Read from socket failed: Connection reset by peer.

Nem sequer começo a saber onde procurar para resolver isso.

Alguém tem alguma pista?

ssh

— boehj
fonte

Qual é a sua configuração de rede? Alguma máquina está atrás de um firewall / roteador?

— 2141212

Ambos apenas se conectaram através de um cabo Ethernet através de um roteador. Eles tinham SSH em ambas as direções no passado.

— boehj

Você verificou que os dois daemons SSH estão em execução? Alguma coisa nos logs?

— NorTicUs 23/10/12

Boas e más notícias: respondi à minha própria pergunta. Vou digitar isso abaixo. Obrigado pela sua ajuda da mesma forma.

— boehj

13

comece a monitorar o arquivo de log do servidor

tail -f /var/log/auth.log
adicione -v para obter uma saída detalhada no final do cliente

ssh user@computerB -v

Isso pode lhe dar mais detalhes sobre a causa. se as chaves rsa e dsa estiverem ausentes no servidor, corrija-as da seguinte maneira:

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa  -f /etc/ssh/ssh_host_dsa_key

— antraz
fonte

Isso funcionou para mim. Embora eu tinha que ser root para executar o seguinte: ssh-keygen -t dsa -f / etc / ssh / ssh_host_dsa_key

— StarDust

A re-geração de chaves definitivamente funciona. No meu caso, ele estava mudando o endereço IP da máquina depois que o openssh foi instalado (e as chaves geradas durante a instalação).

— precisa saber é o seguinte

Depois disso, perdi a chance de me conectar ao meu servidor. Tinha que pedir ajuda do provedor de hospedagem. Ainda aguardando sua resposta. Centos 7 com cPanel.

— Tomas Gonzalez

8

Reinstalei os bits SSH fazendo:

sudo apt-get --reinstall install openssh-server openssh-client

Isso corrigiu todos os meus problemas.

— boehj
fonte

8

Pode ser uma coincidência. O fato de o problema ter parado de ocorrer no momento em que você reinstalou o ssh não é uma garantia hermética de causa e efeito. A propósito, de que lado você reinstalou? Ou ambos? De qualquer forma, "é improvável que esta pergunta ajude futuros visitantes".

— Kaz

5

O método do änthräX é muito útil. Funciona para mim!

Basicamente, acho que, após a instalação do ssh, os arquivos principais são necessários.

A única revisão que fiz foi usar em rsavez de rsa1:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key 
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

Esse método modificado funcionou para mim.

— Alan_04
fonte

Este foi o problema no meu caso. O pacote do servidor ssh com a versão atual do Ubuntu para a máquina Utilite ARM instalada com o sintoma do OP. Depois de executar esses dois comandos (que fiz como root), posso finalmente entrar no ssh. Muito obrigado. +1

— James T Snell

1

É porque, de alguma forma, as permissões dos arquivos dentro /etc/sshforam alteradas ... Portanto, altere a permissão dos arquivos, como no exemplo abaixo:

usar:

chmod 644 ssh_config
chmod 600 moduli

e assim por diante...

Finalmente, as permissões de arquivo devem se parecer com as indicadas abaixo,

[root@hostname ssh]# ls -latr
total 172

-rw-r--r--.   1 root root   2047 Aug 12  2010 ssh_config
-rw-------.   1 root root 125811 Aug 12  2010 moduli
-rw-------.   1 root root    963 Mar  1 16:02 ssh_host_key
-rw-r--r--.   1 root root    627 Mar  1 16:02 ssh_host_key.pub
-rw-r--r--.   1 root root    382 Mar  1 16:02 ssh_host_rsa_key.pub
-rw-------.   1 root root   1675 Mar  1 16:02 ssh_host_rsa_key
-rw-r--r--.   1 root root    590 Mar  1 16:02 ssh_host_dsa_key.pub
-rw-------.   1 root root    668 Mar  1 16:02 ssh_host_dsa_key
-rw-------.   1 root root   3845 May  7 11:52 sshd_config

Depois de alterar as permissões, tente conectar-se a massa, deve funcionar bem.

— Varun Joseph
fonte

1

Por que o Putty é relevante? E considere perguntar ao OP quais são as permissões nos arquivos antes de avisar que ele / ela as altera.

— Clive van Hilten

Sinto muito por postar a resposta de uma maneira errada. Agora, aqui está o problema: durante a instalação de um aplicativo, alguém alterou as permissões desses arquivos para 777. Isso eu pude saber ao passar por / var / log / messages (conexão serial ao máquina). Daí mudou as permissões, e adivinhem? funcionou bem depois disso.

— Varun Joseph

1

Tivemos um problema semelhante, mas ocorreu apenas ao fazer logon do Ubuntu no Solaris. Assegurar que todas essas linhas estejam presentes no /etc/ssh/ssh_config host do Ubuntu corrigiu o problema (você deve encontrar algumas dessas linhas já presentes):

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

No caso do Xubuntu, eu precisava apenas dos dois últimos.

— Philip Kearns
fonte

0

Esta mensagem também pode resultar de várias tentativas de ataques ssh. Se você vir essa mensagem em seus logs, uma fonte mal-intencionada pode estar tentando invadir sua máquina usando tentativas de senha de força bruta.

Para diminuir as tentativas, instale o pacote "fail2ban":

sudo apt-get install fail2ban

Na página wiki de fail2ban :

O Fail2ban varre os arquivos de log (por exemplo, / var / log / apache / error_log) e bane os IPs que mostram sinais maliciosos - muitas falhas de senha, buscas por explorações, etc. Geralmente, o Fail2Ban é usado para atualizar as regras de firewall para rejeitar os endereços IP. por um período de tempo especificado

— Liloulinx
fonte

1

Por favor, explique a sua resposta com mais detalhes sobre por que isso iria funcionar

— DnrDevil