chave privada e chave pública no mesmo diretório faz com que o ssh falhe

7

Eu tenho esse problema muito estranho em que estou tentando conectar usando o SSH a um servidor remoto.

Estou fazendo isso a partir da linha de comando, e a chave privada e a chave pública estão localizadas no meu diretório atual. Eles são denominados id_rsa e id_rsa.pub, respectivamente. Verifiquei, por meio da impressão digital, que eles correspondem a chaves públicas e privadas.

Quando eu emito o seguinte comando:

ssh -vT -i ./id_rsa usuario @ remotehost

Recebo o seguinte erro: Permissão negada (publickey).

No entanto, se eu renomear meu id_rsa.pub para outra coisa, tudo funciona bem. O que poderia estar causando isso? Poderia ser uma configuração no servidor remoto que está causando isso?

A saída de -vT quando eu tenho o id_rsa.pub no mesmo diretório é (e falha):

OpenSSH_6.1p1, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options for *
debug1: Connecting to remotehost port 22.
debug1: Connection established.
debug1: identity file ./id_rsa type 1
debug1: identity file ./id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA <removed>
debug1: Host remotehost is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:10
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Ubuntu 10.04.4 LTS
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ./id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

A saída de depuração quando eu renomeio o id_rsa.pub é:

OpenSSH_6.1p1, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options for *
debug1: Connecting to remotehost port 22.
debug1: Connection established.
debug1: identity file ./id_rsa type -1
debug1: identity file ./id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_53p1     Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA <removed>
debug1: Host remotehost is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:10
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Ubuntu 10.04.4 LTS
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: ./id_rsa
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key './id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to reoteserver:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
    
por Steve 08.04.2014 / 18:28

3 respostas

6

Consegui reproduzir seus sintomas usando uma chave pública e uma chave privada, que não combinavam entre si. Mesmo se ambas as chaves forem permitidas por authorized_keys, o login falhará quando as chaves pública e privada não corresponderem.

Pelo que posso dizer, acontece o seguinte.

  1. Aviso do cliente de que a chave privada está criptografada
  2. O cliente leu o arquivo de chave pública
  3. O cliente oferece essa chave para o servidor
  4. O servidor aceita a chave pública
  5. Solicitações do cliente para senha
  6. O usuário insere a senha
  7. O cliente continua a autenticação usando chave privada incompatível

Quando você remove a chave pública, o cliente pedirá uma senha sem saber se o servidor aceitará a chave. Isso significa que você pode ser solicitado a digitar a senha de uma chave privada apenas para descobrir que o servidor não a aceitaria de qualquer maneira.

    
por 08.04.2014 / 19:56
2

Isso pode ser um bug no OpenSSH ou a chave no authorized_keys do servidor e sua chave privada não correspondem. Quando a autenticação é bem sucedida, você obtém

debug1: identity file ./id_rsa type -1

, o que significa que o OpenSSH não pode carregar o arquivo de identidade (acho que chave pública) nesse estágio. No código-fonte na parte de carregamento da chave, há esse trecho ( authfile.c ):

/* try ssh2 public key */
pub = key_new(KEY_UNSPEC);
if (key_try_load_public(pub, filename, commentp) == 1)
    return pub;
if ((strlcpy(file, filename, sizeof file) < sizeof(file)) &&
    (strlcat(file, ".pub", sizeof file) < sizeof(file)) &&
    (key_try_load_public(pub, file, commentp) == 1))
    return pub;

Significa que o OpenSSH tentará carregar o que é dado em -i parameter + ".pub" como uma chave pública e terá sucesso conforme indicado no log. Sem a chave pública com o sufixo ".pub" no diretório atual, isso falhará. Mais tarde, ao fazer a autenticação ( sshconnect2.c ):

/*
 * send a test message if we have the public key. for
 * encrypted keys we cannot do this and have to load the
 * private key instead
 */
    if (id->key && id->key->type != KEY_RSA1) {
        debug("Offering %s public key: %s", key_type(id->key),
            id->filename);
        sent = send_pubkey_test(authctxt, id);
    } else if (id->key == NULL) {
        debug("Trying private key: %s", id->filename);
        id->key = load_identity_file(id->filename);
        if (id->key != NULL) {
            id->isprivate = 1;
            sent = sign_and_send_pubkey(authctxt, id);
            key_free(id->key);
            id->key = NULL;
        }
    }

Se a chave pública estiver presente, o OpenSSH a enviará como uma mensagem de teste (?) que falhará por algum motivo. Sem chave pública pré-carregada, ela tentará a chave privada e terá sucesso.

Eu não sei porque a falha com a chave pública acontece (se eu tiver tempo, vou tentar descobrir mais). Talvez haja alguma incompatibilidade com os arquivos em .ssh/ que são manipulados em comparação com outros caminhos ou, afinal de contas, há alguma incompatibilidade com suas chaves.

    
por 08.04.2014 / 22:00
0

Tenho quase certeza de que é um problema de permissão. Verifique as permissões da pasta para garantir que ela não seja 770 , mas 740 ou similar. Se você não estiver usando o diretório .ssh , isso pode causar o problema que você está enfrentando com facilidade.

Para corrigir, use chmod o-w /root . Eu altamente recomendo usar uma pasta dedicada para essas chaves, pois as configurações de permissões nas pastas base são complicadas.

    
por 08.04.2014 / 18:39

Tags