Ah pardon voilà,

May  8 23:15:23 postfix/smtpd[5380]: error: ConvertFullUserName: SYNOUserLoginNameConvert(holding) failed
May  8 23:15:25 postfix/smtpd[5380]: warning: unknown[212.91.92.30]: SASL LOGIN authentication failed: authentication failure
May  8 23:15:29 postfix/smtpd[5380]: error: ConvertFullUserName: SYNOUserLoginNameConvert(holding1) failed
May  8 23:15:31 postfix/smtpd[5380]: warning: unknown[212.91.92.30]: SASL LOGIN authentication failed: authentication failure
May  8 23:15:33 postfix/smtpd[5380]: error: ConvertFullUserName: SYNOUserLoginNameConvert(holding123) failed
May  8 23:15:35 postfix/smtpd[5380]: warning: unknown[212.91.92.30]: SASL LOGIN authentication failed: authentication failure

Ca se sont des messages postfix, tu devrais trouver des messages concernant ssh, ressemblant à "May 8 23:15:35 sshd[5380] <texte>"

J'ai pas, le seul message que j'ai date d'hier.

NAS> cat /var/log/messages | grep ssh
May  7 08:16:11 sshd[13018]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)

J'ai pas, le seul message que j'ai date d'hier.

NAS> cat /var/log/messages | grep ssh
May  7 08:16:11 sshd[13018]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)

Comprend pas comment ça peut être possible: pour chaque connexion ssh entrante le démon sshd produit au moins entrée dans une entrée dans la log.

Tu n'aurais pas modifié "loglevel" dans la config sshd (/etc/ssh/sshd_config) au moins?

Tu peux toujours le passer en "debug" pour voir:

• ajouter une ligne "Loglevel debug" à "/etc/ssh/sshd_config"
• forcer sshd à relire sa config (killall -HUP sshd)
• et recommencer

**EDIT**

Je ne t'ai pas posé la question, car j'imagine que si tu utilisais démon ssh d'optware à la place de celui de DSM tu l'aurait dis

N'est-ce pas?

Modifié le 8 mai 201312 a par CoolRaoul

Non même en mettant la ligne debbug, en killant etc j'ai rien.

J'avais pas modifié le fameux fichier...

Non même en mettant la ligne debbug, en killant etc j'ai rien.

J'avais pas modifié le fameux fichier...

Même sans rien ajouter, le kill -HUP envoyé au démon sshd doit forcément écrire dans syslog un truc de ce genre (testé à l'instant chez moi):

May  8 23:40:28 sshd[23970]: Received SIGHUP; restarting.
May  8 23:40:28 sshd[31144]: Server listening on :: port 22.
May  8 23:40:28 sshd[31144]: Server listening on 0.0.0.0 port 22.

Il y a vraiment un truc qui coince sur ta config, et là je n'ai plus la moindre piste

Modifié le 8 mai 201312 a par CoolRaoul

Je comprend pas non plus... Pourtant dans ma technique de base, qui était de générer une clef pour chaque compte root, de les mette toutes dans un fichier et de le mettre sur chaque serveur, ça fonctionnait pour root. Le souci vient du compte admin. Personne sur tout le forum n'a jamais essayer de faire ça ?

Bon je vais continuer de chercher en tout cas merci pour ta patiente

Modifié le 8 mai 201312 a par Lokomass

Le souci vient du compte admin.

Un truc qui pourrait expliquer ce que tu constate serait que tu n'utilise pas le ssh DSM mais un autre (comme celui d'optware) comme je l'ai envisagé.

Sous DSM le compte "admin" n'est pas tout a fait un compte comme les autres, il est traité de façon un peu spéciale (comme par exemple le fait qu'il ait automatiquement le même mot de passe que root) et le démon ssh DSM est patché pour gérer cela.

Apparemment, mauvaise piste la aussi: j'a testé une instance du sshd optware, tournant sur le port 999.

Et il sait bien accepter une connexion sur le compte admin en mode publickey et le tout étant loggé bien dans syslog comme on peut le constater:

May  9 00:19:37 sshd[18802]: Server listening on :: port 999.
May  9 00:19:37 sshd[18802]: Server listening on 0.0.0.0 port 999.
May  9 00:19:48 sshd[19512]: Accepted publickey for admin from 127.0.0.1 port 51661 ssh2

Donc le fait que ton syslog ne recoive rien (a l'excepion de l'unique message d'hier) du démon sshd (quel qu'il soit) est franchement louche