Por que minha conexão ssh não é autorizada embora eu tenha atualizado minha chave na máquina remota?

1

Na minha máquina local, tenho uma chave pública armazenada em

.ssh/id_rsa.pub

Para fazer login em uma máquina remota, copio essa chave usando ssh-copy-id :

ssh-copy-id user@remote-host

No host remoto, vejo duas linhas adicionadas ao arquivo .ssh/authorized_keys iniciando com ssh-dss e ssh-rsa e terminando com as informações da máquina local.

No entanto, quando faço login na máquina remota com

ssh user@remote-host

Ainda me pedem uma senha. Por que isso e como isso pode ser corrigido?

  • As permissões de arquivo de authorized_keys estão corretas.
  • O seguinte é o resultado de ssh -v :

    OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 de março de 2012 debug1: Lendo dados de configuração / etc / ssh / ssh_config debug1: / etc / ssh / ssh_config linha 19: Aplicando opções para * debug1: Conectando a porta xxx [xxx] 22. debug1: Conexão estabelecida. debug1: arquivo de identidade /home/alexander/.ssh/id_rsa type 1 debug1: Verificando o arquivo da lista negra /usr/share/ssh/blacklist.RSA-2048 debug1: Verificando o arquivo da lista negra /etc/ssh/blacklist.RSA-2048 debug1: arquivo de identidade /home/alexander/.ssh/id_rsa-cert type -1 debug1: arquivo de identidade /home/alexander/.ssh/id_dsa tipo 2 debug1: Verificando o arquivo da lista negra /usr/share/ssh/blacklist.DSA-1024 debug1: Verificando o arquivo da lista negra /etc/ssh/blacklist.DSA-1024 debug1: arquivo de identidade /home/alexander/.ssh/id_dsa-cert tipo -1 debug1: arquivo de identidade /home/alexander/.ssh/id_ecdsa type -1 debug1: arquivo de identidade /home/alexander/.ssh/id_ecdsa-cert tipo -1 debug1: Remote protocol version 2.0, versão de software remoto dropbear_0.52 debug1: no match: dropbear_0.52 debug1: Ativando o modo de compatibilidade para o protocolo 2.0 debug1: String de versão local SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1 debug1: SSH2_MSG_KEXINIT enviado debug1: SSH2_MSG_KEXINIT recebido debug1: kex: servidor- > cliente aes128-ctr hmac-md5 nenhum debug1: kex: client- > servidor aes128-ctr hmac-md5 nenhum debug1: enviando SSH2_MSG_KEXDH_INIT debug1: esperando SSH2_MSG_KEXDH_REPLY debug1: Chave do host do servidor: RSA XXXX debug1: O host 'remote_host' é conhecido e corresponde à chave do host RSA. debug1: Chave encontrada em /home/alexander/.ssh/known_hosts:26 debug1: ssh_rsa_verify: assinatura correta debug1: SSH2_MSG_NEWKEYS enviado debug1: esperando SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS recebido debug1: Roaming não permitido pelo servidor debug1: SSH2_MSG_SERVICE_REQUEST enviado debug1: SSH2_MSG_SERVICE_ACCEPT recebido debug1: Autenticações que podem continuar: publickey, password debug1: Próximo método de autenticação: publickey debug1: Oferta de chave pública DSA: /home/alexander/.ssh/id_dsa debug1: Autenticações que podem continuar: publickey, password debug1: Oferta de chave pública RSA: /home/alexander/.ssh/id_rsa debug1: Autenticações que podem continuar: publickey, password debug1: Tentativa de chave privada: /home/alexander/.ssh/id_ecdsa debug1: Próximo método de autenticação: senha senha do usuário @ remote_host:

por Alex 08.11.2013 / 10:05

2 respostas

0

Você precisará excluir o conteúdo do diretório host remoto ou ele não reconhecerá a nova chave e chmod 700 (não 600) ambos os diretórios .ssh (host local e remoto).

Após gerar o novo par de chaves, insira o comando no host local cat .ssh/id_rsa.pub | ssh <user>@<remotehost> 'cat >> .ssh/authorized_keys' Isso levará a saída de suas chaves autorizadas em sua máquina local e a colocará também na máquina remota. Além disso, você precisará garantir o acesso RWX, e não apenas o RW.

    
por 07.07.2016 / 06:21
-2

tente chmod 0600 ~ / .ssh

E certifique-se de que as permissões do seu diretório sejam válidas.

Eu encontrei diretórios de .ssh com ??????? opções ao fazer um ls -l devido à restauração de backups.

    
por 08.11.2013 / 11:32