Bonjour à tous,
Je vous soumet ce soucis que je constate depuis que j'installe (et
installons au boulot) des Debian Trixie, que ce soit en installation
neuve qu'en upgrade depuis une version de debian précédente.
J'ai d'abord cru à une mauvaise manipulation, mais c'est la 5ème ou 6ème
machine où je constate la même problématique. Quel que soit le niveau de
mise à jour.
En synthèse : lorsqu'une machine en Debian Trixie vient de redémarrer,
impossible de s'y connecter en SSH si on copie/colle le mot de passe.
Dans les détails :
Nous avons un utilisateur d'administration que nous nommerons
"useradmin" pour préserver son anonymat. Cet utilisateur fait partie du
groupe sudo.
Si sur cet utilisateur nous utilisons un mot de passe simple (8
caractères sans caractères spéciaux), aucun soucis pour s'y connecter en
ssh, monter root via sudo, effectuer les opérations, redémarrer la
machine, et recommencer un cycle.
Puis arrive la phase de sécurisation avant mise en production, ou nous
modifions le mot de passe de l'utilisateur d'administration pour à
minima du 12 caractères alphanumériques minuscule/majuscule + caractères
spéciaux (complexité minimale estimée pour reproduction du problème).
On utilise KeepassXC pour la génération de mot de passe, un coup de
"passwd" depuis le shell de "useradmin" et on colle le mot de passe généré.
Si on ouvre en parallèle une nouvelle connexion en SSH avec le nouveau
mot de passe (copié/collé), pas de soucis, on peut se connecter.
Tant que la machine est active, aucun soucis pour s'y connecter en SSH.
C'est au moment du reboot que le problème apparaît : en utilisant
strictement la même manipulation de connexion SSH et de copier/coller de
mot de passe => échec de connexion : le mot de passe n'est plus accepté.
Les logs d'authentification côté serveur indiquent simplement un échec
de mot de passe pour l'utilisateur "useradmin" sans plus de précision.
Là ou cela devient vicieux : c'est que si on tape le mot de passe
manuellement (sans copier/coller), le login fonctionne, et surtout,
toutes les connexions suivantes copier/coller ou non fonctionnent
également... Jusqu'au reboot suivant ! ou la première connexion
redevient problématique.
Donc le problème est ciblé :
* Sur la première connexion en SSH après redémarrage
* Sur trixie : neuve ou en upgrade : j'ai fait la semaine dernière la
migration d'une machine de buster à trixie, en passant par toutes les
releases intermédiaires , et je n'ai eu aucun soucis ni en bullseye, ni
en bookworm, mais c'est apparu en trixie.
Notes complémentaires (si cela peut avoir une importance) :
* Les postes de travail se connectant sur les serveurs sont
exclusivement des Ubuntu : Versions diverses, allant de la 18.04 LTS à
la 24.04 LTS, toutes ayant rencontré au moins une fois le problème.
* Les connexions ssh s'effectuent avec le client openssh disponible sur
la distribution du poste de travail (pas de client exotique)
* Le problème existe peu importe la source de la copie (KeepassXC ou
gedit ou même VS Code, même combat).
Est-ce que quelqu'un dans l'assistance s'est déjà retrouvé confronté à
un problème similaire ?
A bientôt.
Christophe.
