Connexion ssh refusée pour un utilisateur spécifique

Mon serveur YunoHost

Matériel: NUC
Version de YunoHost: 11.2.9.1 (stable)
J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran | …
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : non

Description du problème

Bonjour,

J’ai migré mon serveur depuis un Raspberry vers un NUC. J’ai effectué les sauvegardes sur le Raspberry et restauré sur le NUC. Tout s’est bien passé mais j’ai un souci avec l’utilisateur principal : la connexion ssh est refusée : Permission denied, please try again. C’est la seule erreur que j’ai. Le compte fait bien partie du groupe administrateurs. D’ailleurs je peux me connecter à la console web.

Le ssh fonctionne. Depuis le réseau local je peux me connecter avec root. Je peux aussi me connecter avec un autre compte admin créé pour tester, mais pas avec mon compte principal.

Pour débloquer cette situation. Quelles sont les paramètres à vérifier? Quels sont les logs à creuser s’il vous plait ?

Quelques questions :

  • Utilises-tu un mot de passe ou une clé privée pour te connecter ?
  • Dans un terminal avec l’utilisateur root, lance la commande tail -f /var/log/auth.log -n 0, puis dans un autre terminal essaie de te connecter avec ton utilisateur bloqué, avec l’option -vvv pour rendre la connexion plus verbeuse. Après la tentative, tu peux quitter le tail ... avec CTRL+C.

Partage le résultat de tout ça.

Pour l’instant j’utilise le mot de passe. J’ai essayé avec la clé privée mais ça ne fonctionne pas plus.

Côté commande ssh -vvv, il cherche les différents chemins possible pour la clé puis il continue avec le mot de passe. Après la saisie il ne se passe rien d’autre que Permission denied, please try again.

Coté logs, on a un début d’explication

Jan 18 13:59:06 myServer sshd[332781]: Connection from 192.168.0.37 port 64634 on 192.168.0.20 port 22 rdomain ""
Jan 18 13:59:06 myServer sshd[332781]: User paul from 192.168.0.37 not allowed because none of user's groups are listed in AllowGroups

J’ai l’impression que des groupes ont été perdus lors de la migration.

  • Pour le user migré qui échoue
    groups=1000(paul),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev)
  • Pour le nouveau user de test qui fonctionne
    groups=22152(bertrand),4002(all_users),5001(mail.main),4001(admins),38990(snappymail.main),…
  • les autres users sont corrects également

Sur cette machine l’image ISO ne fonctionne pas. Une histoire de boot UEFI si j’ai bien compris. J’ai donc installé une Debian classique et installé Yunohost par dessus. Il est possible (je ne me souviens plus) que j’ai créé ce user lors de l’installation Debian avant la restauration du backup Yunohost. Ce qui pourrait expliquer cette histoire de groupes. Par contre si j’essaie usermod -a -G admins paul je n’ai pas de message d’erreur mais le groupe n’est pas ajouté.

Il faut peut-être passer par le LDAP Yunohost ? Mais je ne sais pas comment faire. Si j’essaie yunohost user group add admins paul il est ajouté mais je ne le vois toujours pas dans le résultat de id paul.

Je soupçonne un petit soucis dans ces eaux-là. Peux-tu retirer paul du groupe administrateur, et le rajouter ? (équivalent d’un bon vieux “avez-vous redémarré?”)

Je pense que c’est normal que le groupe admins ne s’affiche pas, il provient de LDAP.


Edit: et peux tu vérifier que le Diagnostic ne se plaint pas de la configuration SSH?

J’avais exploré ces pistes mais ça ne donne rien. Je vais explorer d’autres pistes quand j’aurai un peu de temps.

Ah! ça pourrait être une explication. Essaie, dans cet ordre:

  1. Supprime-le de YunoHost (SANS purger ton dossier personnel ^^)
  2. Supprime l’utilisateur dans Debian: userdel paul
  3. Recrée-toi dans YunoHost et assigne-toi au groupe admins.

Edit: Le nouveau compte ne récupère pas les données de Nextcloud.

J’y pensais mais j’ai peur de perdre des données, notamment dans Nextcloud. Les quotas, la configuration des répertoires externes, les calendriers partagés avec d’autres utilisateurs etc. Si je ne supprime pas les données personnelles, ça conserve aussi ce genre de données ?

Correct, toutes mes excuses, je viens d’essayer et tes fichiers ne sont pas reconnectés au nouveau compte, et je crains pour les autres données. Je biffe mon message ci-dessus, mais du coup j’avoue ne pas savoir comment faire.

Il reste la solution de tout sauvegarder, supprimer le user dans Debian puis restaurer le système et les apps. C’est un peu bourrin.

Avec $ compgen -u je vois 2 fois Paul dans la liste. Il doit y avoir une instance Debian et une instance dans le LDAP. Reste à savoir comment supprimer l’instance Debian sans casser l’instance LDAP. Je testerai sur un user bidon.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.