O SSH está exigindo senha quando a chave pública está no host remoto

Question

Portanto, tenho lutado para tentar autenticar sem uma senha. Aqui estão todos os meus passos.

1. No host de origem ssh-keygen e salvou o arquivo no diretório padrão com uma frase-chave em branco (enter) drwx ------ 2 root 4096 Dez 11 18:08 .ssh é a permissão do arquivo.

2. ssh-keyscan 192.168.117.131 > known_hosts

3. ssh-copy-id [email protected] e senha "usuário" imputada. Depois de digitar a senha, recebi:

ssh-copy-id [email protected]
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

4. ssh [email protected] e ainda está exigindo uma senha.

No host remoto

drwxr-xr-x  2 user user 4096 Dec 12 08:27 .ssh 

e

-rwxr-xr-x  1 user user  391 Dec 12 08:27 authorized_keys

O arquivo
5. authorized_key possui a mesma chave que id_rsa.pub no servidor SOURCE.

Meu arquivo sshd_config tem as seguintes configurações:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
StrictModes no
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
AuthorizedKeysFile      .ssh/authorized_keys .ssh/authorized_keys2

6. /etc/init.d/ssh restart

7. Do servidor de origem, tentei novamente o SSH e ele ainda está solicitando uma senha.

Aqui está o meu log de depuração também:

root@kali:~/.ssh# ssh -v [email protected]
OpenSSH_7.4p1 Debian-10, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.117.131 [192.168.117.131] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10
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
debug1: Authenticating to 192.168.117.131:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
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:uGQe2r9lvKFm6w5p5jInX8Ywrg2PmICccUvC+q+Wc18
debug1: Host '192.168.117.131' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Skipping ssh-rsa key /root/.ssh/id_rsa - not in PubkeyAcceptedKeyTypes
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>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password: 

Por favor, ajudem, eu tenho tentado descobrir isso nos últimos 2 dias.

Obrigado!

    

Answer 1

Das mensagens de depuração, parece que o seu ssh local precisa de algumas mudanças na configuração. Você pode ver o ssh local, debug1: , ignorando sua chave RSA:

debug1: Skipping ssh-rsa key /root/.ssh/id_rsa - not in PubkeyAcceptedKeyTypes

Você pode descobrir como configurar essa opção fazendo check-out da man page para ssh_config :

 PubkeyAcceptedKeyTypes
         Specifies the key types that will be used for public key authentication as a comma-separated pattern list.  Alternately if the speci‐
         fied value begins with a ‘+’ character, then the key types after it will be appended to the default instead of replacing it.  If the
         specified value begins with a ‘-’ character, then the specified key types (including wildcards) will be removed from the default set
         instead of replacing them.  The default for this option is:

            [email protected],
            [email protected],
            [email protected],
            [email protected],
            [email protected],
            ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
            ssh-ed25519,ssh-rsa

         The list of available key types may also be obtained using "ssh -Q key".

Então, consultando sua configuração do ssh:

ssh -Q key

Deve render todos os tipos de chaves aceitos para o cliente ssh local.

Parece que sua configuração não é a configuração padrão. Isso parece provável devido à versão especializada do GNU / Linux que você está executando: "Kali"

    

Answer 2

No host, o diretório ~/.ssh não deve ser legível por ninguém, mas o usuário ( drwx------ ) e o arquivo authorized_keys devem ser os mesmos ( -rw------- ).

Se não for assim, é ignorado pelo SSH.

    

Answer 3

Você tem um agente em execução, com uma chave carregada e um conjunto de acesso em seu ambiente atual? Se você pensar no cliente ssh como a chave para uma porta, e o servidor sshd como o bloqueio naquela porta, então ter uma chave carregada no agente pode ser pensada como a necessidade de ter a chave com você e realmente inserir em a fechadura quando você quiser abrir a porta.

Você pode verificar com ssh-add -l como:

$ ssh-add -l
2048 SHA256:Y0NxbfZjsvauyER2jjUqh5gysMyvawKKrYStcqWg6Ks user@Nhostname (RSA)
# An agent is running and accessible, and a key is loaded

A página ssh-agent man é um lugar para começar a usar isso, e há as respostas aqui também.

    

Answer 4

Adicione uma linha no arquivo sshd_config :

RSAAuthentication yes

e reinicie o serviço.