What type of hardware are you using: Old laptop or computer
What YunoHost version are you running: 12.1.39
How are you able to access your server: SSH
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: Migration ancien serveur : Debian 12 + YunoHost 12, => backup complet (système + apps + données) vers nouveau serveur : Debian 12 + YunoHost 12, restauration d’une grosse archive (1,5 To). Compte principal : user (uid 1000, sudo), root désactivé à l’install Debian.
Describe your issue
Depuis la migration, impossible de se connecter en SSH avec user si AllowGroups est actif dans /etc/ssh/sshd_config.
Share relevant logs or error messages
Client :
ssh -vvv user@mon-domaine.fr
# ...
Offering public key: /home/user/.ssh/id_rsa ...
Auth. that can continue: publickey
No more authentication methods to try.
user@mon-domaine.fr: Permission denied (publickey).
Serveur (journalctl -u ssh) :
User user from ... not allowed because none of user's groups are listed in AllowGroups
Connection closed by invalid user user ... [preauth]
Donc sshd voit user comme « invalid user » et sans groupe autorisé, avant même l’étape d’auth.
Contrôles effectués
- Utilisateur YunoHost / Unix :
yunohost user info user # OK, user existe
getent passwd user # user:x:1000:1000:/home/user:/bin/bash
- Groupes YunoHost :
yunohost user group info admins
members: user, AUTRE-ADMIN
- Permissions YunoHost :
yunohost user permission list | grep -A3 ssh
ssh.main:
allowed: user
- Groupes Unix :
id user
... groups=1000(user), ..., 4001(admins), 5003(ssh.main)
getent group admins
admins:*:4001:AUTRE-ADMIN,user
getent group ssh.main
ssh.main:*:5003:user
Donc user est bien dans admins et ssh.main au niveau Unix.
- SSHD / AllowGroups :
/etc/ssh/sshd_config :
AllowGroups ssh.main sftp.main ssh.app sftp.app admins root
Vérifié par :
sshd -T | grep -i allowgroups
allowgroups ssh.main
allowgroups sftp.main
allowgroups ssh.app
allowgroups sftp.app
allowgroups admins
allowgroups root
sshd -T | grep -i pubkeyauthentication
pubkeyauthentication yes
- Clé SSH et permissions :
- Empreinte de
~/.ssh/id_rsa.pubcôté client = empreinte de/home/user/.ssh/authorized_keyscôté serveur. - Permissions :
ls -ld /home /home/user /home/user/.ssh /home/user/.ssh/authorized_keys
drwxr-xr-x root root ... /home
drwxr-xr-x user user ... /home/user
drwx------ user user ... /home/user/.ssh
-rw------- user user ... /home/user/.ssh/authorized_keys
ACL nettoyées (setfacl -b).
Test décisif
En commentant AllowGroups :
#AllowGroups ssh.main sftp.main ssh.app sftp.app admins root
puis :
systemctl restart ssh
la connexion SSH avec user fonctionne immédiatement en publickey.
Conclusion : la clé et les droits sont bons, c’est uniquement le couplage AllowGroups<=> résolution des groupes qui fait échouer la connexion, alors que getent et id disent que user est dans les bons groupes.
Questions :
-
Quelqu’un a‑t‑il déjà vu ce cas sur YunoHost 12 : utilisateur présent dans YunoHost + groupes Unix corrects, mais
sshdle considère comme « invalid user » et horsAllowGroupstant que cette directive est active ? -
Y a‑t‑il des points spécifiques à vérifier côté YunoHost (LDAP ???) pour s’assurer que
sshdutilise bien la même source d’utilisateurs/groupes quegetent? -
Est‑ce qu’il est recommandé, de ne pas utiliser
AllowGroups(mon instinct me dit que non) et de laisser commenté #AllowGroups dans/etc/ssh/sshd_config
Bon, regardons un peu