Por que a autenticação da chave SSH está falhando para este usuário? (CENTROS 7) [fechado]

Question

Eu estou tentando depurar o fato de que uma nova conta de usuário não pode com êxito o SSH em um servidor Centos 7 usando autenticação de chave RSA via o comando

ssh theuser@theserver

As seguintes observações podem ser feitas:

• A conta do usuário (theuser) existe e não está bloqueada
• A pasta home do usuário contém um diretório .ssh (permissão 700) contendo um arquivo authorized_keys (permissão 600)
• o arquivo authorized_keys contém uma cópia da chave pública da máquina local
• o arquivo ~ / .ssh / config da máquina local aponta para o arquivo de chaves correto a ser usado neste servidor
• ssh pode ser obtido com sucesso digitando a senha do usuário quando a autenticação da chave falhou
• ssh por chave pública pode ser obtido com uma conta de usuário diferente
• o arquivo / var / log / secure não registra nada quando a chave é recusada como o usuário

Alguém pode sugerir os próximos passos que devo dar para tentar encontrar a origem desse problema, pois meus colegas e eu estamos presos?

Editar: incluiu a saída ssh -vvv

debug1: Host 'theserver' is known and matches the ECDSA host key.
debug1: Found key in /Users/ambulare/.ssh/known_hosts:20
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare (0x7fc#obfuscated#), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred 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: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
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

    

Answer 1

Graças à sugestão do @ DevilaN, resolvi o problema.

A tentativa de ssh-copy-id retornou um erro "permissão negada em authorized_keys". Como era um erro de permissão, voltei para verificar a propriedade e as permissões no arquivo authorized_keys e, apesar de ter configurado a propriedade para o usuário neste arquivo (como na pergunta original), claramente eu ou meus colegas faziam algo desde a configuração inicial que levou a que a propriedade fosse alterada para "raiz".

Foi um problema de propriedade simples.

chown theuser:theuser authorized_keys

e voila, ssh está funcionando.

Para qualquer pessoa que encontre essa resposta por meio de uma pesquisa do Google: parece que a propriedade do usuário errado do arquivo authorized_keys fará com que uma tentativa de login do ssh falhe silenciosamente sem retornar ou registrar em log em qualquer lugar que seja um erro de permissão -copy-id.