# Clefs SSH - copies retenues sur la machine

**URL:** <https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176>\
**Category:** Support Debian\
**Created:** [Septembre 16, 2019, 8:24 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176 "2019-09-16T20:24:39Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Acksop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/acksop/32/8207_2.png) [@Acksop](https://www.debian-fr.org/u/Acksop)\
**Post date:** [Septembre 16, 2019, 8:24 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/1 "2019-09-16T20:24:39Z")

</div>

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 :

```nohighlight
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:~$ 

```

```nohighlight
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 ?

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Septembre 16, 2019, 9:13 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/2 "2019-09-16T21:13:41Z")

</div>

> [@Acksop](#):
>
> Peut-on m’expliquer ?

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.

---

<div class="post-metadata">

**Author:** ![Acksop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/acksop/32/8207_2.png) [@Acksop](https://www.debian-fr.org/u/Acksop)\
**Post date:** [Septembre 16, 2019, 9:18 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/3 "2019-09-16T21:18:56Z")

</div>

bizarrement cela ne fonctionne pas …

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

```

et ceci non plus:

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

```

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Septembre 16, 2019, 9:30 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/4 "2019-09-16T21:30:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Acksop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/acksop/32/8207_2.png) [@Acksop](https://www.debian-fr.org/u/Acksop)\
**Post date:** [Septembre 16, 2019, 9:33 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/5 "2019-09-16T21:33:24Z")

</div>

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 !

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Septembre 17, 2019, 6:37 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/6 "2019-09-17T18:37:33Z")

</div>

Mets du 600 en droits 😉

---

<div class="post-metadata">

**Author:** ![Acksop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/acksop/32/8207_2.png) [@Acksop](https://www.debian-fr.org/u/Acksop)\
**Post date:** [Septembre 18, 2019, 7:28 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/7 "2019-09-18T07:28:45Z")

</div>

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

Je n’arrive pas a me décider …

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Septembre 18, 2019, 7:39 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/8 "2019-09-18T07:39:58Z")

</div>

Bonjour [**Acksop**](https://www.debian-fr.org/u/Acksop)

```nohighlight
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 :

```nohighlight
chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/id_rsa.pub

```

---

<div class="post-metadata">

**Author:** ![Acksop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/acksop/32/8207_2.png) [@Acksop](https://www.debian-fr.org/u/Acksop)\
**Post date:** [Septembre 18, 2019, 8:39 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/9 "2019-09-18T08:39:34Z")

</div>

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

Merci @Clochette et @anon29980398 !

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Septembre 18, 2019, 8:46 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/10 "2019-09-18T08:46:22Z")

</div>

> [@Acksop](#):
>
> Bien qu’obscur, ca me semble un petit peu plus clair les clefs SSH maintenant.

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.

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Septembre 18, 2019, 6:33 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/11 "2019-09-18T18:33:48Z")

</div>

> [@mattotop](#):
>
> Je suis hermétique à toute explication sur le domaine, je ne sais pas pourquoi.

Oui mais tu vois tout en noir, comme ton avatar 😃

> [@anon29980398](#):
>
> sauf le fichier **`~/.ssh/id_rsa.pub`** qui est en **`644`**

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

---

<div class="post-metadata">

**Author:** ![chris72](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/85e7bf/32.png) [@chris72](https://www.debian-fr.org/u/chris72)\
**Post date:** [Septembre 23, 2019, 7:08 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/12 "2019-09-23T07:08:08Z")

</div>

> [@Clochette](#):
>
> Je veux bien une explication sur le pourquoi du 644 à la place du 640 pour la clé publique.

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 😂

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Septembre 23, 2019, 10:13 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/13 "2019-09-23T10:13:44Z")

</div>

> [@chris72](#):
>
> 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

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.

---

<div class="post-metadata">

**Author:** ![chris72](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/85e7bf/32.png) [@chris72](https://www.debian-fr.org/u/chris72)\
**Post date:** [Septembre 23, 2019, 10:44 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/14 "2019-09-23T10:44:20Z")

</div>

> [@Clochette](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\
**Post date:** [Septembre 23, 2019, 12:28 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/15 "2019-09-23T12:28:05Z")

</div>

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é.

---

<div class="post-metadata">

**Author:** ![chris72](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/85e7bf/32.png) [@chris72](https://www.debian-fr.org/u/chris72)\
**Post date:** [Septembre 23, 2019, 12:48 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/16 "2019-09-23T12:48:57Z")

</div>

É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.

---

<div class="post-metadata">

**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\
**Post date:** [Septembre 23, 2019, 1:20 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/17 "2019-09-23T13:20:26Z")

</div>

> [@chris72](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![chris72](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/85e7bf/32.png) [@chris72](https://www.debian-fr.org/u/chris72)\
**Post date:** [Septembre 23, 2019, 1:50 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/18 "2019-09-23T13:50:14Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Septembre 24, 2019, 1:47 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/19 "2019-09-24T01:47:41Z")

</div>

> [@chris72](#):
>
> **Clochette** demandait une explication sur le fait que la **clé publique** était en `644`

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.

> [@anon70622873](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![Acksop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/acksop/32/8207_2.png) [@Acksop](https://www.debian-fr.org/u/Acksop)\
**Post date:** [Février 1, 2020, 1:23 UTC](https://www.debian-fr.org/t/clefs-ssh-copies-retenues-sur-la-machine/80176/20 "2020-02-01T01:23:35Z")

</div>

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.  
🙂 Un chmod 604 est-il un droit débile ? Je le crains fortement…