Clefs SSH - copies retenues sur la machine

Support Debian
#1

Bonsoir,

J’ai un problème que je n’arrive pas comprendre… Je ne suis pas très bon en gestion de clefs ssh.
Voici ma console :

acksop@XXX:~$ ssh-copy-id gitea.local
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 2 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
acksop@gitea.local's password: 

Number of key(s) added: 2

Now try logging into the machine, with:   "ssh 'gitea.local'"
and check to make sure that only the key(s) you wanted were added.
acksop@XXX:~$ 

acksop@XXX:~$ ssh gitea.local
sign_and_send_pubkey: signing failed: agent refused operation
acksop@gitea.local's password: 
acksop@XXX:~$

Peut-on m’expliquer ?

#2

Non, mais peut être règler le probléme:
sur le client, tu executes juste ssh-add et tu essayes ensuite de te connecter.
Normalement, ça doit suffire.

#3

bizarrement cela ne fonctionne pas …

acksop@debian-gitlab:~$ ssh-add
Could not open a connection to your authentication agent.

et ceci non plus:

acksop@debian-gitlab:~$ ssh-add acksop@XXX
Could not open a connection to your authentication agent.
#4

Essayes (toujours au feeling):
eval $(ssh-agent -s)
tente de te connecter
puis si ça ne passe pas re ssh-add
puis retest
là ça devrait passer.

#5

heu non pas seulement, hélas là à la première lecture je ne comprenais pas vraiment…

acksop@debian-gitlab:~$ eval $(ssh-agent -s)
Agent pid 16366
acksop@debian-gitlab:~$ exit
déconnexion
Connection to gitea.local closed.
acksop@XXX:~$ eval $(ssh-agent -s)
Agent pid 12040
acksop@XXX:~$ ssh-add
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/acksop/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
acksop@XXX:~$ ssh gitea.local
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/acksop/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/acksop/.ssh/id_rsa": bad permissions
acksop@gitea.local's password: 
Linux debian-gitlab 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) 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 Sep 16 23:17:50 2019 from 192.168.1.XXX
acksop@debian-gitlab:~$

-> j’y ai mis basiquement un chmod 755 puis un chmod 750… pas chmod 700 mais je ne suis pas très bon de ce coté, je m’emmêle toujours au niveau des permissions vu que je bosse seul en général… depuis trop longtemps…

Merci @mattotop !

#6

Mets du 600 en droits :wink:

#7

pas nécessaire de l’executer ?
sur la clef ou sur le dossier ? ou tout ?

Je n’arrive pas a me décider …

#8

Bonjour Acksop

michel@deb1005pe:~$ ls -la ~/.ssh/
total 28
drwx------  2 michel michel 4096 sept. 25  2018 .
drwxr-xr-x 31 michel michel 4096 sept. 18 09:23 ..
-rw-------  1 michel michel 1535 juil. 30  2018 authorized_keys
-rw-------  1 michel michel 1675 juil.  9  2017 id_rsa
-rw-r--r--  1 michel michel  398 juil.  9  2017 id_rsa.pub
-rw-------  1 michel michel  888 juin  13 18:16 known_hosts
-rw-------  1 michel michel  666 juil.  8  2018 known_hosts.old
michel@deb1005pe:~$

Le répertoire ~/.ssh est en 700
Les fichiers contenus dans le répertoire ~/.ssh sont en 600
sauf le fichier ~/.ssh/id_rsa.pub qui est en 644

Donc :

chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/id_rsa.pub
1 J'aime
#9

Bien qu’obscur, ca me semble un petit peu plus clair les clefs SSH maintenant.

Merci @Clochette et @MicP !

#10

Tu as de la chance, moi ça fait des années que je fonctionne au feeling sans rien comprendre, avec ces trucs de clés.
Je suis hermétique à toute explication sur le domaine, je ne sais pas pourquoi.

#11

Oui mais tu vois tout en noir, comme ton avatar :smiley:

Je veux bien une explication sur le pourquoi du 644 à la place du 640 pour la clé publique.

#12

Regarde la colonne de gauche de la liste des fichiers contenus dans le dossier ~/.ssh/ en « oubliant » pour l’instant les deux dossiers « . » et « .. ». Tous sont en rw- --- --- sauf le fichier de la clé publique id_rsa.pub qui est en rw- r-- r-- Voyons ce que cela signifie.

Le premier caractère est un tiret « - » car il s’agit de fichiers ; ce serait un « d » (comme Directory) s’il s’agissait d’un répertoire.
Le propriétaire du fichier est concerné par les trois premières positions : rw- signifie que le fichier est Lisible (R comme Readable) ; il peut le Modifier (W comme Writable) ; il n’est pas exécutable car la troisième position est un « - » (s’il était éXécutable, cette position serait à X). En binaire cela donne 110 soit 6.
Les trois positions suivantes concernent les droits du groupe auquel appartient le propriétaire du fichier ; «--- » signifie qu’un membre de ce groupe ne peut ni lire, ni modifier, ni exécuter le fichier ; ici on a donc 000 en binaire, soit 0 en décimal.
Les trois dernières positions s’interprètent de la même façon pour tous les autres utilisateurs ; c’est encore 0 : ils n’ont aucun droit sur ces fichiers.
Pourquoi le fichier id-rsa.pub a-t-il rw- r-- r-- ? Justement parce qu’il est PUBLIC ! C’est la clé publique à communiquer à tous ceux qui voudront envoyer un message chiffré AVEC CETTE CLÉ à l’utilisateur propriétaire de la clé ; le propriétaire déchiffrera le message avec sa clé PRIVÉE (et donc SECRÈTE) id_rsa qu’il est le seul à posséder et à pouvoir utiliser. La clé id_rsa.pub étant publique, les droits sont rw- r-- r--, ce qui donne 110 100 100 en binaire, soit 644 en décimal.
En espérant que cela aide,
Bonne lecture :joy:

1 J'aime
#13

Merci ça je le sait

Mais la question est plutôt : je vois pas pourquoi 644 et pas un simple 640 ?
Finalement seul le propriétaire et à la limite root ont à avoir accès a ce fichier …
Encore plus radicale pour une clé de l’utilisateur root que je verrais en 600 tout simplement.

#14

Mais non justement : tout utilisateur doit pouvoir t’envoyer un message que tu seras seule à pouvoir lire ; cet utilisateur n’est pas nécessairement root et le propriétaire n’a pas besoin de crypter un message pour se l’envoyer.
Exemple : moi, Chris72, j’ai besoin de t’envoyer un message crypté que tu seras seule à pouvoir lire : je vais le crypter avec TA CLÉ PUBLIQUE ; je dois donc pouvoir la lire et l’utiliser. Tu décrypteras le message avec ta clé privée.

#15

Je suis d’accord avec @Clochette.
Il n’y a aucune nécessité d’avoir une clé SSH publique accessible à tout le monde et la clé privée doit bien entendu être accessible uniquement à son propriétaire.
Si on utilise les clés SSH pour chiffrer des fichiers ou des messages il faudra de toute façon transmettre la clé publique à son correspondant. Mais ce n’est pas l’usage le plus courant. Pour chiffre les messages on utilise plutôt GPG qui permet de publier facilement la clé publique. Ici on est dans le cadre d’une authentification par clé.

#16

Évidemment ! Mais il faut éviter de tout mélanger au risque de ne plus se comprendre.

Clochette demandait une explication sur le fait que la clé publique était en 644 ; la réponse générale est celle que je donne qui s’applique donc à toute situation. Il est vrai, cependant, que la clé publique reste sur le serveur SSH, dans le fichier authorized_keys, et qu’elle n’a pas vocation à être diffusée ailleurs.

Pensez, par exemple, à la clé publique pour chiffrer des courriers électroniques : comment est-elle utilisée ? Évidemment comme je le décris dans mon message précédent.

#17

Non, puisque dans ce cas on utilise GPG et non des clés SSH (en tout cas je n’ai jamais vu cet usage) et la clé publique est publiée sur un serveur de clés ou transmise directement dans le courriel.

1 J'aime
#18

Je n’ai pas dit qu’on utilise dans ce cas des clés SSH ! Je parle de CLÉ PUBLIQUE. SSH ou pas, cela fonctionne toujours de la même façon.

Je crois que nous ne nous comprendrons pas, aussi, j’arrête là sur ce sujet.

#19

Non je ne demandais pas une explication simplement sur l’utilisation d’une clé SSH comme tu l’entends mais comme le sujets le traite.

Pour moi c’est comme ça que je conçoit une clé SSH.

#20

644 --> permet la copie par tout le monde (groupe y compris) mais pas l’execution dans ce dossier… ce qui ne serait pas trop logique je l’accorde.

En tout cas j’ai bien mis ces droits sur mes fichiers.
:slight_smile: Un chmod 604 est-il un droit débile ? Je le crains fortement…