Temos um servidor XXX no Amazon EC2.
O SSH está sendo executado em uma porta padrão (22).
Coloquei meu pubkey no arquivo /.ssh/authorized_keys
A coisa divertida é que ontem estava funcionando muito bem!
Mas hoje não sei o que aconteceu! Eu simplesmente não consigo entrar.
ssh -vvvv servername
está preso em
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Eu verifiquei meu pubkey e está lá! (como eu chequei? Eu pedi para o outro cara verificar)
e depois usei outro computador (windows 7 + putty) e coloquei meu novo pubkey. E o que? Eu consegui entrar! E esse é outro computador com o Win7 que está na mesma LAN, o que indica que o IP externo é o mesmo.
Minha chave privada funciona para outros servidores, mas não para isso.
Essa coisa está me matando)))))
Absolutamente estranho.
Por favor, ajude!
Eu tive o mesmo problema depois de atualizar minha máquina cliente Ubuntu. Eu resolvi meu problema reduzindo o tamanho da linha "Ciphers" em / etc / ssh / ssh_config. Também funciona se você especificar o cypher na linha de comando (ex: ssh -c username @ hostname)
Dica aqui:
Altere a MTU da interface de rede para resolvê-la. Este é um bug para o Ubuntu 14.04.
Isso funcionou para mim:
sudo ip li set mtu 1200 dev wlan0
OR
sudo ifconfig wlan0 mtu 1200
ssh falha ao conectar-se ao host VPN - trava em 'esperar SSH2_MSG_KEX_ECDH_REPLY'
O mesmo problema exato aqui para acessar um servidor dedicado no datacenter online.net.
Não há problema após uma reinicialização, não há necessidade de mudar MTU, a conexão ssh funciona por 1-3 semanas, então aparece exatamente esse mesmo bug, bloqueando o KEXINIT, não é mais possível conectar o servidor ssh.
Poderia ser algum tipo de bug sshd, mas é necessariamente desencadeada por alguma coisa nova acontecendo depois de 1-3 semanas, eu reproduzi esse problema exato muitas vezes com muitos servidores diferentes nesta rede, alguns dizem que isso poderia estar relacionado a um bug do Cisco, possivelmente relacionado com algumas opções de DPI.
Esse problema nunca aconteceu com outros servidores que eu gerencio em outros datacenters, e que têm exatamente a mesma distro, config e versão sshd.
se você não quiser reinicializar a cada 10 dias porque os firewalls de datacenter (ou outros ajustes de rede) estão fazendo coisas estranhas:
conecte-se primeiro a uma dessas soluções alternativas do lado do cliente:
solução alternativa 1, reduzindo seu MTU local do lado do cliente:
ip li set mtu 1400 dev wlan0
(1400 deve ser o suficiente, mas você pode tentar usar valores mais baixos, se necessário)
solução 2, especificando o cypher escolhido para a conexão ssh:
ssh -c [email protected] host
(ou tente com qualquer outro cypher disponível)
Ambas as soluções do lado do cliente fizeram isso para mim, eu poderia conectar e salvar meu tempo de atividade; mas você quer consertar este lado do servidor, para sempre, então você não precisa pedir a cada cliente para ajustar localmente o seu MTU.
No gentoo, acabei de adicionar:
mtu_eth0="1400"
no /etc/conf.d/net
(a mesma opção mtu deve estar disponível em algum lugar no seu arquivo de configuração de rede de distribuição preferido)
Eu configurei o mtu para 1400, mas 1460 provavelmente é o suficiente na maioria dos casos.
outra solução auxiliar poderia ser usar as seguintes regras do iptables para gerenciar a fragmentação:
# / sbin / iptables -I OUTPUT -p tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu
# / sbin / ip6tables -I SAÍDA -p tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu
(mas eu pessoalmente não precisava disso até agora)
observe também que os sintomas desse problema também podem ser:
debug1: SSH2_MSG_KEXINIT sent
não apenas
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
editar março de 2016:
diminuir o mtu para 1400 no servidor quase sempre funciona, mas recentemente tive o caso em que o mtu já estava reduzido para 1400 no servidor e o problema reapareceu, e o cliente também teve que baixar mtu para 1400.
O problema também apareceu em formulários de login da web esperando que a página fosse recarregada até dizer "o servidor reinicializou a conexão", também corrigido depois que o cliente definiu o mtU para 1400.
related links :
No meu caso, não tenho permissão para diminuir o tamanho da MTU. E manualmente, especificando a cifra não funciona.
Eu consigo conectar depois de encurtar a lista de MACs especificando um, por exemplo:
ssh -o MACs=hmac-sha2-256 <HOST>
Comecei a ter esse problema hoje, no Windows (ssh distribuído com o Git) e no Ubuntu.
Parece ser um bug no OpenSSH, há um problema no LauchPad .
Funcionou para mim no Windows forçando a cifra 3des-cbc e a chave no Ubuntu.
Alterando o KexAlgorithm funcionou para mim e pode ser uma opção em que você não tem direitos de sistema para alterar as configurações de MTU. Isso também pode ser um para a equipe do OpenSSH abordar. por exemplo,
ssh -o KexAlgorithms=ecdh-sha2-nistp521 [email protected]
nós resolvemos isso comentando a linha Ciphers em / etc / ssh / ssh_config
Parece claro que a caixa de diálogo de opções causa um problema, porque alterei a ordem na qual o Putty negocia a troca de chaves e o problema resolvido.
cmiiw
verifique sua permissão ~ / .ssh / authorized_keys, deve ser 600
verifique on / var / log / secure, / var / log / messages ou / var / log / auth
Tags ssh security amazon-ec2 linux