(postado anteriormente em stackoverflow por erro)
Estou executando um monte de servidores com o Ubuntu 14.04.1 (sun, hyperion, ...), que usam chaves públicas (OpenSSH_6.6.1, OpenSSL 1.0.1f 6 de janeiro de 2014 em todas as máquinas) para rsync sem problemas. Quase tudo ...
Uma conexão falha sem alterações nas configurações ou chaves. Então eu vou tentar adicionar novamente as chaves, verifique se há ECDSA, reinicie / reinicie o ssh e ele funciona novamente. Ou não. Neste caso eu apenas espero uma quantidade aleatória de tempo (1h até 3 meses) e faço o mesmo. Desta vez, resolve o problema - por um tempo.
As partes relevantes de um diff ssh -vvv:
Conexão bem sucedida
debug1: Host 'hyperion.internal' is known and matches the ECDSA host key.
debug1: Found key in /home/bar/.ssh/known_hosts:20
debug1: ssh_ecdsa_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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/bar/.ssh/id_rsa (0x7f..),
debug2: key: /home/bar/.ssh/id_dsa ((nil)),
debug2: key: /home/bar/.ssh/id_ecdsa ((nil)),
debug2: key: /home/bar/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 95:...
debug3: sign_and_send_pubkey: RSA 95:...
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to hyperion.internal ([172.16.0.10]:22).
Conexão com falha
debug1: Host 'hyperion.internal' is known and matches the ECDSA host key.
debug1: Found key in /home/bar/.ssh/known_hosts:20
debug1: ssh_ecdsa_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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/bar/.ssh/id_rsa (0x7f..),
debug2: key: /home/bar/.ssh/id_dsa ((nil)),
debug2: key: /home/bar/.ssh/id_ecdsa ((nil)),
debug2: key: /home/bar/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/bar/.ssh/id_dsa
debug3: no such identity: /home/bar/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/bar/.ssh/id_ecdsa
debug3: no such identity: /home/bar/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/bar/.ssh/id_ed25519
debug3: no such identity: /home/bar/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
Coisas que eu verifiquei várias vezes:
ssh-copy-id -i /home/bar/.ssh/id_rsa [email protected] copia as chaves certas para o arquivo right_hosts direito O que realmente não ajudou, mas foi adicionado ao efeito vodoo / heisenbug:
Eu colei os registros completos com algumas informações editadas no pastebin: parede do log
O problema foi resolvido, não foi relacionado ao ssh:
o hyperion.internal tinha uma home criptografada, portanto, a pesquisa de chave falhou quando não foi montada em /home/europe .
Em retrospecto bastante óbvio, mas é responsável pelo efeito heisenbug de não falhar ao observar os logs na máquina (enquanto estiver logado, é claro ...)
Espero que isso ajude pelo menos mais alguma coisa.
debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
Isso indica que o servidor não aceitou sua chave privada. Infelizmente, o servidor não fornece ao cliente mais detalhes sobre por que ele não aceitou a chave, então você realmente precisa solucionar isso no servidor.
Eu começaria verificando os syslogs em /var/log no servidor em busca de mensagens de sshd , indicando por que ele rejeitou a tentativa de autenticação.
Se você tiver acesso root no servidor remoto, poderá executar uma instância de depuração de sshd e, em seguida, conectar-se a ele com um cliente. No servidor remoto, torne-se root e execute /path/to/sshd -d -p 2222 . Isso iniciará uma instância do sshd que escuta na porta 2222. Ela aceitará uma conexão e imprimirá as informações de depuração no seu terminal.
Em seguida, no cliente, execute ssh normalmente, mas inclua -p 2222 para se conectar à porta correta. Se o login falhar, verifique a saída de depuração impressa pelo servidor.
Para mim, este foi um problema de permissões envolvendo o diretório "Início" também. As permissões para o diretório inicial no servidor de destino foram definidas para 775. Pelo que descobri, as permissões do diretório base devem ser definidas como 755 ou menos. Isso define para onde nenhum usuário diferente do proprietário do diretório inicial pode ter permissões de gravação.
Parece um problema no servidor:
debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
O servidor não parece estar enviando uma resposta aqui. Eu tentaria ativar o debug até 11 no lado do servidor e ver o que é lamentar.
Quanto tempo decorre depois que o pacote publickey é enviado aguardando a resposta quando ele falha? Se eu
Chown os arquivos criados pela raiz (não apenas chmod) de volta para a conta de usuário original. Você também pode testar com o Userify, ver se funciona e se você tem chave pública sem erros.
Muitas vezes tive problemas de SSH devido ao mesmo endereço MAC estar associado a vários nomes de computadores e vice-versa. Existem opções de linha de comando para o ssh lidar com isso. Você também pode eliminar ou editar seu arquivo de hosts conhecidos para eliminar o problema. Não tenho certeza se isso ajuda, mas isso cobre 90% dos meus problemas de ssh.