Se connecter en tant qu'utilisateur partagé est-il une mauvaise habitude?

35

J'ai travaillé dans des organisations où, au lieu de créer un nouvel utilisateur Ubuntu par personne souhaitant se connecter à une machine, les administrateurs système ajoutent simplement la clé ssh de chaque utilisateur .ssh/authorized_keyset que tout le monde sshest connecté à la machine sous la forme ( par exemple ) ubuntu@hostou ec2-user@host. (Incidemment, j'ai également vu cette pratique sur des mini-ordinateurs partagés en laboratoire.) S'agit-il d'une pratique acceptée ou d'un anti-modèle?

Les hôtes en question sont principalement utilisés pour les tests, mais certaines actions nécessitent généralement une configuration par utilisateur et sont suivies comme étant effectuées par un utilisateur spécifique, telles que la création et la diffusion de validations git, qui sont actuellement effectuées à l'aide d'un git générique. utilisateur.

ssh user-management

— utilisateur22a6db72d7249
source

23

Alors que beaucoup de gens ont des problèmes avec les relations polyamoureuses, d'autres les gèrent très bien, donc je ne pense pas que ce soit nécessairement une "mauvaise habitude" de partager un ... oh, tant pis, vous vouliez dire compte d' utilisateur .

— HopelessN00b

Awww, quelqu'un a édité le titre de clickbait .. :(

— Burgi

42

Oui c'est une mauvaise habitude. Il repose sur l’hypothèse de base selon laquelle il n’ya pas de malicieux (ce n’est pas le cas) et personne ne fait d’erreur. Avoir un compte partagé rend simple le fait que des choses se passent sans aucune responsabilité et sans limite - un utilisateur qui casse quelque chose casse la situation pour tout le monde.

Si ce schéma de partage d’identité a simplement pour but de réduire les coûts administratifs liés à la création de nouveaux comptes et au partage de la configuration, les administrateurs devraient peut-être investir un peu de temps dans un système d’automatisation tel que Ansible , Chef , Puppet ou Salt, qui permet de créer des utilisateurs. comptes sur plusieurs machines extrêmement simple.

— thkala
source

4

Ce n'est même pas de la malice, ni de l'incompétence. Lorsque tout ce que je fais ne fonctionne pas, je ne peux pas présumer que je me serais souvenu de tout ce qui a été fait pour ce compte.

— Djechlin

Principes de sécurité des données: Intégrité Confidentialité Disponibilité Responsabilité. +1 pour avoir utilisé le mot responsabilité

— DeveloperWeeks le

7

Pour commencer, cela ne me choque pas et je travaille dans un environnement extrêmement sécurisé. Tout le monde a son propre utilisateur, sa propre machine et sa clé ssh, et pour travailler sur un serveur, nous sommes ssh, en tant que root ou en tant qu’autre utilisateur, via un relais de journalisation si nécessaire. Tout ce que nous faisons est consigné comme ayant été effectué par le propriétaire de la clé ssh, la responsabilité est donc correcte.

Quelle serait l'alternative? Beaucoup de choses doivent être faites en tant qu'utilisateur, sans parler de root. Sudo? Cela convient pour certaines tâches très restreintes, mais pas pour l’administration système de la machine.

Cependant, je ne suis pas sûr de votre dernier paragraphe. Voulez-vous dire que quelqu'un pourrait pousser un git commit à un utilisateur générique? Cela enfreindrait la responsabilité, et casser la responsabilité est mauvais. Nous faisons git à partir de la machine où nous sommes connectés et nous nous authentifions à git avec notre clé ssh ...

L’authentification, l’autorisation et la comptabilité (AAA) sont l’expression classique: vous êtes authentifié avec votre clé ssh, vous êtes autorisé à faire tout ce que l’utilisateur générique peut faire parce que votre clé se trouve dans les authorised_keys et vous avez besoin de la comptabilité pour que vous fassiez ce que vous faites. peut être examiné après le fait.

— Law29
source

3

Ainsi, l'utilisateur générique dispose d'une sorte d'authentification (clé ssh?) Autorisée à modifier le dépôt git? Ce n'est vraiment pas bon. Non seulement parce que cela rompt la responsabilité de ce commit, mais aussi parce que n'importe qui peut copier cette clé et l'utiliser de quelque part. Quand j'ai ce genre de problème, je copie le code ou le diff sur ma machine locale et le valide à partir de là.

— Law29

2

Pourquoi exactement n'est pas sudoacceptable pour l'administration générale d'une machine?

— Blacklight Shining

4

vous êtes en tant que root dans "un environnement extrêmement sécurisé" oO?

— xaa

@BlacklightShining Si vous devez être capable de faire quoi que ce soit (chown, fichiers arbitraires chmod, installer des serveurs, monter des systèmes de fichiers), il n'y a rien à gagner à sshing en tant qu'utilisateur et à faire un sudo bash. À la place, ssh en utilisant soit un relais et / ou connectez tout à un serveur distant avec le propriétaire de la clé ssh dans laquelle ssh'd est installé.

— Law29

1

@ xaa Oui je le fais, et je ne vois pas de problème avec ça. Tout ce que je tape est connecté à d'autres machines. "Ne travaillez pas en tant que root" est une maxime totalement inutile lorsque la machine est un serveur où tout ce que vous voudrez peut-être faire nécessite que vous soyez root.

— Law29

3

Cela dépend clairement du cas d'utilisation du système. Si c'est un système de test de temps en temps, c'est bon pour moi. Nous avons aussi de tels systèmes. Si la société ne dispose d'aucun type de gestion des identités (LDAP, IPA), la création d'un nouvel utilisateur sans contrôle à distance sur un système aléatoire est une lourde tâche.

Mais pour le travail quotidien, quand une erreur rend toute une entreprise incapable de fonctionner, ce n’est pas une bonne idée.

— Jakuje
source

Exactement, si vous n'avez pas ou ne pouvez pas avoir un service d'annuaire, la création et la gestion de milliers de comptes est peu pratique.

— Jim B

Même si vous ne pouvez pas utiliser LDAP, vous aurez toujours un accès SSH (ou Powershell sous Windows). Vous aurez toujours besoin d'un moyen de gérer le fichier registered_keys sur vos hôtes pour tous ces comptes (à moins que vous ne partagiez également des mots de passe) et une tonne d'autres paramètres. Je me demande pourquoi vous n'utilisez pas un type de gestion de la configuration (par exemple, Puppet, Chef, Ansible) si vous avez autant d'utilisateurs ou de serveurs. Supprime ce fardeau et vous donne en retour le contrôle de processus, la responsabilité et l'auditabilité.

— Martijn Heemels

3

Toutes ces réponses répondent à la préoccupation de la responsabilité qui est un problème important et réel en soi, mais l'utilisation d'un compte partagé permet également des attaques pas si subtiles contre d'autres utilisateurs:

Considérez un attaquant créant un sshscript malveillant consignant le mot de passe saisi et le mettant dans lePATH utilisateur partagé (ce qui se fait facilement). Désormais, la prochaine personne qui se connecte à cette machine avec l'utilisateur partagé et décide de se sshrendre ailleurs (cette fois avec son compte personnel non partagé) risque d'avoir une mauvaise surprise.

Fondamentalement, utiliser un compte partagé sur un ordinateur revient à boire dans le bain de pieds de la piscine publique.

— ereOn
source

1

En général, le partage d'un compte est une mauvaise idée pour les raisons suivantes:

Tous les réglages effectués pour cet utilisateur affectent tous ceux qui se connectent. (Promt, alias, ...)
1. Vous perdez la possibilité de savoir qui a fait quoi (responsabilité)
2. Une erreur dans la configuration du compte (par exemple, la suppression accidentelle de ssh kay) affecte toutes les personnes utilisant ce compte utilisateur (dans cet exemple, lock-out).

Et bien sûr, il y a encore plus d'inconvénients ... Mais je ne veux pas en dire plus.

Le fait est que vous devez peut-être partager un compte pour gérer un service exécuté sous un compte d'utilisateur donné auquel tous les administrateurs doivent pouvoir accéder.

Dans une telle configuration, vous avez la possibilité de partager ce compte pour vous connecter (pour les raisons ci-dessus, je préférerais ne pas le faire) ou vous vous connectez individuellement et basculez l'utilisateur sur le compte partagé (je suggérerais cela).

Les outils d’audit vous permettraient toujours de savoir qui a exécuté quoi mais qui partage toujours le même compte.

— Gerhard
source