Para mim, a atualização para o Snow Leopard resolveu o problema. Então, acho que isso estava relacionado a um bug no OSX.
Eu tinha o login baseado em chave ssh funcionando bem. Em seguida, alterei o nome do host no meu computador e o login baseado em chave parou de funcionar. Parecia fazer sentido. as chaves provavelmente dependiam do meu nome de host antigo. Então, eu deletei todas as minhas chaves e todos os arquivos em ~ / .ssh / e os criei novamente (e mudei o authorized_keys nos servidores que eu conecto)
Agora, toda vez que eu tentar o ssh, ele apenas trava sem o prompt de senha, não importa onde eu esteja tentando ssh - até mesmo servidores onde eu não tenho o login baseado em chave configurado. Não há nada em .ssh / config.
Além disso, quando eu 'su -' to root, o ssh funciona perfeitamente. sem problemas. Isso só acontece na minha conta de usuário.
Abaixo estão algumas informações de depuração do ssh
ssh -vv [email protected] OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009 debug1: Reading configuration data /Users/myname/.ssh/config debug1: Reading configuration data /usr/etc/ssh_config ...... debug1: Host 'myremoteserver.com' is known and matches the RSA host key. debug1: Found key in /Users/myname/.ssh/known_hosts:1 debug2: bits set: 512/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received
E então fica aqui ...
Aqui está a saída dtruss (como strace, mas para OSX) perto do final em que ela trava: sudo dtruss ssh -vv [email protected]
select(0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
read(0x3, "$21{L31063sN60@q736b74760!{271=2,57t
ssh -vv [email protected]
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /Users/myname/.ssh/config
debug1: Reading configuration data /usr/etc/ssh_config
......
debug1: Host 'myremoteserver.com' is known and matches the RSA host key.
debug1: Found key in /Users/myname/.ssh/known_hosts:1
debug2: bits set: 512/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
6573;40]2
select(0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
read(0x3, "$21{L31063sN60@q736b74760!{271=2,57t%pre%6573;40]2%pre%5z#%pre%", 0x2000) = 48 0
write(0x2, "debug2: service_accept: ssh-userauth\r\n%pre%", 0x26) = 38 0
connect(0x4, 0xBFFFEEA2, 0x6A) = 0 0
write(0x4, "%pre%", 0x4) = 4 0
write(0x4, "\v5%pre%4%pre%", 0x1) = 1 0
read(0x4, "%pre%", 0x4) = -1 Err#4
5z#%pre%", 0x2000) = 48 0
write(0x2, "debug2: service_accept: ssh-userauth\r\n%pre%", 0x26) = 38 0
connect(0x4, 0xBFFFEEA2, 0x6A) = 0 0
write(0x4, "%pre%", 0x4) = 4 0
write(0x4, "\v5%pre%4%pre%", 0x1) = 1 0
read(0x4, "%pre%", 0x4) = -1 Err#4
Parece que está tentando ler alguma coisa e simplesmente paira sobre isso. Se alguém tiver algumas sugestões ou ideias, ficaria muito grato!
A razão pela qual seu cliente ssh trava sua conta, mas não por outras contas (raiz), provavelmente é porque há algo errado com seu agente ssh. Ou que o ssh-agent não esteja em execução ou que sua configuração esteja errada de alguma forma.
Para ter uma confirmação disso, você pode tentar o seguinte:
unset SSH_AUTH_SOCK
ssh [email protected]
Se você for solicitado a inserir a frase secreta em ssh_key, isso significa que você tem um problema com o agente ssh.
Veja também minha postagem em esta questão relacionada .
Posso lhe interessar em DNS reverso?
Essencialmente, o cliente está fazendo o DNS reverso no servidor, ou vice-versa.
Eu proponho um teste:
Desabilite as pesquisas de DNS no servidor editando / etc / ssh / sshd_config e certificando-se de que "UseDNS" esteja configurado para "não".
Execute "service ssh reload" (ou qualquer coisa que faça com que seu daemon ssh releia a configuração) e tente novamente.
Incidentemente, não acontece para finalmente pedir-lhe depois de um longo período de tempo, não é?
Outra coisa que você pode verificar é o conteúdo do / etc / hosts no servidor para garantir que nada esteja errado.
Verifique as permissões no diretório ~ / .ssh e nos arquivos. Seu umask padrão pode ser permissivo demais & quando você recriou os arquivos, talvez tenha inadvertidamente dado a eles as permissões incorretas. Eu tenho sido queimado por isso algumas vezes eu mesmo. Nenhum dos clientes ssh (ou servidores) que usei já deu uma mensagem de erro útil sobre isso ...
você tem espaço livre em disco no seu cliente (e no seu servidor)?
df -h
Eu tive um problema semelhante.
ssh domain.ip:user.name
Parece que eu poderia ignorar o problema, forçando um nome de login assim.
ssh -v domain.ip -l user.name
Se for por causa de uma chave salva, você poderá excluí-la do diretório ~ / .ssh no arquivo known_hosts. Basta encontrar a entrada e excluí-la e, em seguida, deverá avisá-lo novamente.
Por outro lado, deve dar um aviso quando o host não corresponder ao que foi gravado.
Eu tive problemas onde no OS X a pesquisa do nome do host atua como falha; a conexão acaba com a espera de tanto tempo, ou quando o aviso aparece, ele está esperando há tanto tempo que dá dez segundos para que você digite uma senha antes de soltar a conexão. Eu nunca consegui rastreá-lo apesar das pessoas sugerirem adicionar o host em questão ao arquivo host. Eu acho que foi apenas uma "falha com as pesquisas de DNS do OS X" e esperava-se que fosse tolerado ... se alguém tivesse esse problema e resolvido, eu adoraria saber sobre isso.
Verifique os logs no servidor. Geralmente é em /var/log/auth.log (Debian / Ubuntu) ou /var/log/secure (RedHat / CentOS). Qualquer problema com a conexão geralmente é registrado lá.
Certifique-se de que / etc / hostname seja terminado por nova linha.