Ssh authentication failure correct password

[boistordu]

Mon serveur YunoHost

Matériel: olimex lime2
Version de YunoHost: 3.8.4.9
J’ai accès à mon serveur : Tout
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Description du problème

Quelqu’un sait-il si il y avait des incompatibilités entre la version de debian que yunohost utilise pour le moment et les librairies openssl ou autre de windows utilisées pour le SSH?
Quelque soit le poste client windows ou les programmes clients windows, ssh.exe de windows, putty, termius et autre, J’ai toujorus des authentication failure notée dans les logs auth.log et du coup fail2ban finit parfois par me bloquer mon accès en local ou en remote.
Je n’ai pas essayé avec une clé pour voir si ça fait le même effet mais je pense que le problème est limité à l’authentification en mot de passe.

Jun 21 09:09:38 dev sshd[20884]: Connection from 192.168.4.22 port 64151 on 192.168.80.50 port 22
Jun 21 09:09:38 dev sshd[20884]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.4.22  user=admin
Jun 21 09:09:38 dev sshd[20884]: Accepted password for admin from 192.168.4.22 port 64151 ssh2
Jun 21 09:09:38 dev sshd[20884]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Jun 21 09:09:38 dev systemd-logind[698]: New session 618 of user admin.
Jun 21 09:09:38 dev systemd: pam_unix(systemd-user:session): session opened for user admin by (uid=0)
Jun 21 09:09:39 dev sshd[20884]: User child is on pid 20903
Jun 21 09:09:39 dev sshd[20903]: Starting session: shell on pts/0 for admin from 192.168.4.22 port 64151 id 0

Comme vous pouvez le voir la session est acceptée mais j’ai quand même une authentication failure. Vu la multiplicités des software clients ce n’est pas dû à des tests de clés ou quoi que ce soit. L’exemple de termius le montre très bien.
Je suis tombé sur un rapport de bug de debian 6 je pense? qui parlait d’un problème similaire et qui était dû à la façon don’t ssh et pam interagissait. Mais ça aurait du être réglé depuis longtemps ce bug et certainement pas se reproduire sur debian buster.
Quelqu’un a une connaissance particulière de ce problème?
Merci d’avance

[Aleks]

L’explication la plus simple qui me vient à l’esprit, c’est que tu as une clef configurée dans ton client, et par défaut il essaye cette clef pour se connecter. Du coup ça génère une authentication failure. Puis il bascule sur l’authentification par mot de passe par défaut

[boistordu]

Comme je disais ce n’est pas possible.
Termius ne fonctionne pas comme ça et même pour le client ssh du terminal terminus même chose.
Tous ces clients ne font pas des choses de façons automatiques si ils ne sont pas configurés pour le faire.
Et c’est mon seul setup avec Debian server de cette version-la et c’est le seul à me faire ça. Il ne me fait ça ni sur centos ni sur Ubuntu ni sur fedora ni raspbian.
Et comme je l’ai montré dans le bug report ce genre de choses s’est déjà produit par la passé. Donc y a t il quelqu’un se connectant a partir de ces clients windows sur cette version de Debian de yunohost avec password only qui a l’effet inverse c’est-à-dire pas d ce message dans les logs ou le même effet ?

[boistordu]

Parce que si c’est le cas alors il faut que j’envoie un message sur la mailing list des maintainers ssh Debian pour leur demander suivant la version open ssh exacte qui est installé

Rectification: ce n’est pas seulement windows mais aussi les applis iPhone termius. Donc impossible d’après ce que je sais de leur code que ce soit l’usage d’une autre clé juste avant le mot de passe