SSH Clé unique utilisable par un seul host

Arnaud · 23 juil. 2017, 15:59

C'est normal, car il a inversé les rôles.

Serveur1 se connectait à Serveur2, Serveur3, Serveur4, etc ... pour ses scripts. Or le dev a un accès à Serveur1, donc un accès aux autres serveurs. Il a changé la donne en faisant en sorte que la connexion SSH soit initiée à partir de Serveur2, Serveur3, Serveur4, etc ... vers Serveur1. Donc Serveur1 n'a que les clés publiques de Serveur2, Serveur3, Serveur4, etc ..., ce qui ne permet pas au dév sur Serveur1 d'accéder à quoi que ce soit.

29 juil. 2017, 21:44

piratebab a écrit : 22 juil. 2017, 21:20 Je crois que dans ton application, je n'ai toujours pas compris qui était le client, et qui était le serveur!
Ni qui tu veux identifier avec certitude. Le client ou le serveur ?

:-D

Je donne un accès sudo à une machine qui a des accès via clé ssh à d'autres machines.
Impossible du coup de protéger mes clés privées.

Le seul moyen est de transformer ce client ssh en serveur. Du coup les clés privées sont sur les clients, et plus sur la machine ou je donne des accès.

Comment expliquer ???

30 juil. 2017, 21:48

L'intéret des clefs asymétriques, c'est que cela permet d'identifier le client auprés du serveur, mais la réciproque n'est pas vrai. Donc en inversant comme tu l'a fais, tu n'as plus la même fonctionnalité, ce n'est pas équivalent.
Coté client, le serveur est authentifié par le "known host", qui est un fichier en clair, facile à manipuler.
Pour moi, la clef sert uniquement a authentifier le client, au même titre qu'un mot de passe, et à rien d'autre.
Il serait donc plus important de sécuriser les clients que le serveur. Ca bouscule un peu mes idées reçues! Dans ta manip, la personne qui à l'accès sudo peut ouvrir le serveur à n'importe quel client.
Le jour où tu lui retires les accés sudo, tu as interet à vérifier la liste des clients autorisés à se connecter à ce serveur.

Arnaud · 31 juil. 2017, 00:37

piratebab a écrit : 30 juil. 2017, 21:48 L'intéret des clefs asymétriques, c'est que cela permet d'identifier le client auprés du serveur, mais la réciproque n'est pas vrai. Donc en inversant comme tu l'a fais, tu n'as plus la même fonctionnalité, ce n'est pas équivalent.

Tout ce qu'il a fait, c'est échanger les rôles entre client et serveur, je ne vois pas de rapport avec l'asymétrie des clés.

piratebab a écrit : 30 juil. 2017, 21:48 Coté client, le serveur est authentifié par le "known host", qui est un fichier en clair, facile à manipuler.
Il serait donc plus important de sécuriser les clients que le serveur. Ca bouscule un peu mes idées reçues! Dans ta manip, la personne qui à l'accès sudo peut ouvrir le serveur à n'importe quel client.
Le jour où tu lui retires les accés sudo, tu as interet à vérifier la liste des clients autorisés à se connecter à ce serveur.

Ha oui, ça d'accord, je n'y avais pas pensé, effectivement il faudra faire le ménage dans les fichiers authorized_keys et known_hosts.

31 juil. 2017, 08:23

Justement, l’asymétrie des clefs, fait que l’authentification du client et du serveur n'est pas symétrique. Ce n'est pas un secret partagé, mais un secret connu du client seul (la clef privée).
Donc le choix du client et su serveur dépends de la machine que tu veux authentifier avec certitude.
Dans le cas que nous a soumis lol, il a donné les droits d’accès sudo sur le serveur. Il n'est donc pas très compliqué pour une personne malveillante de récupérer les identifiants du serveur, et donc d'usurper son identité. Il va donc récupérer toutes les connexions venant des clients (il faut aussi rediriger les connexions des clients vers le faux serveur, mais une redirection depuis le serveur légitime peut par exemple étre mise en place).
Suivant les cas, ça peut être sans danger, ou pas .....
Dans l'exemple que j'avais donné, la clef coté client n'est pas stockée sur le disque, mais générée à la demande en fonction d'un fingerprint logiciel et matériel . Certes la clef est présente à un moment donné en mémoire, mais c'est déjà plus compliqué pour la récupérer.

Arnaud · 31 juil. 2017, 10:47

En changeant les rôles du client/serveur, il a fallu générer une nouvelle paire de clés, enfin je suppose que c'est ce que lol a fait ( c'est ce que j'aurais fait ).

01 août 2017, 12:04

Arnaud a écrit : 31 juil. 2017, 10:47En changeant les rôles du client/serveur, il a fallu générer une nouvelle paire de clés, enfin je suppose que c'est ce que lol a fait ( c'est ce que j'aurais fait ).

C'est exactement ça.

piratebab a écrit :Le jour où tu lui retires les accés sudo, tu as interet à vérifier la liste des clients autorisés à se connecter à ce serveur.

Oui, évidemment.