Connexion SSH par clé Résolu/Fermé

Question

Bonjour, 
J'ai installé le Bash Ubuntu de Windows 10 sur une machine dont je veux sauvegarder les données sur un NAS distant, par utilisation de rsync.
Cette configuration a fonctionné auparavant alors que la machine à sauvegarder était sous XP avec Cygwin.
Aujourd'hui la machine XP a été remplacée par une sous W10, le NAS est toujours le même.
Mon problème est que je ne parviens pas à configurer SSH pour me connecter par clé et qu'avec mes très maigres connaissances linux et malgré toutes les recherches que j'ai faites je bloque.
A chaque tentative de connexion depuis le NAS le mot de passe du poste W10 m'est demandé.
Initialement j'ai récupéré le contenu du fichier id_rsa.pub du NAS que j'ai copié dans le authorized_keys du W10. J'ai modifiés les droits du dossier .ssh en drwxr--r-- (744) et des fichiers authorized_keys et known_hosts en -rw-r--r-- (644)
J'ai redémarré ssh et à la connexion depuis le NAS le mot de passe m'est demandé...
Après, j'ai essayé tout un tas de recettes trouvées sur google qui en ont sauvé d'autres mais qui n'ont pas fonctionné pour moi...
Alors si une idée vous vient...
Par avance merci.
Configuration: Windows / Firefox 51.0

mamiemando · Answer

Bonjour,
Concernant la connexion en ssh il faut créer ta clé privée/publique comme il faut, avec les bons droits, et au bon endroit côté client. Ceci est géré par la commande ssh-keygen.
ssh-keygen -t dsa -b 1024
(Garder tous les paramètres par défaut, choisir une passphrase qui servira de mot de passe pour activer la clé).
Côté serveur, ta clé publique doit être écrite au bon endroit dans /home/toto/.ssh/.authorized_keys si ton login sur la machine distante est toto). La première fois, il faut donc l'installer en se connectant par mot de passe (ou via un autre compte). En admettant que l'authentification par mot de passe soit possible. Sur la machine où tu as généré ta clé (machine cliente) lance
ssh-copy-id -i ~/.ssh/id_dsa.pub toto@machine.fr
... ou machine.fr correspond au nom ou à l'IP du serveur ssh.
Note qu'à gauche on donne le chemin de la clé publique. La clé privé doit rester chez toi et ne jamais être diffusée sinon la clé est compromise. Cette commande ajoute ta clé publique à la fin de /home/toto/.ssh/.authorized_keys sur le serveur. Partant de là, l'authentification par clé doit être possible.
On commence par activer l'agent ssh pour ne pas avoir à taper la passphrase de la clé ssh sans arrêt :
ssh-add
À partir de maintenant on peut utiliser la clé de manière transparente :
ssh toto@machine.fr
... et là tu es sensé être directement connecté.
Bonne chance

mamiemando · Answer

Bonjour,
1) Entre le moment où tu tapes ta commande ssh et le "Permission denied", est ce qu'un mot de passe t'es demandé ?
- Selon la manière dont est configuré sshd, celui-ci devrait au moins te demander de tenter un mot de passe (sauf si l'authentification par mot de passe est désactivée).
- Te connecter avec l'option -vvv te permettrait peut-être de mieux comprendre ce qui se passe :
ssh -vvv login@machine
2) Est-ce que user correspond à un login existant sur la machine qui héberge le serveur ssh ?
3) Si ton login côté client et côté serveur (user dans ton exemple) diffèrent, utilises-tu bon login côté serveur ?
4) Est-ce que ta clé publique (~/.ssh/id_dsa.pub) apparaît côté serveur dans ~user/.ssh/authorized_keys ?
5) Es-tu sûr que tu n'as pas filtré le port ssh ? Est-ce que le serveur est lancé ? Écoute-t'il bien sur le port 22 ?
netstat -ntlp
6) Si tu as modifié la configuration ssh, as-tu pensé à relancer le service ssh ?
service ssh restart
Au besoin je peux te copier coller mon /etc/ssh/sshd_config de sorte à n'autoriser que les connexions par clé, mais attention à être sûr au préalable de pouvoir accéder à la machine !
Bonne chance

mamiemando · Answer

Un mot de passe m'est demandé. C'est une fois que je l'ai tapé que j'ai le message permission denied. 
Est-ce que c'est un mot de passe ou une passphrase qui t'es demandé ?
Exemple 1 : authentification par clé :
(mando@velvet) (~) $ ssh toto@xxxxxEnter passphrase for key '/home/mando/.ssh/id_rsa':
Ici il faut taper la passphrase que tu as donné quand tu as créé ta clé ssh. C'est cette même passphrase qui est demandée quand tu fais ssh-add que tu peux utiliser pour tester. Si tu ne te souviens plus de la passphrase, régénère ta clé.
Exemple 2 : authentification par mot de passe :
(mando@velvet) (~) $ ssh toto@yyyyytoto@yyyyy's password:
Ici il faut taper le mot de passe toto sur la machine yyyyy. Si ceci apparaît, c'est que ta clé publique ssh n'a pas été installé dans /home/toto/.ssh/authorized_keys sur la machine yyyyy. Il faut alors reprendre ce que je t'ai indiqué plus haut avec ssh-copy-id.
ssh -vvv login@machine donne une très longue réponse... 
La réponse peut être longue si sshd fait une résolution inverse. Tu peux décommenter ou ajouter UseDNs no dans /etc/ssh/sshd_config. Puis relance sshd avec la commande service ssh restart ou /etc/init.d/ssh restart.
Je l'ai faite sur le NAS pour me connecter sur le serveur et sur le serveur pour me connecter sur le NAS (ça marche dans ce sens) et je compare les réponses pour essayer d'y comprendre quelque chose. Je te donnerai je fruit de mes réflexions demain. 
Attention si on reprend mon exemple précédent, ajouter la clé publique de mando chez toto@xxxxx permet à mando de se connecter à toto@xxxxx, mais la réciproque est fausse. Il faudrait pour cela que toto installe sa clé publique chez mando@velvet.
Ce sont vraiment deux choses indépendantes.
Merci une fois de plus du temps que tu prends pour m'aider.
De rien :-)
Si tu es bloqué, en supposant que toto@yyyyy corresponde au compte sur lequel tu veux te connecter en ssh
1) Vérifie que ta clé publique apparaît bien dans /home/toto/.ssh/authorized_keys sur le serveur ssh. Est-ce le cas ?
2) Que donnent les commandes suivantes sur le serveur ssh :
service ssh statusnestat -ntlp
3) Y a-t'il un pare-feu, un antivirus, ou un proxy entre les deux machines ? Ou sur l'une des deux machines ?
4) Que donne côté client ssh -vvv toto@yyyyy côté client ? (copie colle le résultat) ?
5) Que contient le fichier /etc/ssh/sshd_config sur le serveur (yyyyy)
Bonne chance

Garby · Answer

Bonjour mamiemando Ci-dessous le résultat de la tentative de connexion depuis le client (le NAS) en mode verbose DiskStation2> ssh -vvv XXXX@xxxx.no-ip.orgOpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009debug2: ssh_connect: needpriv 0debug1: Connecting to xxxx.no-ip.org [xxx.xxx.xxx.xxx] port 22.debug1: Connection established.debug1: permanently_set_uid: 0/0debug1: identity file /root/.ssh/identity type -1debug1: identity file /root/.ssh/id_rsa type -1debug1: identity file /root/.ssh/id_dsa type -1debug1: Remote protocol version 2.0, remote software version MS_1.100debug1: no match: MS_1.100debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_5.2debug2: fd 3 setting O_NONBLOCKdebug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1debug2: kex_parse_kexinit: ssh-rsa,ssh-dssdebug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.sedebug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.sedebug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96debug2: kex_parse_kexinit: none,zlib@openssh.com,zlibdebug2: kex_parse_kexinit: none,zlib@openssh.com,zlibdebug2: 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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1debug2: kex_parse_kexinit: ssh-rsa,ssh-dssdebug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbcdebug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbcdebug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1debug2: kex_parse_kexinit: nonedebug2: kex_parse_kexinit: nonedebug2: 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-sha1debug1: kex: server->client aes128-ctr hmac-sha1 nonedebug2: mac_setup: found hmac-sha1debug1: kex: client->server aes128-ctr hmac-sha1 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug2: dh_gen_key: priv key bits set: 152/320debug2: bits set: 996/2048debug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug3: check_host_in_hostfile: filename /root/.ssh/known_hostsdebug3: check_host_in_hostfile: match line 828debug3: check_host_in_hostfile: filename /root/.ssh/known_hostsdebug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hostsdebug1: Host 'xxxx.no-ip.org' is known and matches the RSA host key.debug1: Found key in /root/.ssh/known_hosts:828Warning: Permanently added the RSA host key for IP address 'xxx.xxx.xxx.xxx' to the list of known hosts.debug2: bits set: 1023/2048debug1: ssh_rsa_verify: signature correctdebug2: kex_derive_keysdebug2: set_newkeys: mode 1debug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug2: set_newkeys: mode 0debug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug2: service_accept: ssh-userauthdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug2: key: /root/.ssh/identity ((nil))debug2: key: /root/.ssh/id_rsa ((nil))debug2: key: /root/.ssh/id_dsa ((nil))debug1: Authentications that can continue: gssapi-with-mic,passworddebug3: start over, passed a different list gssapi-with-mic,passworddebug3: preferred publickey,keyboard-interactive,passworddebug3: authmethod_lookup passworddebug3: remaining preferred: ,keyboard-interactive,passworddebug3: authmethod_is_enabled passworddebug1: Next authentication method: passwordXXXX@xxxx.no-ip.org's password: debug3: packet_send2: adding 48 (len 63 padlen 17 extra_pad 64)debug2: we sent a password packet, wait for replydebug1: Authentications that can continue: gssapi-with-mic,passwordPermission denied, please try again. Du peu que j'arrive à comprendre la clé publique est bien trouvée dans le known_hosts du serveur... Et pour répondre à une de tes questions je l'ai bien recopiée dans le known_hosts du dossier .ssh du bon utilisateur (XXXX). Et puis surprise à l'instant : la commande sercice ssh status me répond sshd is not running or je n'ai aucun message d'erreur lorsque je relance ssh après une modif : XXXX@SERVEUR-J:~/.ssh$ sudo service ssh --full-restartStopping OpenBSD Secure Shell server sshdStarting OpenBSD Secure Shell server sshdXXXX@SERVEUR-J:~/.ssh$sercice ssh statussshd is not running J'imagine que c'est une bonne raison que ça ne fonctionne pas... Je viens aussi de lire sur un autre forum qu'il est suggéré d'utiliser un autre port que le 22 pour le ssh du bash W10 et qu'il faut mettre ListenAddress à 0.0.0.0 dans le sshd_config... Ca n'est pas très argumenté mais au point ou j'en suis, je fais le test cet apm... To be continued...

mamiemando · Answer

Merci pour ton retour.
Dernières choses :
debug1: identity file /root/.ssh/identity type -1debug1: identity file /root/.ssh/id_rsa type -1debug1: identity file /root/.ssh/id_dsa type -1
C'est une mauvaise habitude : de manière générale il ne faut être en root que quand c'est strictement nécessaire, ça évite les fausses manipulations et limite un certains nombre d'autres risques.
- Ce n'est pas le cas quand tu veux te connecter en ssh.
- Il faut idéalement empêcher les connexions en root par ssh, c'est le premier login qui sera attaqué (voir /etc/ssh/sshd_config)
- Idéalement, une fois que la clé fonctionne, il vaut mieux ne plus autoriser que les connexions par clé.
Pour cela je recommande de corriger/compléter la configuration du serveur ssh de sorte à avoir notamment ces directives :
PermitRootLogin noAuthorizedKeysFile  %h/.ssh/authorized_keysPasswordAuthentication noUsePam noChallengeResponseAuthentication noUseDNS no
... puis de relancer le service ssh pour prendre les changements en compte :
service ssh restart
Bonne continuation et merci pour ton retour :-)

Garby · Answer

Merci pour cette info complémentaire. Je vais faire la modif.

Connexion SSH par clé

6 réponses

Discussions similaires