Connexion SSH: permission denied (public keys)

Support Debian
#1

Bonjour, ce soir je serai chez des amis et je voudrais me connecter, en ssh avec un pc portable linux depuis chez eux, à mon ordi librazik à la maison.

Je suis sur le cours suivant :

https://openclassrooms.com/fr/courses/4 … e-avec-ssh

Or, avant de partir chez les amis, je tente une connexion depuis l’ordi ( Librazik) maison sur lui même

Est ce que le serveur ssh est lancé ?

/etc/init.d/ssh start
[ ok ] Starting ssh (via systemctl): ssh.service.

ssh nicolas@localhost
Permission denied (publickey)

ssh nicolas@127.0.0.1
Permission denied (publickey)

Je suis allé dans la freebox / paramètres/ ports/ ajouter une direction de port/

https://debian-facile.org/images/file-R … c3748af556

J’essaie depuis mon portable sous MXlinux et la connexion ssh sur lui même fonctionne. Mais je ne parviens pas à connecter librazik en ssh depuis le mx (connexion denied. Public keys)

C’est donc un problème de paramètrage de ssh sur ma Librazik.

J’ai donc, considéré ma librazik comme client et générer deux clefs rsa. J’ai envoyé la clef publique sur lui même (serveur). Je sais c’est bizarre et peut être ai-je fait une bêtise.
avec la commande

ssh-copy-id nicolas@(adresse externe du pc)

J’ai fait de même depuis mon portable sous MXlinux depuis chez les amis : générer des clefs rsa, copie vers librazik . Réponse :

permission denied( public keys)

Que faut il que je fasse ?

Merci

Nico

#2

Pas tout à fait.
ssh va te faire une connection par clé entre un compte C1 sur une machine M1 vers un compte C2 sur une machine M2.
Il faut pour que l’auth par clé fonctionne que la clé publique de C1@M1 (ou bien celle que tu décides d’envoyer) soit présente dans le authorized_keys du compte C2@M2.
Donc:
1 - en local sur le compte nicolas où tu veux accèder à librazik, tu t’assures que ~/.ssh/authorized_keys contient bien ce qu’il y a dans ~/.ssh/id_rsa.pub, ou tu fais cat ~/.ssh/id_rsa.pub >>~/.ssh/authorized_keys pour l’y ajouter.
Tu testes ensuite ta connection locale, nicolas@(adresse lan de librazik) je zappe volontairement le test sur localhost, on s’en fout.
Ca, ça va tester si la connection par clé du service ssh fonctionne dans l’absolu.

2 - depuis le compte que tu utilises sur ton portable:

Ca, vu que tu as bloqué la connection par password, il ne peut pas amorcer une connection ssh pour transfèrer la clé.
Il faudrait faire venir la clé publique du compte du portable avec une clé usb pour la rajouter dans le autorized_keys.
Mais le plus rapide: tu réactives la connection par password, tu fais ton ssh-copy-id, puis tu redésactives l’accés password.

3 - une fois que tu auras transfèré cette clé publique du compte du portable sur librazik, peu importe que tu te connectes par ta redirection de port, ou l’ip du lan, ton compte de portable aura son accés sur nicholas@librazik.
Un compte sur le portable connecté à un compte sur librazik…

1 J'aime
#3

Comprendre la notion de clefs :joy:

Votre maison s’appelle librazik et vous avez déjà un jeu de clefs pour ouvrir la porte, le problème est tout simplement que vous avez oublié de prendre les clefs sur vous avant de partir chez vos amis. Au lieu de cela, vous êtes allé chez un serrurier et avez fait faire une clé sans donner d’original : un clé neuve de type rsa(la partie générer des clefs depuis le portable sous MXlinux ). La logique veut que cela ne fonctionne pas.
La solution est très simple : copier le jeu de clefs de la maison librazik vers votre compte sur le portable avant de sortir voir vos amis.
En pratique, comme vous vous êtes emmêlé les pinceaux avec la génération des clefs et copie, il convient de décider quel jeu de clefs est officiel et fait foi, autrement dit on ne va qu’une fois chez le serrurier, un seul jeu de clefs de type rsa suffit.

De plus, je suis sûr que vous avez fait

man ssh-copy-id

mais cette page en anglais n’est pas très claire et votre esprit était occupé par la redirection de port sur la box et la notion d’adresse externe. Vous avez bien fait de lancer

car cela a validé l’adresse publique et la redirection du port 22. Vous rappelez-vous si il y a eu demande de phrase de passe ou si vous utilisiez ssh-agent?
Vous pouvez vérifier l’horodatage des fichiers du répertoire ~/.ssh et la création de ~/.ssh/authorized_keys

cd
ls -l .ssh

et donc, a priori ce n’était pas une bêtise.
La bêtise était tout simplement de ne pas copier la clef
privée avant d’emporter le portable sous le bras.
La génération (inutile) de clefs sur nx a eu pour effet bénéfique de créer le répertoire ~/.ssh avec les bons droits ce qui n’est pas rien car c’est crucial.

sur le portable
cd
ls -l .ssh
cd .ssh
rm id_rsa*

depuis le compte nicolas sur librazik   déterminer l'IP du nx
ssh-copy-id  nicolas2@ip_nx
scp -p .ssh/id_rsa  nicolas2@IP_nx:.ssh

Vous pouvez aussi copier le fichier id_rsa.pub pour être cohérent.
Et retour sur le nx pour tenter une connexion sur librazik via l’adresse publique (et aussi via l’adresse locale tant qu’à faire).

Mon conseil :
sur les deux machines, installez keychain, une fois configuré par l’ajout dans le fichier .bashrc d’une ligne du genre

eval `keychain --eval id_rsa`

vous ne pourrez plus oublier vos clés, car à la première ouverture d’un terminal (ou d’une console tty) la phrase de passe vous sera demandée. Vos identifiants sont alors stockés dans ssh-agent et vous vous connectez sans mot de passe .

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#4

Des esprits tordus arrivent à utiliser ce mécanisme pour obtenir l’équivalent de sudo ou su en ne donnant aucun mot de passe.

fp2@debpacha:~$ ssh root@localhost id
uid=0(root) gid=0(root) groupes=0(root)
fp2@debpacha:~$ alias asroot='ssh root@localhost'
fp2@debpacha:~$ asroot pwd
/root
fp2@debpacha:~$

C’est effectivement la clef du problème

fp2@debpacha:~$ asroot  ls -l .ssh
total 8
-rw-r--r-- 1 root root 246 janv. 31  2018 authorized_keys
-rw-r--r-- 1 root root 664 janv. 31  2018 known_hosts
fp2@debpacha:~$ 
fp2@debpacha:~$ cat /home/fp2/.ssh/id_ed25519.pub | asroot tee -a .ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL2xg094HdAvf/cxnHfRGjcSIUfB0jlP/Jgsji68hVXO fp2@debpacha
fp2@debpacha:~$ asroot  ls -l .ssh
total 8
-rw-r--r-- 1 root root 340 sept. 15 14:27 authorized_keys
-rw-r--r-- 1 root root 664 janv. 31  2018 known_hosts
fp2@debpacha:~$

Pour information, la clé que j’avais copiée dans authorized_keys date en fait du 8 janvier 2003 et n’est plus acceptée par les versions récentes de Debian.

Pour la clé au nom bizarre voir https://blog.g3rt.nl/upgrade-your-ssh-keys.html

Le bon truc, c’est de mettre toujours la même phrase de passe.

Je me demande si je ne vais pas remplacer sudo et su par asroot .

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

#5

Salut , je viens de rentrer à la maison avec les deux ordi sous le nez.

  1. En interne, sur Librazik j’ai copié sa propre clef publique dans le fichier “authorised keys” .

Je teste une connexion de librazik vers lui même :

ssh nicolas@192.168.1.33 qui me renvoie

[code] ssh nicolas@192.168.1.33
Linux LibraZiK2-studio-audio 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3 (2019-09-02) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon May 13 23:17:46 2019
xset: unable to open display “”
xset: unable to open display “”
setterm: le terminal xterm-256color ne prend pas en charge --blank
setterm: impossible de (dé)configurer le mode powersave: Ioctl() inapproprié pour un périphérique [/code]

  1. j’ai copié la clef publique générée par mx sur librazik
  2. depuis mx
 ssh nicolas@ip-locale de librazik

même réponse qu’au point 1)

#6

Par contre ça fonctionne dans les deux sens . Ce que je ne pige pas c’est que je n’ai pas mis la clef publique de librazik sur MX . Comment vous expliquez ça ?

#7

Pour que tout le monde s’y retrouve, il faudrait faire un copier-coller incluant l’invite de commande. Parce que là, nous voyons que depuis le compte courant dont nous ne connaissons pas le nom vous vous êtes connecté au compte nommé “nicolas” qui n’avait pas été utilisé depuis le 13 mai au soir.
De plus, la séquence de démarrage de ce compte (vraisemblablement le fichier /home/nicolas/.bashrc ) semble faire des appels inconditionnels à des programmes qui supposent qu’un serveur d’affichage est présent et utilisable.
Pourrait-on avoir le retour complet (avec les prompts) de

hostname --fqdn
who
w
id
getent passwd $USER
id nicolas
getent passwd nicolas

depuis librazik et depuis NX ?

La commande

getent passwd nicolas | tr ':' '\t' | cut -f6

affiche le répertoire HOME de l’utilisateur nicolas, si ledit nicolas a bien un compte sur le système.

Et avec des sous-titres ? Parce que en l’état, la phrase n’a pas beaucoup de sens. Un copier-coller complet de commandes du genre

ssh-add -l
ssh -v nicolas@192.168.1.33 id

serait beaucoup plus explicite. Ou un tableau avec
de user@machine -> compte2@machine2 OK par exemple.
Remarquez que pour simplement tester les paramétrages et la syntaxe il est judicieux de mettre une commande anodine (telle que who id ou pwd…) à la fin de la commande ssh.

Sans les retours des commandes ci-dessus, nous n’expliquons rien.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#8 
nicolas@LibraZiK2-studio-audio:~$ hostname --fqdn

LibraZiK2-studio-audio
nicolas@LibraZiK2-studio-audio:~$ who
nicolas tty7 2019-09-16 19:25 (:0)
nicolas@LibraZiK2-studio-audio:~$ w
08:34:15 up 13:10, 1 user, load average: 0,23, 0,27, 0,17
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
nicolas tty7 :0 lun.19 13:10m 4:03 0.30s x-session-manag
nicolas@LibraZiK2-studio-audio:~$ id
uid=1000(nicolas) gid=1000(nicolas) groupes=1000(nicolas),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),60(games),108(netdev),113(lpadmin),115(scanner),120(pulse),123(vboxusers),1001(famille)
nicolas@LibraZiK2-studio-audio:~$ getent passwd $USER
nicolas:x:1000:1000:nicolas,:/home/nicolas:/bin/bash
nicolas@LibraZiK2-studio-audio:~$ id nicolas
uid=1000(nicolas) gid=1000(nicolas) groupes=1000(nicolas),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),60(games),108(netdev),113(lpadmin),115(scanner),120(pulse),123(vboxusers),1001(famille)
nicolas@LibraZiK2-studio-audio:~$ getend passwd nicolas
bash: getend : commande introuvable
nicolas@LibraZiK2-studio-audio:~$ getent passwd nicolas
nicolas:x:1000:1000:nicolas,:/home/nicolas:/bin/bash
nicolas@LibraZiK2-studio-audio:~$

#9

Depuis MX:
nicolas@mx:~
$ hostname --fqdn
mx
nicolas@mx:~
$ who
nicolas tty7 2019-09-17 08:37 (:0)
nicolas@mx:~
$ id
uid=1000(nicolas) gid=1000(nicolas) groupes=1000(nicolas),7(lp),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),108(netdev),114(vboxsf),116(lpadmin),119(scanner)
nicolas@mx:~
$ getent passwd $USER
nicolas:x:1000:1000::/home/nicolas:/bin/bash
nicolas@mx:~
$ id nicolas
uid=1000(nicolas) gid=1000(nicolas) groupes=1000(nicolas),7(lp),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),108(netdev),114(vboxsf),116(lpadmin),119(scanner)
nicolas@mx:~
$ getent passwd nicolas
nicolas:x:1000:1000::/home/nicolas:/bin/bash
nicolas@mx:~
$

#10 
nicolas@mx:~

$ ssh nicolas@192.168.1.33
Linux LibraZiK2-studio-audio 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3 (2019-09-02) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Sep 15 18:46:49 2019 from 192.168.1.26
xset: unable to open display “”
xset: unable to open display “”
setterm: le terminal xterm-256color ne prend pas en charge --blank
setterm: impossible de (dé)configurer le mode powersave: Ioctl() inapproprié pour un périphérique
nicolas@LibraZiK2-studio-audio:~$

#11

nicolas@LibraZiK2-studio-audio:~$ ssh nicolas@192.168.1.26
nicolas@192.168.1.26’s password:
Linux mx 4.9.189-antix.1-amd64-smp #1 SMP PREEMPT Tue Aug 13 12:28:30 BST 2019 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
No mail.
nicolas@mx:~
$

#12

Ben je ne comprends pas, le probléme est réglé non ?
De ce que je vois, maintenant, tu n’as plus le refus de connexion:

Si ?

Sinon, ça:

Ce sont des appel à X windows qui comme le suggère @littlejohn75 doivent venir du lancement d’une appli graphique dans /home/nicolas/.bashrc
Ce n’est pas normal de les mettre là, il faut mettre ces lancements d’applis ailleurs, ùais en attendant si tu te connectes en ssh -X, les fenètres s’afficheront sur ton client et tu ne devrais plus avoir de message d’erreur “xset”.

#13

Je n’ai pas placé de clef publique générée par lirazik dans MX et pourtant librazik affiche le terminal de mx . Alors qu’afficher le terminal de librazik sur mx m’a demandé de placer la clef publique générée par mx dans librazik . Ma question portait là dessus.

#14

Bon, ben je ne comprend toujours pas le soucis en fait.
Je ne vois pas le rapport entre tes échanges de clés et les affichages de terminal sur l’un ou sur l’autre, et je ne sais même pas ce que tu désigne par

Ca veut dire que tu as le prompt de mx quand tu te connectes dessus depuis librazik ?
Ca veut dire que tu as une fenètre supplémentaire qui s’ouvre sur librazik ?

Comprends pas.

#15

Désolé, je ne suis pas clair.
Je ne parviens pas à m’ expliquer que depuis librazik , en tapant la commande ssh nicolas@192.168.1.26 ( qui est l’adresse ip de mx ) j’obtienne le prompt de mx sans jamais n’avoir placé la clef publique de librazik sur mx ?

#16

Tu peux vérifier que le ~/.ssh/authorized_keys de nicolas sur mx contient bien une ligne pour la clé rsa.pub du compte librazik duquel tu te connectes.
Faute de savoir d’où vient cette clé, tu sauras d’où vient le fait que tu te connectes tranquille depuis librazik sur mx.
Si c’est la dernière clé ajoutée à l’authorized_keys, la date de dernière modification du fichier peut te donner une info sur le moment où tu as ajouté la clé, aussi.

Sinon, tu peux supprimer cet accès en enlevant la ligne correspondante du authorized_keys sur le compte nicolas de mx.

#17

ça fonctionne dans mon réseau local mais à l’extérieur non (??)

prompt pc boulot$ ssh 192.168.1.33@adresse publique du pc maison

pas de connection

J’ai pourtant créé, sur le pc boulot, un fichier authorised_keys dans le dossier .ssh où j’ai placé la clef publique du pc maison. J’ai aussi placé cette clef publique du pc maison dans le fichier known_host du pc du boulot

J’ai aussi fait l’inverse : placer la clef public du pc boulot dans le fichier authorised_keys du pc maison .

Rien de rien

#18

C’est authorized_keys, avec un ‘z’.

Non, ça faut pas, le fichier known_hosts n’a rien à voir avec tes échanges de clés personnelles, ce sont les chaines d’identification des serveurs ou tu te connectes.
C’est juste pour vérifier que le serveur ou tu te connectes sur une ip est bien toujours le même que la dernière fois que tu y es allé.
Normalement, tu n’as pas à manipuler toi même le fichier, sauf si ssh te le suggère (et il te dit ce qu’il faut faire).

#19

Je n’ai pas lu tout le fil mais il me semble que tu fais beaucoup de confusions.
J’appelle client la machine à partir de la quelle tu te connectes (ton pc boulot) et serveur (ton pc maison) la machine à laquelle tu veux te connecter.
Si tu es toto sur le client et que tu veux te connecter en tant que titi sur le serveur tu dois faire :

ssh titi@ip_du_serveur

Pour que l’authentification par clés fonctionne il faut au préalable avoir copié la clé publique de toto (par exemple /home/toto/.ssh/id_rsa.pub) dans le fichier /home/titi/.ssh/authorized_keys du serveur et uniquement cela.

#20

Salut

Et si on veut établir une connexion dans les deux sens et donc inverser le rôle du client et du serveur ?