SSH Clé unique utilisable par un seul host

[lol]

Salut,

Je suis dans l'obligation de partager un accès à une machine.
Cette machine à elle-même accès via clé SSH à d'autres serveurs (Quelques scripts en on impérativement besoin).

J'ai beau cherche je ne vois pas comment empêher qu'on me pique les clés ssh pour les utiliser sur d'autres machines.
Bien entendu j'ai pensé à l'option from="IP" qu'on peut ajouter à .ssh/authorized_keys mais ce n'est pas sufisant: La machine a deux sorties Internet et une des deux sorties est en IP variable...

J'ai bien pensé à l'adresse MAC avec iptables, mais c'est trop facilement contournable.
Inutile de me dire qu'il ne faut pas que je laisse les clé ssh sur le serveur accessible par un tiers. Je n'ai pas le choix.

Bref, y-a-t-il un moyen de lier un accès SSH par clé à une machine unique (Hors IP et/ou Adresse Mac) ?

Merci.

[marcastro]

Cette machine à elle-même accès via clé SSH à d'autres serveurs

cette machine pourrait avoir accès aux autres serveurs par un bon mot de passe blindé connu de toi seul,sans accès par clés? si j'ai dit une connerie pas de problème je sors tout de suite

[piratebab]

google arrive bien à faire un finger print de chaque machine pour nous tracer .....
Pour cela ils regardent quels services tournent, leur version, les plugins installés dans le navigateur, la langue .....

Autre idée:
je suppose que tes clefs sont dans un rep. Est ce que les accés que tu dois déléguer doivent avoir les droits de lire ce rep ?

[Grhim]

ne pourrais-tu pas inclure une Passphrase afin de restreindre l'acces ?

[marcastro]

ne pourrais-tu pas inclure une Passphrase afin de restreindre l'acces ?

mon ssh n'utilise pas d'échange de clés, j'utilise un mot de passe bien blindé de 18 cacractères et c'est pourquoi j'avais suggéré cette possibilité.

[piratebab]

A mon avis, il n'y a pas d'intervention humaine lors de ces connexions SSH entre machines ...

[lol]

Salut,
Merci pour vos réponses,

A mon avis, il n'y a pas d'intervention humaine lors de ces connexions SSH entre machines ...

Exactement, ce sont des scripts qui se connectent via SSH à d'autres machines. Pas question de mot de passe donc.

google arrive bien à faire un finger print de chaque machine pour nous tracer .....
Pour cela ils regardent quels services tournent, leur version, les plugins installés dans le navigateur, la langue .....

C'était ma première idée le fingerprint de machine, mais je n'ai pas trouvé l'option avec SSH.

Autre idée:
je suppose que tes clefs sont dans un rep. Est ce que les accés que tu dois déléguer doivent avoir les droits de lire ce rep ?

Non, le dev à besoin d'un accès à toutes les fonctionnalités (il passe donc root avec sudo... Je sais...). Donc pas moyen de cacher les clés dans un répertoire.

J'ai pensé à deux choses entre-temps:
- Copier les clés 2 minutes avant que le script ne se lance, puis les effacer en fin de script. Les scripts se lancent la nuit, personne n'est au bureau à ce moment (Je sais c'est merdique...);
- Utiliser l'option command="/path/to/command arg1 arg2" dans .ssh/authorized_keys + PermitRootLogin forced-commands-only dans /etc/ssh/sshd_config.

Je crois que c'est la seconde solution la plus propre: L'accès via clés n'est possible que pour des commandes listées pour chaque clé. En dehors de ces commandes précises pas d'accès.
Faut que je fasse un essai (un peu chiant car il faut lister toutes les commandes des scripts, mais c'est probablement ce qui entraîne le moins de risques).

???

[piratebab]

j'ignorais qu'on pouvait limiter ssh à un certain nombre de commandes.
Mais si tu dis que tu as beaucoup de commandes à autoriser, est ce que ça vaut encore le coup ?
D'un autre coté, tu veux bétonner la sécurité et tu donnes l'accès total via sudo à quelqu'un qui n'est pas digne de confiance pour les clefs .....
Si on suit ta logique, tu dois aussi limiter le nombre de commandes autorisées via sudo.

[Arnaud]

Si il a un accès sudo, je pense que tu peux oublier. Au pire, tu peux prendre le problème inverse, en faisant en sorte que les autres machines se connectent à celle-là pour tes scripts. Mais c'est lourd d'inverser les mécanismes.

[lol]

Salut,

D'un autre coté, tu veux bétonner la sécurité et tu donnes l'accès total via sudo à quelqu'un qui n'est pas digne de confiance pour les clefs .....

C'est un développeur, il a besoin d'accéder à l'ensemble de la machine. Digne de confiance ou pas n'est pas la question. Je laisse traîner des clés ssh, on ne sais jamais.
Faut vraiment que je me penche vers Docker...

Si il a un accès sudo, je pense que tu peux oublier. Au pire, tu peux prendre le problème inverse, en faisant en sorte que les autres machines se connectent à celle-là pour tes scripts. Mais c'est lourd d'inverser les mécanismes.

J'ai "inversé" le problème effectivement. Mes scripts sont maintenant lancés depuis la machine "cliente".


On va dire que c'est réglé.
Mais ça reste un peu con de ne pas pouvoir attacher une clé ssh à une machine unique... On peut le faire pour une IP, une commande, pas une machine.

[PengouinPdt]

En quoi un dev a besoin des accès root ?
(j'aimerais comprendre, ni + ni -)
Et, vraiment s'il a besoin d'accès root, en a-t-il réellement besoin sur l'ensemble de la machine, mais plutôt sur certains binaires, non ?!

Après oui, tu peux "filtrer" SSH par l'adresse IP, MAC, l'id utilisateur, mais pas la machine en soit... tu définis comment une machine, autrement, que par son IP, sa MAC, voire sa clé d'hôte - je ne sais pas si cette dernière tu peux la gérer !

[lol]

En quoi un dev a besoin des accès root ?

Il faut un peu plus que du développement. Il a besoin d'installer des paquets, de faire des chown, créer des utilisateurs, bref plein de truc d'administration.

Et, vraiment s'il a besoin d'accès root, en a-t-il réellement besoin sur l'ensemble de la machine, mais plutôt sur certains binaires, non ?!

Trop chiant de lister tout les trucs auxquels il a besoin d'accéder. Si c'est pour qu'il vienne me voir toutes les 5mn en me disant qu'il y a un truc qui bloque...

Après oui, tu peux "filtrer" SSH par l'adresse IP, MAC, l'id utilisateur, mais pas la machine en soit... tu définis comment une machine, autrement, que par son IP, sa MAC, voire sa clé d'hôte - je ne sais pas si cette dernière tu peux la gérer !

C'est bien dommage. IP/MAC et ID peuvent se "spoofer"... Je pensais qu'il serait possible d'obtenir un fingerprint d'une machine (que serait une empreinte de l'ensemble: IP/MAC/ID/OS/Softs, etc.). Mais non semble-t-il...


La seule solution propre c'est des containeurs dans lesquels il peut faire ce qu'il veut.
Donc ce sera Docker (faut juste que je travaille un peu dessus pour voir comment ça se danse).

[PengouinPdt]

Là, y'a @clochette qui est au point sur les conteneurs, de type Docker, justement... au besoin.

Juste une idée comme ça, en l'air, et qui fera hurler certains : pourquoi tu n'utiliserais pas un compte 'sudo', qui te permettrait de journaliser son activité ?

[lol]

Là, y'a @clochette qui est au point sur les conteneurs, de type Docker, justement... au besoin.

Juste une idée comme ça, en l'air, et qui fera hurler certains : pourquoi tu n'utiliserais pas un compte 'sudo', qui te permettrait de journaliser son activité ?

Merci pour l'info au sujet de Docker.

Pour mon histoire ssh, j'ai pas envie d'avoir un nouveau truc à surveiller! L'inversion du sens des scripts suffit pour que je ne m'inquiète plus de rien...

[piratebab]

j'ai pas trop compris en quoi l'inversion du mécanisme à partiellement résolu ton problème. Que ce soit le client ou le serveur qui lance la connexion, il faut que les 2 possèdent la clef.
Une rapide recherche sur la façon d'identifier une machine afin de bloquer les usurpation d'identité est un problème bien connu des personnes qui travaillent sur les licences. Comment s'assurer que c'est bien la machine à qui la licence à été attribué qui se connecte ?
Un résultat de recherche: https://www.codeproject.com/articles/28 ... a-computer
Il doit y avoir moyen de faire beaucoup mieux.

[Arnaud]

j'ai pas trop compris en quoi l'inversion du mécanisme à partiellement résolu ton problème. Que ce soit le client ou le serveur qui lance la connexion, il faut que les 2 possèdent la clef.

Le serveur ne possède que la clé publique du client. Donc si le dev a un accès root sur le serveur, il ne pourra pas lancer une connexion par clé sur le client ( mais pourra éventuellement bloquer la connexion venant du client en vidant ~/.ssh/authorized_keys ).

[piratebab]

Ben justement, si l'utilisateur à accès au client, il a accès à la clef privée.
Dans le dernier lien que j'ai indiqué, le clef n'est plus stockée sur le client , mais calculée à la demande à partir d'un fingerprint matériel (chiffrage symétrique).
Car c'est bien le client qui doit être identifié de façon univoque.

[lol]

Salut

Intéressant ton article @Piratebab. Je vais regarder ça en détail.

Que ce soit le client ou le serveur qui lance la connexion, il faut que les 2 possèdent la clef.

Tu te trompes: Le serveur n'a que la clé publique, il ne peut pas se connecter au client.
En inversant la machine qui initie la connexion je règle mon problème: Le client (qui avait clé privée/publique dans .ssh) devient le serveur et il n'a plus QUE la clé publique dans ~/.ssh/authorized_keys.
Impossible depuis le serveur de se connecter au client sans clé privée... L'utilisateur n'a donc pas accès au client.

[lol]

Hello,

C'est du beurre Docker...


Ça ressemble à un chroot avec un accès réseau.
Ultra simple à mettre en place et super léger (pas de virtualisation).

Avec l'interface Web je peux déléguer la gestion des conteneurs, parfait!

[piratebab]

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 ?