Connexion SSH par clé

Résolu/Fermé
Garby
Messages postés
126
Date d'inscription
samedi 7 octobre 2006
Statut
Membre
Dernière intervention
26 mai 2022
- 29 janv. 2017 à 17:18
mamiemando
Messages postés
31322
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 août 2022
- 3 févr. 2017 à 09:35
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.



6 réponses

mamiemando
Messages postés
31322
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 août 2022
7 400
30 janv. 2017 à 10:16
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
0
Garby
Messages postés
126
Date d'inscription
samedi 7 octobre 2006
Statut
Membre
Dernière intervention
26 mai 2022
16
30 janv. 2017 à 12:16
Bonjour mamiemando et merci pour ta réponse.

Je n'ai pas procédé de la façon que tu décris car je ne suis pas parvenu à me connecter avec mot de passe sur le serveur (W10+Bash ubuntu) malgré les modifications apportées dans le sshd_config puisque par défaut l'accès par ssh avec mot de passe est bloqué ai-je lu...
D'où mes manipulations manuelles qui m'ont semblé conformes à ce que font les commandes qui permettent la configuration automatique mais peut être ai-je loupé quelque chose...

Pour me connecter avec mot de passe, j'ai modifié deux entrées du sshd_config :
- PermitRootLogin que j'ai passé de without-password à yes
- PasswordAuthentication que j'ai passé de no à yes.
J'ai ensuite relancé ssh.

Ensuite "ssh user@host" répond invariablement Permission denied, please try again... (user n'étant pas le root)
0
mamiemando
Messages postés
31322
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 août 2022
7 400
30 janv. 2017 à 16:41
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
0
Garby
Messages postés
126
Date d'inscription
samedi 7 octobre 2006
Statut
Membre
Dernière intervention
26 mai 2022
16
30 janv. 2017 à 19:33
Un mot de passe m'est demandé. C'est une fois que je l'ai tapé que j'ai le message permission denied.

ssh -vvv login@machine donne une très longue réponse...
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.

Merci une fois de plus du temps que tu prends pour m'aider.
0
mamiemando
Messages postés
31322
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 août 2022
7 400
Modifié par mamiemando le 31/01/2017 à 10:21
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@xxxxx
Enter 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@yyyyy
toto@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 status
nestat -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
0
Garby
Messages postés
126
Date d'inscription
samedi 7 octobre 2006
Statut
Membre
Dernière intervention
26 mai 2022
16
31 janv. 2017 à 12:28
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.org
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxxx.no-ip.org [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version MS_1.100
debug1: no match: MS_1.100
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
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,ssh-dss
debug2: 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.se
debug2: 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.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
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 aes128-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 152/320
debug2: bits set: 996/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 828
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug1: Host 'xxxx.no-ip.org' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:828
Warning: Permanently added the RSA host key for IP address 'xxx.xxx.xxx.xxx' to the list of known hosts.
debug2: bits set: 1023/2048
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: 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,password
debug3: start over, passed a different list gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,keyboard-interactive,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
XXXX@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 reply
debug1: Authentications that can continue: gssapi-with-mic,password
Permission 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-restart
Stopping OpenBSD Secure Shell server sshd
Starting OpenBSD Secure Shell server sshd
XXXX@SERVEUR-J:~/.ssh$sercice ssh status
sshd 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...
0
Garby
Messages postés
126
Date d'inscription
samedi 7 octobre 2006
Statut
Membre
Dernière intervention
26 mai 2022
16
31 janv. 2017 à 20:01
A force de retouches en tous genres dont j'ai fini par perdre le fil j'ai désinstallé le bash puis réinstallé.
Poursuivant mes recherches je suis tombé sur le lien ci-dessous qui m'a permis de me connecter en ssh sur le serveur depuis le NAS.
La solution à résidé dans la désinstallation puis la réinstallation de openssh-server...

https://superuser.com/questions/1111591/how-can-i-ssh-into-bash-on-ubuntu-on-windows-10

Reconfiguration des clés pour la connexion sans mot de passe en quelques minutes et tout fonctionne !

Un grand grand merci à toi mamiemando pour ta précieuse aide très claire et détaillée qui m'a permis de mieux comprendre ce mode de connexion.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
mamiemando
Messages postés
31322
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 août 2022
7 400
1 févr. 2017 à 10:35
Merci pour ton retour.

Dernières choses :

debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: 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 no
AuthorizedKeysFile %h/.ssh/authorized_keys
PasswordAuthentication no
UsePam no
ChallengeResponseAuthentication no
UseDNS no


... puis de relancer le service ssh pour prendre les changements en compte :

service ssh restart


Bonne continuation et merci pour ton retour :-)
0
Garby
Messages postés
126
Date d'inscription
samedi 7 octobre 2006
Statut
Membre
Dernière intervention
26 mai 2022
16
2 févr. 2017 à 17:11
Merci pour cette info complémentaire. Je vais faire la modif.
0
mamiemando
Messages postés
31322
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 août 2022
7 400
3 févr. 2017 à 09:35
De rien, bonne continuation !
0