SSH na minha rede local - problema com o login

2

Estou com problemas para fazer login no meu ssh de rede local-linux (servidor) com o Putty (e com o terminal Linux também)

Quando meu servidor me mostra o pedido para inserir o nome de usuário, insiro "root" e pressiono enter.

Estou aguardando sete segundos para solicitar minha senha!

Também olhei para essa questão

e tentei aceitar a resposta, também com o comando

/etc/init.d/ssh restart

Não funcionou. Meu amigo me disse que eu deveria ter que usar outro deamon SSH, mas eu não sei qual. O que eu poderia fazer agora?

minha configuração atual do / etc / ssh / ssh_config:

# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
  GSSAPIAuthentication no
   GSSAPIDelegateCredentials no
   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
    SendEnv LANG LC_*
    HashKnownHosts yes
    
por genesis 12.07.2011 / 20:42

2 respostas

2

Você não precisa de outro daemon SSH. Você pode precisar explicitamente desativar (em vez de simplesmente comentar) GSSAPIAuthentication e GSSAPIKeyExchange no cliente; a outra pergunta não mencionou o último, provavelmente porque é uma adição recente e acho que ainda são patches de terceiros aplicados pelo fornecedor. (O Debian Squeeze, pelo menos, definitivamente tem isso.) GSSAPIDelegateCredentials não precisa ser tocado, pois só é olhado quando GSSAPIAuthentication está habilitado.

Se o item acima não funcionar, sua etapa de aninhamento é usar strace para ver o que está acontecendo durante a pausa.

strace /usr/bin/ssh -vvv host

Isso pressupõe que é o final do cliente; o servidor é um pouco mais difícil de depurar. Se chegar a esse ponto, você precisará desativar o servidor normal (no mundo moderno, isso é service ssh stop ) e, em seguida, fazer algo como

sudo strace -f /usr/sbin/sshd -ddd

Não se esqueça de reativar o servidor normal com service ssh start depois!

    
por 12.07.2011 / 21:00
0

Pode ser um problema de DNS. Em caso positivo, tente remover o comentário:

#   GSSAPITrustDNS no

para que se torne

   GSSAPITrustDNS no

Trabalhará com os problemas por enquanto, no entanto, a correção real é corrigir o problema do DNS. Como observação, adicionar -vvv ao seu comando SSH imprimirá muito mais informações e dará uma ideia melhor de onde procurar, por exemplo:

ssh -vvv <user>@<server>
    
por 29.07.2011 / 11:44