☰

La clave privada y la clave pública en el mismo directorio hacen que ssh falle

tag-icon • tag-icon ssh
La clave privada y la clave pública en el mismo directorio hacen que ssh falle

Tengo este problema realmente extraño al intentar conectarme usando SSH a un servidor remoto.

Estoy haciendo esto desde la línea de comando y tanto la clave privada como la pública se encuentran en mi directorio actual. Se denominan id_rsa e id_rsa.pub respectivamente. He verificado mediante la huella digital que coinciden con las claves públicas y privadas.

Cuando emito el siguiente comando:

ssh -vT -i ./id_rsa usuario@remotehost

Recibo el siguiente error: Permiso denegado (clave pública).

Sin embargo, si cambio el nombre de mi id_rsa.pub por otro, funciona bien. ¿Qué podría estar causando esto? ¿Podría ser una configuración en el servidor remoto la que está causando esto?

El resultado de -vT cuando tengo id_rsa.pub en el mismo directorio es (y falla):

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).

El resultado de depuración cuando cambio el nombre de id_rsa.pub es:

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

Respuesta1

Pude reproducir sus síntomas usando una clave pública y una clave privada, que no coincidían entre sí. Incluso si las claves_autorizadas permiten ambas claves, el inicio de sesión falla cuando la clave pública y la privada no coinciden.

Por lo que puedo decir sucede lo siguiente.

  1. Aviso del cliente de que la clave privada está cifrada
  2. El cliente lee el archivo de clave pública
  3. El cliente ofrece esta clave al servidor.
  4. El servidor acepta la clave pública.
  5. El cliente solicita una contraseña
  6. El usuario ingresa la contraseña
  7. El cliente continúa la autenticación utilizando una clave privada que no coincide

Cuando eliminas la clave pública, el cliente te pedirá una contraseña sin saber si el servidor aceptará la clave. Esto significa que es posible que le pidan que escriba la contraseña de una clave privada y descubra que el servidor no la aceptará de todos modos.

Respuesta2

Esto puede ser un error en OpenSSH o la clave en el servidor authorized_keysy su clave privada no coinciden después de todo. Cuando la autenticación es exitosa, obtienes

debug1: identity file ./id_rsa type -1

lo que significa que OpenSSH no puede cargar el archivo de identidad (creo que la clave pública) en esa etapa. En el código fuente en la parte de carga de claves hay este fragmento ( 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;

Lo que significa que OpenSSH intentará cargar lo que se proporciona en -iel parámetro + ".pub" como clave pública y tendrá éxito como se indica en el registro. Sin la clave pública con el sufijo ".pub" en el directorio actual, esto fallará. Posteriormente al realizar la autenticación ( 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;
        }
    }

Si la clave pública estaba presente, OpenSSH la enviará como un mensaje de prueba (?) que fallará por algún motivo. Sin una clave pública precargada, probará la clave privada y tendrá éxito.

No sé por qué ocurre el error con la clave pública (si tengo tiempo, intentaré averiguar más). Tal vez haya alguna discrepancia en los archivos que .ssh/se manejan en comparación con otras rutas, o, después de todo, haya alguna discrepancia con sus claves.

Respuesta3

Estoy casi seguro de que es un problema de permisos. Verifique los permisos de la carpeta para asegurarse de que no sea 770pero 740o similar. Si no estás utilizando el .sshdirectorio, esto podría causar fácilmente el problema que estás experimentando.

Para corregir utilice chmod o-w /root. IaltamenteRecomiendo usar una carpeta dedicada para estas claves, ya que la configuración de permisos en las carpetas de inicio es complicada.

información relacionada