Forum Linux.redhat Connexion ssh - Permission denied (publickey,gssapi-keyex,gssapi-with-mic

Posté par  . Licence CC By‑SA.
Étiquettes :
0
29
août
2017

Bonjour,

Je suis débutant sous linux, et je suis bloqué depuis 2 jours sur une connexion ssh entre 2 serveurs. J'aimerais éviter de rester bloquer encore 2 jours de plus, donc je fais appel à vous.

Mon but est de transférer des fichiers d'un ancien serveur sur le nouveau avec un rsync.
Mais la connexion ssh ne fonctionne pas . Je vais essayer de vous donner le plus d'infos possible .

Ma requête rsync

[root@***~]# rsync -avzh /data/www/ ssh ec2-user@**:/data/www/ > /data/logRSYNC.txt

résultat :

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(600) [sender=3.0.6]

Donc j'en ai déduis que le problème vient de ssh et effectivement en executant la requête :

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: cipher ok: aes256-ctr [aes256-ctr,aes192-ctr,aes128-ctr]
debug3: cipher ok: aes192-ctr [aes256-ctr,aes192-ctr,aes128-ctr]
debug3: cipher ok: aes128-ctr [aes256-ctr,aes192-ctr,aes128-ctr]
debug3: ciphers ok: [aes256-ctr,aes192-ctr,aes128-ctr]
debug2: mac_setup: found hmac-sha1
debug3: mac ok: hmac-sha1 [hmac-sha1]
debug3: macs ok: [hmac-sha1]
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to ******* port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 464 bytes for a total of 485
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes256-ctr,aes192-ctr,aes128-ctr
debug2: kex_parse_kexinit: aes256-ctr,aes192-ctr,aes128-ctr
debug2: kex_parse_kexinit: hmac-sha1
debug2: kex_parse_kexinit: hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-sha1
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024 32)
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Wrote 16 bytes for a total of 1053
debug2: set_newkeys: mode 0
debug2: cipher_init: set keylen (16 -> 32)
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Wrote 52 bytes for a total of 1105
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x7f27516786f0)
debug2: key: /root/.ssh/id_dsa ((nil))
debug2: key: /root/.ssh/id_ecdsa ((nil))
debug3: Wrote 68 bytes for a total of 1173
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address *****.
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 372 bytes for a total of 1545
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

J'ai généré des clés pour l'utilisateur ec2-user dans home/ec2-user/.ssh. Mais il va chercher la clé dans root alors que j'ai précisé ec2-user@ (dans root il n'y a pas clé généré)

Si vous avez des idées , merci beaucoup

  • # re

    Posté par  . Évalué à 2.

    Bon sang, c'est toujours pénible de trouver un titre pour répondre dans le forum…
    Plusieurs choses:

    • Tu as un guide pour formater tes messages en dessous du champ ou l'on écrit le message. Quand on débute sur linuxfr ça dépanne bien, d'expérience ;)
    • ça donne quoi avec rcp? Ça sera pas idéal, mais ça peut éventuellement te débloquer
    • je suis intrigué par le ssh qui traîne entre la source et la destination… et je ne vois rien dans la doc de rsync à ce sujet? Enfin, pas sans l'option --rsh=

    • [^] # Re: re

      Posté par  . Évalué à 1.

      Merci du retour,

      rcp ne me convient dans la situation actuelle, j'ai essayé --rsh=ssh et ça me donne le même message d'erreur. Au delà de ça c'est ma connexion avec ssh qui n'est pas fonctionnelle . J'ai pas compris le premier point au sujet de mon message .

      Thanks.

      • [^] # Re: re

        Posté par  (site web personnel) . Évalué à 2.

        ec2-usertu as ecrit ca

        rsync -avzh /data/www/ ssh ec2-user@**:/data/www/ > /data/logRSYNC.txt

        Que vient faire la ce ssh.

        soit c est une typo dans le forum, soit c est une erreur et cela peut expliquer ton problème.

        ensuite tu lance la commande en root, donc la clef utilisée pour la session, est celle du user lançant la commande, c est a dire root (dans ton cas). si tu as généré des clef pour ec2-user, et bien ça sert a rien.

        il te fait le couple clef privé/clef public pour établir la session, la cléf privée sur la machine source dans $HOME/.ssh/ ($HOME de root dans ton cas), et concaténer clef public dans le fichier $HOME/.ssh/authorized_keys du user ec2-user de la machine cible.

        en pratique tu as le couple sur la machine source et ensuite tu fais ssh-copy-id ec2-user@ et cela met à jour tout ce qu il faut a partir du moment ou tu peux te connecter avec password sur la machine cible avec le user cible.

        /Enjoy

        • [^] # Re: re

          Posté par  . Évalué à 2.

          Pour le sujet du root… j'étais un peu fatigué l'autre jour, je l'ai vu mais j'ai eu un doute.

          Pour essayer d'expliquer plus clairement (je ne te répond pas à toi saurondemordor, mais ça me semble plus logique de continuer ce fil), dans la commande exécutée (en admettant que le ssh tout seul soit une typo), l'outil prend la clé de l'utilisateur qui lance la commande sur la machine qui initie la requête, root dans ce cas.
          Ensuite, l'outil vérifie que cet utilisateur à les accès nécessaires aux fichiers source (le 1er paramètre) ainsi qu'aux fichiers cibles (le 2nd) et fait son boulot.

          Autrement dit, si on à un utilisateur U1 sur la machine A qui tente de synchroniser le dossier /home/U2/src de la machine B vers le dossier /home/U3/dst de la machine C, on va utiliser les identifiants contenus dans le dossier ~U1/.ssh de la machine A, vérifier que U1@A est autorisé à se logguer en tant que U2 sur la machine B (en regardant dans le fichier ~U2/.ssh/authorized_keys de la machine B) ainsi qu'en tant que U3 sur la machine C (même raisonnement que pour U2).

          Sinon, il me semble avoir vu dans les logs de debugs que le fichier de clé est foireux.

          • [^] # Re: re

            Posté par  (site web personnel) . Évalué à 1.

            c est l'idée

            cependant il n y a pas reelement de contraintre sur le serveur source, sauf contrainte dans le fichier de config /etc/ssh/sshd_config sur serveur avec les directive Match.

            en effect c est la clef qui permet la session (de nimporte ou)
            mais ton pb est lié a ssh, pas a rsync a priori, donc dans un premier temps essaye de faire du debug avec le ssh en ligne de commande.

            1) peux tu te connecter avec le password sur le serveur cible?
            - oui
            -> pousse la clef avec ssh-copy-id
            -> reessaye de faire ssh, la passphrase doit etre demandée
            - connextion
            - oui => fait rsync rsync
            - non => il y a un pb avec la clef, detruit le couple clef pub/priv et recomence

            - non
            -> regle ce probleme pour avoir une sesson en ec2-user sur le serveur cible

            ensuite si tu doit transferer des gros volume de fichier, il es préférable de lancer rsync en mode daemon

      • [^] # Re: re

        Posté par  . Évalué à 2.

        J'ai pas compris le premier point au sujet de mon message .

        Hé bien, pour faire une citation par exemple, on mets une ligne vide suivie d'une ligne dont le 1er caractère est un >. Pour finir la citation, on mets une ligne vide.

        Pour afficher une sortie de console, donc du texte brut qui ne doit pas être interprété par le forum, on mets une ligne vide suivie de 3 backquotes (`), éventuellement suivie du langage (pour la coloration syntaxique). On insère le texte voulu à partir d'une nouvelle ligne, qui ne sera pas interprété (pas de gras, d'italique, de citation, etc) et pour finir, on mets à nouveau 3 backquotes sur une ligne dédiée.

        Ça permets de faire des choses comme ça:

        > ceci est un texte **non interprété**, idéal pour coller un log

        ou encore

        printf( "ceci est un texte avec la coloration syntaxique du langage %s\n", "C" );

  • # utilisateur root

    Posté par  (site web personnel) . Évalué à 0.

    Il va chercher la clé de root parce que tu lances la commande en root… Vu que tu as un accès interdit, tous les logs que tu vois, sont ceux de ta machine et de l'utilisateur qui lance la commande.

    • [^] # Re: utilisateur root

      Posté par  . Évalué à 0.

      Je suis en root sur mon serveur source , mais sur le serveur cible j'ai bien précisé ec2-user@***

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.