Plusieurs administrateurs système Linux travaillant en tant que root

Notre équipe compte trois administrateurs système chevronnés chargés d'administrer quelques dizaines de serveurs Debian. Auparavant, nous travaillions tous en tant qu'utilisateur root en utilisant l'authentification par clé publique SSH. Mais nous avons discuté de la meilleure pratique pour ce scénario et n’avons pu nous entendre sur rien.

La clé publique SSH de tout le monde est placée dans ~ root / .ssh / allowed_keys2

• Avantage: facile à utiliser, le transfert d’agent SSH fonctionne facilement, peu de frais généraux
• Inconvénient: audit manquant (on ne sait jamais quelle "racine" a changé), les accidents sont plus probables

Utiliser des comptes personnalisés et sudo

Ainsi, nous nous connecterions avec des comptes personnalisés à l'aide de clés publiques SSH et utiliserons sudo pour effectuer des tâches uniques avec des autorisations root . De plus, nous pourrions nous attribuer le groupe "adm" qui nous permet de visualiser les fichiers journaux.

• Avantage: bon audit, sudo nous empêche de faire des bêtises trop facilement
• Inconvénient: le transfert d’agent SSH est interrompu, c’est un problème car presque rien ne peut être fait en tant que non-root

Utilisation de plusieurs utilisateurs UID 0

C'est une proposition très unique de l'un des administrateurs système. Il suggère de créer trois utilisateurs dans / etc / passwd ayant tous l’ID 0 mais des noms de connexion différents. Il affirme que ce n'est pas réellement interdit et permet à tout le monde d'être UID 0 mais tout en étant capable d'auditer.

• Avantage: le transfert d’agent SSH fonctionne, l’audit peut fonctionner (non testé), pas de problème sudo
• Inconvénient: se sent assez sale - impossible de le trouver documenté comme moyen permis

Que suggérerais-tu?

La deuxième option est la meilleure à mon humble avis. Comptes personnels, accès sudo. Désactivez complètement l'accès root via SSH. Nous avons quelques centaines de serveurs et une demi-douzaine d'administrateurs système, c'est comme cela que nous procédons.

Comment se passe la transmission d'agent exactement?

De plus, si c’est si compliqué d’utiliser sudodevant chaque tâche, vous pouvez appeler un shell sudo avec sudo -sou basculer vers un shell racine avecsudo su -

En ce qui concerne la 3ème stratégie suggérée, autre que la lecture useradd -o -u userXXXattentive des options recommandées par @jlliagre, je ne suis pas habitué à exécuter plusieurs utilisateurs avec le même identifiant utilisateur. (Par conséquent, si vous continuez avec cela, je serais intéressé si vous pouviez mettre à jour le message avec tout problème (ou succès) qui pourrait survenir ...)

Je suppose que ma première observation concernant la première option "La clé publique SSH de tout le monde est placée dans ~ root / .ssh / allowed_keys2" est la suivante: à moins que vous ne travailliez jamais sur aucun autre système;

1. puis au moins une partie du temps , vous allez devoir travailler avec des comptes d'utilisateurs etsudo

La deuxième observation serait que, si vous travaillez sur des systèmes qui aspirent à la conformité HIPAA, PCI-DSS, ou à des logiciels tels que CAPP et EAL, vous devrez contourner les problèmes de sudo car:

2. C’est une norme de l’industrie de fournir des comptes d’utilisateur individuels non root, pouvant être audités, désactivés, expirés, etc., généralement à l’aide d’une base de données d’utilisateurs centralisée.

Alors; Utiliser des comptes personnalisés et sudo

Il est regrettable qu'en tant qu'administrateur système, presque tout ce que vous aurez besoin de faire sur une machine distante va nécessiter des autorisations élevées. Cependant, il est ennuyeux que la plupart des outils et utilitaires basés sur SSH soient interrompus pendant votre séjour. sudo

Par conséquent, je peux vous transmettre certaines astuces que j’utilise pour contourner les inconvénients de ce sudoque vous avez mentionné. Le premier problème est que si la connexion root est bloquée à l'aide PermitRootLogin=noou si vous n'avez pas la racine à l'aide de la clé ssh, alors les fichiers SCP ressemblent à un PITA.

Problème 1 : Vous voulez scp des fichiers du côté distant, mais ils nécessitent un accès root, cependant vous ne pouvez pas vous connecter directement à la boîte distante en tant que root.

Solution ennuyeuse : copiez les fichiers dans le répertoire de base, chown et scp down.

ssh userXXX@remotesystem, sudo su -etc, cp /etc/somefilesto /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesutilisez scp pour récupérer des fichiers à distance.

Très ennuyeux en effet.

Solution moins ennuyeuse : sftp supporte le -s sftp_serverdrapeau, vous pouvez donc faire ce qui suit (si vous avez configuré sudo sans mot de passe /etc/sudoers);

sftp  -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf 

(Vous pouvez aussi utiliser ce bidouillage avec sshfs, mais je ne suis pas sûr que ce soit recommandé ... ;-)

Si vous ne possédez pas de droits sudo sans mot de passe, ou si, pour une raison quelconque, la méthode ci-dessus est rompue, je peux vous suggérer une méthode de transfert de fichier moins ennuyeuse pour accéder aux fichiers racine distants.

Méthode Ninja Port Forward :

Connectez-vous à l'hôte distant, mais spécifiez que le port distant 3022 (qu'il soit libre ou non réservé aux administrateurs, c'est-à-dire> 1024) doit être renvoyé au port 22 du côté local.

 [localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------

Obtenez racine de manière normale ...

-bash-3.2$ sudo su -
[root@remotehost ~]# 

Maintenant, vous pouvez scp les fichiers dans l'autre sens en évitant l'étape fastidieuse de faire une copie intermédiaire des fichiers;

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \
 -P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password: 
resolv.conf                                 100%  
[root@remotehost ~]#  

Problème 2: Transfert d’agent SSH : Si vous chargez le profil racine, par exemple en spécifiant un shell de connexion, les variables d’environnement nécessaires pour le transfert d’agent SSH telles que SSH_AUTH_SOCKréinitialisées, le transfert d’agent SSH est donc "interrompu" sudo su -.

Réponse à moitié cuite :

Tout ce qui charge correctement un shell root va réinitialiser correctement l'environnement. Cependant, il existe une légère solution de contournement que vous pouvez utiliser lorsque vous avez besoin à la fois de la permission root ET de la possibilité d'utiliser l'agent SSH, EN MÊME TEMPS.

Cela crée une sorte de profil de chimère, qui ne devrait vraiment pas être utilisé, car c’est un hack méchant , mais qui est utile lorsque vous avez besoin de fichiers SCP de l’hôte distant en tant que root, vers un autre hôte distant.

Quoi qu'il en soit, vous pouvez indiquer à votre utilisateur de conserver ses variables ENV en définissant les paramètres suivants dans sudoers:

 Defaults:userXXX    !env_reset

Cela vous permet de créer de mauvais environnements de connexion hybrides comme ceci;

connectez-vous normalement;

[localuser@localmachine ~]$ ssh userXXX@remotehost 
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971

créer un shell bash, qui s'exécute /root/.profileet /root/.bashrc. mais conserveSSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

Donc, ce shell a les permissions root et root $PATH(mais un répertoire personnel encombré ...)

bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin

Mais vous pouvez utiliser cette invocation pour effectuer des tâches qui requièrent une racine sudo distante, mais également l’accès de l’agent SSH comme tel;

bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys              100%  126     0.1KB/s   00:00    
bash-3.2# 

La 3ème option semble idéale - mais avez-vous réellement essayé de voir ce qui se passait? Bien que vous puissiez voir les noms d'utilisateur supplémentaires à l'étape d'authentification, toute recherche inversée retournera la même valeur.

Autoriser l'accès ssh direct à la racine est une mauvaise idée, même si vos machines ne sont pas connectées à Internet / utilisez des mots de passe forts.

D'habitude, j'utilise 'su' plutôt que sudo pour l'accès root.

J'utilise (1), mais il m'est arrivé de taper

rm -rf / tmp *

un jour malheureux.Je peux voir assez pour être assez si vous avez plus d’une poignée d’admins.

(2) est probablement plus technique - et vous pouvez devenir une racine à part entière grâce à sudo su -. Les accidents sont toujours possibles.

(3) Je ne toucherais pas avec un poteau de chaland. Je l'ai utilisé sur Suns, afin d'avoir un compte root non-barebone-sh (si je me souviens bien), mais il n'a jamais été robuste - de plus, je doute que ce soit très vérifiable.

Répondre définitivement 2.

1. Cela signifie que vous autorisez l'accès SSH en tant que root. Si cette machine est en aucun cas publique, c'est juste une idée terrible; Lorsque j’exécutais SSH sur le port 22, mon VPS avait plusieurs tentatives d’authentification par heure. J'avais un IDS de base configuré pour enregistrer et interdire les IP qui faisaient plusieurs tentatives infructueuses, mais elles n'arrêtaient pas d'arriver. Heureusement, j'avais désactivé l'accès SSH en tant qu'utilisateur root dès que j'avais mon propre compte et configuré sudo. En outre, vous ne disposez pratiquement d'aucun journal d'audit.

2. Fournit un accès root au besoin. Oui, vous n’avez pratiquement aucun privilège en tant qu’utilisateur standard, mais c’est exactement ce que vous voulez; si un compte est compromis, vous voulez que ses capacités soient limitées. Vous souhaitez que tout accès super utilisateur nécessite une nouvelle saisie du mot de passe. De plus, l'accès sudo peut être contrôlé par le biais de groupes d'utilisateurs et limité à des commandes particulières si vous le souhaitez, ce qui vous permet de mieux contrôler qui a accès à quoi. En outre, les commandes exécutées en tant que sudo peuvent être consignées, ce qui permet une meilleure piste d'audit en cas de problème. Oh, et ne lancez pas simplement "sudo su -" dès que vous vous connectez. C'est terrible, pratique terrible.

3. L'idée de votre administrateur système est mauvaise. Et il devrait se sentir mal. Non, les machines * nix ne vous empêcheront probablement pas de le faire, mais votre système de fichiers et pratiquement toutes les applications existantes prévoient que chaque utilisateur possède un UID unique. Si vous commencez dans cette voie, je peux vous garantir que vous rencontrerez des problèmes. Peut-être pas tout de suite, mais finalement. Par exemple, malgré l’affichage de noms conviviaux, les fichiers et les répertoires utilisent des numéros UID pour désigner leurs propriétaires; Si vous rencontrez un programme qui a un problème avec des UID en double sur toute la ligne, vous ne pouvez pas changer un UID dans votre fichier passwd ultérieurement sans avoir à effectuer un nettoyage manuel sérieux du système de fichiers.

sudoest la voie à suivre. Cela peut causer des problèmes supplémentaires avec les commandes en cours d’exécution en tant que root, mais cela vous fournit une boîte plus sécurisée, à la fois en termes d’accès et d’audit.

Certainement l'option 2, mais utilisez des groupes pour donner à chaque utilisateur autant de contrôle que possible sans avoir besoin d'utiliser sudo. sudo devant chaque commande perd la moitié de l'avantage parce que vous êtes toujours dans la zone de danger. Si vous faites en sorte que les répertoires pertinents soient accessibles en écriture aux administrateurs système sans sudo, vous renvoyez sudo à l'exception, ce qui permet à chacun de se sentir plus en sécurité.

Auparavant, le sudo n'existait pas. En conséquence, avoir plusieurs utilisateurs UID 0 était la seule alternative disponible. Mais ce n'est toujours pas très bon, notamment avec une journalisation basée sur l'UID pour obtenir le nom d'utilisateur.

De nos jours, sudo est la seule solution appropriée. Oublie autre chose.

C'est documenté admissible par les faits. Les bureaux de BSD ont leur compte principal depuis longtemps, et les utilisateurs de base sont généralement acceptés sur les systèmes où csh est standard (faute professionnelle reconnue;)

Je suis peut-être bizarre, mais la méthode (3) est aussi ce qui m’a le plus marqué. Avantages: vous auriez le nom de chaque utilisateur dans les journaux et vous sauriez qui fait quoi en tant que root. Inconvénients: ils seraient chacun racine tout le temps, donc les erreurs peuvent être catastrophiques.

Je voudrais demander pourquoi vous avez besoin que tous les administrateurs aient un accès root. Les trois méthodes que vous proposez présentent un inconvénient distinct: une fois qu'un administrateur a exécuté une opération sudo bash -lou une action sudo su -similaire, vous perdez votre capacité à déterminer qui fait quoi et par la suite, une erreur peut être catastrophique. De plus, en cas de mauvaise conduite, cela pourrait même devenir bien pire.

Au lieu de cela, vous voudrez peut-être envisager une autre solution:

• Créez vos utilisateurs administrateurs en tant qu'utilisateurs réguliers
• Décidez qui doit faire quel travail (gestion d'Apache / gestion de postfix, etc.)
• Ajouter des utilisateurs à des groupes liés (tels que ajouter "martin" à "postfix" et "mail", "amavis" si vous l'utilisez, etc.)
• Autorisations de réparation (chmod -R g + w postfix: postfix / etc / postfix)
• ne donne que des pouvoirs sudo relatifs: (visudo -> laissez martin utiliser /etc/init.d/postfix, / usr / bin / postsuper, etc.)

De cette façon, martin serait capable de gérer postfixe en toute sécurité, et en cas d'erreur ou de comportement déplacé, vous ne perdriez que votre système postfixé, pas tout le serveur.

La même logique peut être appliquée à n'importe quel autre sous-système, tel qu'apache, mysql, etc.

Bien sûr, ceci est purement théorique à ce stade et pourrait être difficile à mettre en place. Cela ressemble à une meilleure façon d’y aller. Au moins pour moi. Si quelqu'un essaie cela, dites-moi s'il vous plaît comment ça s'est passé.