Bonjour Christophe, Je n’ai jamais eu ce problème mais il est vrai que j’ai banni la connexion SSH avec mot de passe sur mes machines. Tout se fait par échange de clé.
Sinon, ta mésaventure me fait penser plutôt à un problème avec ce qui est copié avant d’être collé. Du coup tu ne colle peut-être pas ce que tu crois à la saisie du mot de passe. C’est peut-être ça la différence entre Bullseye et Trixie ? > Le 16 févr. 2026 à 18:06, Christophe <[email protected]> a écrit : > > 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. > -- Pierre Malard https://plm4-photos.odexpo.com Clé OpenGPG : https://keys.openpgp.org |\ _,,,---,,_ /,`.-'`' -. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
