Question clé privée et clé publique dans le même répertoire provoque l'échec de ssh


J'ai ce problème vraiment étrange où j'essaie de me connecter via SSH à un serveur distant.

Je le fais à partir de la ligne de commande et la clé privée et la clé publique se trouvent dans mon répertoire actuel. Ils sont nommés id_rsa et id_rsa.pub respectivement. J'ai vérifié via l'empreinte digitale qu'ils correspondent aux clés publique et privée.

Quand j'émets la commande suivante:

ssh -vT -i ./id_rsa user @ remotehost

J'obtiens l'erreur suivante: Permission refusée (publickey).

Cependant, si je renomme mon id_rsa.pub en quelque chose d'autre, cela fonctionne bien. Qu'est-ce qui pourrait éventuellement être la cause de cela? Pourrait-il s'agir d'un paramètre sur le serveur distant à l'origine de cela?

La sortie de -vT quand j'ai le id_rsa.pub dans le même répertoire est (et cela échoue):

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

La sortie de débogage lorsque je renomme le id_rsa.pub est la suivante:

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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8

7
2018-04-08 16:28


origine




Réponses:


J'ai été capable de reproduire vos symptômes en utilisant une clé publique et une clé privée, qui ne se correspondaient pas. Même si les deux clés sont autorisées par allowed_keys, la connexion échoue lorsque les clés publique et privée ne correspondent pas.

D'après ce que je peux dire, il se passe ce qui suit.

  1. Avis du client que la clé privée est cryptée
  2. Le client a lu le fichier de clé publique
  3. Le client offre cette clé au serveur
  4. Le serveur accepte la clé publique
  5. Le client demande le mot de passe
  6. L'utilisateur entre son mot de passe
  7. Le client continue l'authentification en utilisant une clé privée incompatible

Lorsque vous supprimez la clé publique, le client vous demandera un mot de passe sans savoir si le serveur acceptera la clé. Cela signifie que vous serez peut-être invité à taper le mot de passe d'une clé privée uniquement pour constater que le serveur ne l'acceptera pas de toute façon.


6
2018-04-08 17:56





Cela peut être un bogue dans OpenSSH ou la clé dans le serveur authorized_keys et votre clé privée ne correspond pas après tout. Lorsque l'authentification réussit, vous obtenez

debug1: identity file ./id_rsa type -1

ce qui signifie que OpenSSH ne peut pas charger le fichier d'identité (clé publique, je pense) à cette étape. Dans le code source de la partie de chargement de clé, il y a cet extrait (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;

Cela signifie que OpenSSH va essayer de charger ce qui est donné dans -i paramètre + ".pub" en tant que clé publique et réussissez comme indiqué dans le journal. Sans la clé publique avec le suffixe ".pub" dans le répertoire actuel, cela échouera. Plus tard, lors de l'authentification (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 clé publique était présente, OpenSSH l'enverra sous forme de message test (?) Qui échouera pour une raison quelconque. Sans clé publique préchargée, elle essaiera la clé privée et réussira.

Je ne sais pas pourquoi l'échec avec la clé publique se produit (si j'en ai le temps, j'essaierai d'en comprendre plus). Il y a peut-être une incompatibilité des fichiers dans .ssh/ sont gérées par rapport aux autres chemins, ou il y a une certaine inadéquation avec vos clés après tout.


2
2018-04-08 20:00





Je suis presque certain que c'est un problème d'autorisations. Vérifiez les autorisations du dossier pour vous assurer que ce n'est pas le cas. 770 mais 740 ou similaire. Si vous n'utilisez pas le .ssh répertoire cela pourrait facilement causer le problème que vous rencontrez.

Pour corriger, utilisez chmod o-w /root. je très recommande d'utiliser un dossier dédié à ces clés, car la configuration des autorisations sur les dossiers de départ est délicate.


0
2018-04-08 16:39