Matériel: PC Version de YunoHost: 11.1.16 (stable) J’ai accès à mon serveur : En SSH + Par la webadmin + (possible éventuellement : en direct avec un clavier/écran) Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui Si oui, expliquer: installation depuis une Debian fraîche
Description du problème
Je retardais la suppression du compte admin depuis la migration vers la version 11.1 et je m’y met seulement aujourd’hui.
Un problème cependant que je ne comprend pas trop :
mon utilisateur ‘arofarn’ est bien dans le groupe admins dans la webadmin et via la commande:
yunohost user group info admins
mail-aliases:
- root@maison.arofarn.info
- admin@maison.arofarn.info
- postmaster@maison.arofarn.info
- admins@maison.arofarn.info
- abuse@maison.arofarn.info
- webmaster@maison.arofarn.info
members:
- admin
- arofarn
permissions:
par contre, pour le reste du système l’utilisateur n’est dans aucun groupe et une tentative de connection via SSH échoue systématiquement (avec clé ou mot de passe):
arofarn@maison:~$ groups
groups: cannot find name for group ID 1000
1000
dans /var/log/auth.log je trouve : sshd[122498]: User arofarn from [my_IPv6] not allowed because not in any group
J’ai tenté en vain :
1- enlever puis remettre mon utilisateur dans le groupe admins depuis la webadmin
2- sudo usermod -a -G admins arofarn
Ça ressemble à une situation où ton utilisateur arofarn est aussi un utilisateur UNIX plutot que d’être un utilisateur LDAP … Du coup ça créé une maxi confusion de l’espace dans le système
Moi aussi je garde l’utilisateur admin surtout parce que son mot de passe est une passphrase, donc plus facile de s’en rappeler. Pour le premier utilisateur, le mot de passe est plus compliqué (alphanumérique et symboles) et je ne peux pas le changer pour l’instant car je devrais le mettre à jour dans tout mes dispositifs. Par contre pour le ssh, j’ai dû manuellement ajouter l’autorisation ssh à cet utilisateur dans la webadmin
Ca me semble une bonne piste étant donné que c’est certainement l’utilisateur que j’avais créé pendant l’installation de Debian avant d’installer Yunohost.
Jusqu’ici, ça n’avait pas posé de soucis.
Je viens de fouiller un peu les fichiers de configurations des utilisateurs :
ni le groupe “admins”, ni l’utilisateur “admin” n’apparaissent dans /etc/passwd ou /etc/group malgré que j’arrive à me connecter en SSH sur le compte admin et qu’une commande groups renvoies bien l’appartenance à admins
à l’inverse, mon utilisateur “arofarn” apparaît bien dans /etc/passwd mais il n’appartient pas à un groupe dans /etc/group. Pour le système, c’est un simple utilisateur qui n’a de droit que sur ses fichiers. La commande groups le confirme.
Comme évoquer avant, l’utilisateur “arofarn” est auss un utilisateur yunohost qui appartient à “admins” mais ça n’est valable que pour la webadmin (et le SSO de yunohost a priori).
J’en déduis qu’au moment d’une authentification (connection SSH, sudo,…), le système n’essaie de chercher un utilisateur dans le LDAP que s’il n’existe pas d’utilisateur classique ?
Si un utilisateur homonyme classique existe, il aura donc la priorité et les infos (groupes, droits,…) du LDAP sont ignorées.
Dans ce cas, est-ce qu’un coup de deluser --backup (sauvegarde de précaution et surtout pas de --remove-home) pourrait résoudre le problème en supprimant l’utilisateur classique pour ne laisser que celui du LDAP ?
Comme je n’ai pas l’habitude de la gestion d’utilisateur avec LDAP, je crains un peu les effets de bord indésirables.
Voilà qui confirme la présence de mon utilisateur dans les bons groupes du LDAP mais pas dans les fichiers ou systemd.
En tirant le fil, je découvre aussi le fichier /etc/nsswitch.conf :
admin@maison:~ $ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
passwd: files systemd ldap
group: files systemd ldap
shadow: files ldap
gshadow: files
hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
sudoers: files ldap
Je vois que la priorité est toujours la plus faible pour LDAP. Cependant, mettre LDAP en premier sur toutes les lignes ou il apparait en dernier n’a rien changé : ssh refusé (même après un service ssh restart) et idem pour sudo. Par contre, je n’ai pas redémarré le serveur, seulement SSH.
Je suis donc revenu à la configuration d’origine et à l’idée du deluser
D’abord j’ai supprimé l’utilisateur classique avec sudo deluser --backup depuis une connexion SSH avec le compte admin.
Toujours impossible de me connecter en SSH mais le message d’erreur dans /var/log/auth.log a changé : maintenant mon utilisateur arofarn est invalide
Comme j’ai aussi des soucis depuis le webadmin avec le compte admin, j’ai créé un compte temporaire admin_temp qui possède tous les droits admin sur le webadmin et SSH.
Après avoir vérifier que tous fonctionne comme attendu depuis ce compte admin_temp, je me suis connecté sur le webadmin pour supprimer le compte arofarn sans supprimer les données de l’utilisateur (qui sont sauvegardées quand même).
Je recrée dans la foulée le compte arofarn et lui redonne toutes les autorisation qui vont bien.
Là, une tentative de connexion SSH échoue de nouveau mais pour un problème de clés SSH alors qu’elles devraient être bonne dans le /home/arofarn/.ssh/authorized_keys. Il y a du mieux
En SSH depuis de le compte admin_temp, je vois que le propriétaire du répertoire /home/arofarn n’a pas été restauré et est resté avec uid numérique qui doit correspondre à celui du compte initial… sudo chown -R arofarn /home/arofarn résout le problème et je peux enfin me connecter en SSH avec ce compte, sans mot de passe et je peux aussi utiliser sudo
Je vais garder les compte admin et admin_temp quelques jours pour voir si des problèmes apparaissent mais pour l’instant tout à l’air de bien fonctionner.
) et découvre l’usage de 
