Você precisa procurar nos logs do servidor para descobrir por que está rejeitando a chave. normalmente é evidente das mensagens de log qual é o problema.
EDIT: Depois de consultar logs detalhados, como foi sugerido, encontrei o erro sozinho. A resposta está no final.
Eu tenho um droplet DigitalOcean que desejo usar como um ambiente de desenvolvimento. Eu criei um usuário não-root com privilégios sudo para fazer todo o trabalho real, e configurei este usuário com a chave pública no meu par via ssh-copy-id . A tentativa de copiar a chave novamente confirma que a chave está presente e é reconhecida:
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
Depois de tentar as seguintes sugestões:
.ssh em ambas as máquinas, gere e copie uma nova chave chmod para garantir que .ssh esteja definido como 700 e authorized_keys esteja definido como 600 no VPS. etc/ssh/sshd_config stating PubkeyAuthentication yes , bem como
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
, seguida da reinicialização do daemon ssh no VPS. cat
Nesse estágio, qualquer tentativa de conexão via SSH ainda solicita a senha do usuário, mesmo que eu defina explicitamente a chave como sem senha e, ao não fornecer essa senha, isso resultará nesse erro: Permission denied (publickey,password). Se eu fornecer a senha, Ainda sou capaz de fazer login diretamente como usuário.
A seguir estão os logs detalhados antes que o prompt de senha seja exibido:
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "138.197.31.224" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 138.197.31.224 [138.197.31.224] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5p1 Ubuntu-10
debug1: match: OpenSSH_7.5p1 Ubuntu-10 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 138.197.31.224:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:cAw/cF/p37TL25mwRKivxJpMCPyrCMFo5YaeTYQ2Wvo
debug1: Host '138.197.31.224' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/user/.ssh/id_rsa ((nil))
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))
debug2: key: /home/user/.ssh/id_ed25519 ((nil))
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Se olharmos para os registros acima, estas são as linhas mais relevantes:
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Podemos ver que ssh tem quatro arquivos padrão que serão verificados, o que é bom supondo que você tenha permitido que ssh-keygen forneça um nome padrão durante a geração. No entanto, se você atribuir um nome especial à sua chave, será necessário apontar o ssh para o local da chave privada, pois ele não sabe procurar por ela. Depois que percebi isso, tentei fazer o login com o seguinte comando:
ssh [email protected] -i .ssh/custom_named_rsa
. . e foi bem sucedido. Note que o acima apenas acontece de ser o caminho relativo para a chave do diretório em que eu estava, as considerações usuais do pathing se aplicam. Graças a ambas as sugestões para processar logs, especialmente aquele para o log detalhado no lado do cliente.
Você precisa procurar nos logs do servidor para descobrir por que está rejeitando a chave. normalmente é evidente das mensagens de log qual é o problema.
Para garantir que isso possa ser encerrado corretamente, agora que descobri, vou reiterar aqui uma resposta automática do que eu disse acima:
Tente se conectar ao servidor remoto usando ssh -vv [email protected] . Isso mostrará os logs detalhados da tentativa, que na parte inferior logo antes do prompt de senha geram as seguintes linhas importantes:
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Podemos ver que ssh tem quatro arquivos padrão que serão verificados, o que é bom supondo que você tenha permitido que ssh-keygen forneça um nome padrão durante a geração. No entanto, se você der à sua chave um nome especial, você terá que apontar o ssh para a localização da chave privada, já que ela não sabe procurá-lo. Depois que eu percebi isso, eu tentei faça o login com o seguinte comando:
ssh [email protected] -i .ssh/custom_named_rsa
. . e foi bem sucedido. Note que o acima apenas acontece de ser o caminho relativo para a chave do diretório em que eu estava, as considerações usuais do pathing se aplicam.
Você pode definir a chave personalizada no arquivo .ssh / config do usuário. link