En ce qui concerne la troisième stratégie suggérée, en dehors de l'examen des options useradd -o -u userXXX tel que recommandé par @jlliagre, je ne suis pas familier avec l'exécution de plusieurs utilisateurs avec le même uid. (donc si vous décidez de le faire, je serais intéressé si vous pouviez mettre à jour le message avec les problèmes (ou succès) qui se posent...)
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/authorized_keys2" est que à moins que vous ne travailliez absolument jamais sur d'autres systèmes;
- alors au moins une partie du temps, vous devrez travailler avec des comptes utilisateurs et
sudo
La deuxième observation serait que si vous travaillez sur des systèmes qui aspirent à respecter les normes HIPAA, PCI-DSS ou des choses comme CAPP et EAL, alors vous devrez contourner les problèmes de sudo parce que;
- C'est une norme de l'industrie de fournir des comptes utilisateurs individuels non-root, qui peuvent être audités, désactivés, expirés, etc, généralement en utilisant une base de données utilisateur centralisée.
Donc; Utilisation de comptes personnalisés et de sudo
Il est malheureux qu'en tant qu'administrateur système, presque tout ce que vous aurez besoin de faire sur une machine distante nécessitera des autorisations élevées, cependant il est agaçant que la plupart des outils et utilitaires basés sur SSH soient buggés lorsque vous êtes en sudo
Par conséquent, je peux vous transmettre quelques astuces que j'utilise pour contourner les inconvénients de sudo que vous mentionnez. Le premier problème est que si la connexion en tant que root est bloquée en utilisant PermitRootLogin=no ou que vous n'avez pas la clé ssh en tant que root, alors cela complique le transfert de fichiers avec SCP.
Problème 1 : Vous voulez copier des fichiers depuis le côté distant, mais ils nécessitent un accès root, cependant vous ne pouvez pas vous connecter à la boîte à distance en tant que root directement.
Solution ennuyeuse : copiez les fichiers dans le dossier personnel, changez le propriétaire et copiez avec scp.
ssh userXXX@systemeàdistance, sudo su - etc, cp /etc/somefiles à /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefiles, utilisez scp pour récupérer les fichiers à distance.
Très ennuyeux en effet.
Solution moins ennuyeuse : sftp prend en charge le drapeau -s sftp_server, donc vous pouvez faire quelque chose comme ce qui suit (si vous avez configuré le sudo sans mot de passe dans /etc/sudoers);
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@hôteàdistance:/etc/resolv.conf
(vous pouvez également utiliser cette méthode de contournement avec sshfs, mais je ne suis pas sûr que ce soit recommandé... ;-)
Si vous n'avez pas les droits sudo sans mot de passe, ou pour une raison configurée cette méthode ci-dessus est cassée, je peux suggérer une autre méthode de transfert de fichiers moins ennuyeuse, pour accéder aux fichiers racine à distance.
Méthode Ninja de Port Forward :
Connectez-vous à l'hôte distant, mais spécifiez que le port distant 3022 (peut être n'importe quel port libre, et non réservé aux administrateurs, ie >1024) doit être renvoyé vers le port 22 du côté local.
[utilisateurlocal@machinelocale ~]$ ssh userXXX@hôteàdistance -R 3022:localhost:22
Dernière connexion : Lun Mai 21 05:46:07 2012 depuis 123.123.123.123
------------------------------------------------------------------------
C'est un système privé; blah blah blah
------------------------------------------------------------------------
Obtenez les droits root de la manière habituelle...
-bash-3.2$ sudo su -
[root@hôteàdistance ~]#
Maintenant vous pouvez utiliser scp dans l'autre sens pour éviter l'étape ennuyeuse de copier les fichiers;
[root@hôteàdistance ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf utilisateurlocal@localhost:~
motdepasse utilisateurlocal@localhost:
resolv.conf 100%
[root@hôteàdistance ~]#
Problème 2 : Transfert d'agent SSH : Si vous chargez le profil root, 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_SOCK sont réinitialisées, donc le transfert d'agent SSH est "cassé" sous sudo su -.
Réponse à moitié cuite :
N'importe quelle chose qui charge correctement un shell root, va réinitialiser l'environnement, cependant il y a une légère solution de contournement que vous pouvez utiliser lorsque vous avez BESOIN à la fois des autorisations root et de la possibilité d'utiliser l'Agent SSH, EN MÊME TEMPS
Cela crée une sorte de profil chimaère, qui ne devrait vraiment pas être utilisé, parce que c'est un hack méchant, mais cela est utile lorsque vous devez copier des fichiers depuis l'hôte distant en tant que root, vers un autre hôte distant.
Quoi qu'il en soit, vous pouvez activer la possibilité pour votre utilisateur de conserver ses variables d'environnement, en définissant ce qui suit dans sudoers;
Defaults:userXXX !env_reset
Cela vous permet de créer des environnements de connexion hybrides méchants comme ceci;
connectez-vous normalement;
[utilisateurlocal@machinelocale ~]$ ssh userXXX@hôteàdistance
Dernière connexion : Lun Mai 21 12:33:12 2012 depuis 123.123.123.123
------------------------------------------------------------------------
C'est un système privé; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971
créez un shell bash, qui exécute /root/.profile et /root/.bashrc. mais conserve SSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Ainsi ce shell a les autorisations root, et le $PATH root (mais un répertoire personnel buggé...)
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 faire des choses qui nécessitent du sudo root à distance, mais aussi l'accès à l'agent SSH comme ceci;
bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@quelque-autre-hôte-à-distance:~
/root/.ssh/authorized_keys 100% 126 0.1KB/s 00:00
bash-3.2#
