☰

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

tag-icon • tag-icon ssh
chave privada e chave pública no mesmo diretório fazem com que o ssh falhe

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

Estou fazendo isso na linha de comando, e tanto a chave privada quanto a chave pública estão localizadas em meu diretório atual. Eles são nomeados id_rsa e id_rsa.pub respectivamente. Verifiquei por meio da impressão digital que elas correspondem às chaves pública e privada.

Quando eu emito o seguinte comando:

ssh -vT -i ./id_rsa usuário@remotehost

Recebo o seguinte erro: Permissão negada (chave pública).

No entanto, se eu renomear meu id_rsa.pub para outra coisa, tudo funcionará 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 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 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

Responder1

Consegui reproduzir seus sintomas usando uma chave pública e uma chave privada, que não correspondiam. Mesmo que ambas as chaves sejam permitidas porauthorized_keys, o login falhará quando as chaves pública e privada não corresponderem.

Pelo que posso dizer, acontece o seguinte.

  1. O cliente percebe que a chave privada está criptografada
  2. O cliente leu o arquivo de chave pública
  3. O cliente oferece esta chave ao servidor
  4. O servidor aceita a chave pública
  5. Cliente solicita senha
  6. O usuário digita a senha
  7. O cliente continua a autenticação usando chave privada incompatível

Ao remover a chave pública, o cliente solicitará 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 e descobrir que o servidor não a aceitará de qualquer maneira.

Responder2

Isso pode ser um bug no OpenSSH ou a chave no servidor authorized_keyse sua chave privada não correspondem, afinal. Quando a autenticação for bem-sucedida, você obterá

debug1: identity file ./id_rsa type -1

o que significa que o OpenSSH não pode carregar o arquivo de identidade (acho que a chave pública) nesse estágio. No código fonte na parte de carregamento da chave existe este 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 é fornecido no -iparâmetro + ".pub" como chave pública e terá sucesso conforme indicado no log. Sem a chave pública com sufixo ".pub" no diretório atual, isso falhará. Posteriormente, 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 irá enviá-la como uma mensagem de teste (?) que falhará por algum motivo. Sem a chave pública pré-carregada, ele tentará a chave privada e terá sucesso.

Não sei por que acontece a falha na chave pública (se tiver tempo, tentarei descobrir mais). Talvez haja alguma incompatibilidade nos arquivos .ssh/manipulados em comparação com outros caminhos ou, afinal, há alguma incompatibilidade com suas chaves.

Responder3

Tenho quase certeza de que é um problema de permissões. Verifique as permissões da pasta para garantir que não seja 770mas 740ou semelhante. Se você não estiver usando o .sshdiretório, isso poderá facilmente causar o problema que você está enfrentando.

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

informação relacionada