Eu tenho um servidor Solaris 10 em outra rede. Eu posso fazer ping e telnet para ele, mas o ssh não conecta. O registro do PuTTY não contém nada de interesse (ambos negociam com o ssh v2) e então eu obtenho
"Event Log: Network error: Software caused connection abort".
O ssh está em execução:
svcs -a | grep ssh
online 12:12:04 svc:/network/ssh:default
Aqui está uma extração do arquivo / var / adm / messages (anonimizado)
Jun 8 19:51:05 ******* sshd[26391]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer
No entanto, se eu fizer o telnet na caixa, posso fazer login no ssh localmente. Eu também posso ssh para outras máquinas (não-Solaris) naquela rede, então não acredito que seja um problema de rede (embora, como estou a algumas centenas de quilômetros de distância, não posso ter certeza).
O firewall do servidor está desativado, então isso não deve ser um problema
root@******** # svcs -a | grep -i ipf
disabled Apr_27 svc:/network/ipfilter:default
Alguma idéia do que devo começar a verificar?
Atualização: Com base no feedback abaixo, executei o sshd no modo de depuração. Aqui está a saída do cliente:
$ ssh -vvv root@machine -p 32222
OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008
debug2: ssh_connect: needpriv 0
debug1: Connecting to machine [X.X.X.X] port 32222.
debug1: Connection established.
debug1: identity file /home/lawrencj/.ssh/identity type -1
debug1: identity file /home/lawrencj/.ssh/id_rsa type -1
debug1: identity file /home/lawrencj/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
E aqui está a saída do servidor:
root@machine # /usr/lib/ssh/sshd -d -p 32222
debug1: sshd version Sun_SSH_1.1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 32222 on ::.
Server listening on :: port 32222.
debug1: Bind to port 32222 on 0.0.0.0.
Server listening on 0.0.0.0 port 32222.
debug1: Server will not fork when running in debugging mode.
Connection from 1.2.3.4 port 2652
debug1: Client protocol version 2.0; client software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x4584c(0x0)
Esta linha parece ser um provável candidato:
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Verifique seu arquivo .ssh / authorized_keys no servidor se você estiver usando a autenticação baseada em chave. Eu tive o mesmo problema, e a pessoa que tinha configurado o acesso tinha colado a chave com quebras de linha. Remover as quebras de linha resolveu o problema, embora você possa testar movendo o arquivo authorized_keys para fora do caminho ou escolhendo a autenticação de senha primeiro e ver se você tem o mesmo problema:
ssh -o PreferredAuthentications=password username@hostname
Tente desativar completamente o GSSAPI:
GSSAPIAuthentication no
Você está na lista de usuários permitidos em sshd_conf?
Você pode obter algumas informações de depuração mais úteis executando
sshd com o sinalizador -d (e possivelmente o sinalizador -p para especificar outra porta
se você quiser deixar o original sshd em execução) e, em seguida, conectar-se a ele
com seu cliente ssh -v .
Atualização: Parece que seu problema está relacionado à rede, e não relacionado à autenticação. Você pode ver que ambos os lados da conversa tiveram sua conexão redefinida. Você pode verificar com a equipe de rede relevante para ver se há um nó de rede intermediário (por exemplo, um firewall) que está causando o problema.
Isso é interessante, eu tenho o mesmo problema. Só eu posso ssh da rede local, mas não quando usando vpn.
May 11 18:03:10 servername sshd [14733]: [ID 800047 auth.crit] fatal: Falha na leitura do soquete: conexão redefinida pelo peer
Eu nunca sou solicitado por um pw. As sessões morrem rapidamente.
Suspeitei que havia algo a ver com problemas de troca de chaves, já que você diz que o SSHv2 é negociado.
Não foi possível encontrar uma boa descrição sobre isso ainda; existe essa referência PuTTY .
você deve tentar uma captura de pacotes no servidor para ver onde a comunicação SSH pára.
Você também pode tentar " ssh -v " para ver quais erros o cliente vê.
Isso é 99% do tempo causado por TCP Wrappers (hosts.deny). Você provavelmente precisa permitir o seu endereço IP lá:
/etc/hosts.deny
O motivo pelo qual ele trabalha a partir do localhost é porque o 127.0.0.1 provavelmente é permitido lá (ou via /etc/hosts.allow).
Seu sshd se bifurca para lidar com a conexão (mesmo na execução de depuração). Parece-me que a criança está morrendo silenciosamente assim que está prestes a interagir com os mecanismos de autenticação do sistema. É a época em que normalmente verifica o UID, o GID e executa o PAM. O seu servidor usa LDAP ou NIS +?
É melhor executar a depuração em um servidor que funcione corretamente e ver o que deve vir em seguida (use vimdiff ou diff).
Eu tenho um problema muito semelhante recentemente quando um grupo tinha muitos membros (o comprimento de todos os membros era de cerca de 500-600 caracteres). Embora isso estivesse no Linux.
Nota: ao executar o servidor para depuração, especifique -ddd (triple debug) para obter mais informações.
Você diz que o host de destino está em outra rede. E que o 'firewall dos servidores está desativado'.
Existe um firewall ou qualquer tipo de dispositivo de filtragem de pacotes entre a rede e a rede de destino.
Valeria a pena fazer um traceroute para ver o que há entre as duas redes.
Certifique-se também de não perder nenhum pacote durante a transmissão. Um teste simples com ping pode ajudá-lo a descobrir se você tem algum problema de rede.
No meu caso, olhando em / var / log / messages me mostrou que eu tinha muitas sessões abertas (limitado pelo PAM): 21 de agosto de 18:05:43 nv20 pam_limits [13325]: muitos logins (máx. 20) para o usuário
Alguns ctrl-D's mais tarde e o ssh estava funcionando novamente ...
Acabei de resolver um problema semelhante com o mesmo sintoma: desconectado após:
debug1: SSH2_MSG_KEXINIT sent.
Executando o servidor ssh em duas portas, 22 e 'outra porta não divulgada'. Eu poderia conectar usando a porta 22, mas não usando a outra porta com a desconexão súbita acima antes da troca de chave do host.
Descobrimos que sshd para a porta 22 estava sendo executado como root enquanto sshd para a outra porta que estava sendo executada como usuário ubuntu . Obviamente, o usuário do ubuntu não pode ler a chave de host privada como mostrado em /var/log/auth.log :
error: Could not load host key: /etc/ssh/ssh_host_rsa_key
error: Could not load host key: /etc/ssh/ssh_host_dsa_key
fatal: No supported key exchange algorithms
O comando 'sudo netstat -nap | grep ssh ' retornou 2 processos diferentes para a porta 22 e a outra porta (editada):
$ sudo netstat -nap | grep ssh
tcp 0 0 0.0.0.0:other port 0.0.0.0:* LISTEN 17620/sshd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 31160/sshd
tcp6 0 0 :::other port :::* LISTEN 17620/sshd
tcp6 0 0 :::22 :::* LISTEN 31160/sshd
Mostra que o servidor ssh na porta 22 usa o processo # 31160 enquanto a outra porta usa a porta # 17620 .
E 'ps -eaf | grep ssh 'mostrou que um processo estava rodando como root enquanto o outro estava rodando como ubuntu (editado):
$ ps -eaf | grep ssh
ubuntu 17620 1 0 Apr25 ? 00:00:00 /usr/sbin/sshd
root 31160 1 0 08:35 ? 00:00:00 /usr/sbin/sshd
Para resolver o problema, eu tive que matar o processo rodando como o ubuntu ( kill 17620 ) e reiniciar o servidor ssh usando o comando 'sudo /etc/init.d/ssh restart '.
Eu não sei ao certo como isso aconteceu, mas depois de tentar reproduzir o problema, descobri que talvez eu tenha tentado reiniciar o sshd sem o root. Funciona, mas a nova porta é hospedada pelo usuário do Ubuntu:
$ /etc/init.d/ssh restart
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
* Restarting OpenBSD Secure Shell server sshd
start-stop-daemon: warning: failed to kill 31884: Operation not permitted
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Se foi isso que fiz, fui mordido por ignorar essas mensagens de erro. No entanto, isso pode ser considerado um bug, já que o servidor não pode mais ser reiniciado adequadamente sem matar o sshd de execução do Ubuntu.
Para aqueles que se perguntam, eu uso outra porta em vez da porta 22 para evitar a maioria das tentativas de conexão na porta 22 em todos os meus servidores e, em seguida, bloquear a porta 22 usando um firewall. Isto é simples, mas funciona e permite-me ligar de qualquer endereço IP.
Este problema pode ser resolvido executando os seguintes 2 comandos do prompt do console / terminal na máquina que a massa não pode acessar:
$ sudo apt-get - remover remover openssh-server
$ sudo apt-get instala o openssh-server
O primeiro comando desinstala completamente o servidor openssh usando purge, ao contrário do autoremove, o que deixa os arquivos de configuração para trás. O segundo comando reinstala o servidor opnessh
Agora tente acessar a máquina novamente.