CoolRaoul

Ca me semble une bonne explication en effet, on va attendre sa réponse

Essaie comme ceci: su - admin -c'/usr/syno/pgsql/bin/psql -d video_metadata -q -A -t -c "UPDATE video_file SET path = $NEW_PATH WHERE id= $DB_ID;"'

Zut, on n'avait pas compris que le probleme était du coté de Synology Assistant. Mais si c'est le cas, c'est un logiciel autonome qui n'a absolument rien a voir avec le navigateur. Peux-tu nous dire exactement et précisément comment tu le lances (nom de l'icone ou du menu que tu actives) et ce qui se passe ensuite?

Comment est-on passé d'un sujet a l'autre?

Suffit de faire le test: après avoir désinstallé flash la connexion DSM marche toujours. Ne pas oublier aussi qu'ils a été demandé ceci par le support: Voila pourquoi je pense que mieux vaut commencer par l'aider à faire la manip comme ça lui a été demandé.

Qu'avez-vous tous avec Flash? Chez moi il n'est pas installé et je n'ai pas de problême pour me connecter à DSM. Le message "IE9 a rencontré un problème et doit fermer" a des chances d'être causé par un module complémentaire qui merdoie. Donc essayer avec une autre navigateur permettrait déja d'éliminer (ou pas) cette piste **edit** Note: cela dit la mise a jour vers IE10 n'est pas inutile non plus.

C''est le traffic *entrant* qui pose problème

Etrange, pour moi, sous Windows avec flash player non installé et le flash embarqué de chrome désactivé: aucun probleme pour me connecter à DSM et pas d'alerte non plus

Juste apres avoir posté, en réponse à , un message à propos de Google Chrome, je retourne sur la page d'index des forums et voici ce qui apparaît dans le bandeau de pub: Coïncidence ou bien faut imaginer que Google est aussi capable d'aller jusqu'à d'analyser le *contenu* des messages postés pour orienter la pub contextuelle? Note: pour éviter de me faire traiter de lourdaud ne sachant pas utiliser adblock, sachez qu'il est bien installé mais nas-forum.com figure dans ma liste banche, en solidarité et pour maintenir le financement du site

Etonnant qu'ils parlent de flash car filestation n'a pas besoin de flash. Mais on verra plus tard. Pour Chrome, tu l'installes à allant ici: https://www.google.com/intl/fr/chrome/ puis en cliquant sur ensuite il suffit de te laisser guider

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

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.

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

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?

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

Faudrait maintenant regarder ce qui a été loggé dans /var/log/messages sur la machine 192.168.100.160 au moment de cette tentative de connexion.

Si tu as vraiment suivi mon conseil *à la lettre* tu es bien d'accord que la situation doit être maintenant entièrement symétrique puisque sur les 6 comptes (root et admin des 3 serveurs) le contenu des fichiers authorized_keys est identique et que la clé privée que tu utilises est bien la même (tu spécifie bien le paramètre "-i <chemin_clé_privée>" pour la commande ssh?, essaie d'ajouter aussi "-oIdentitiesOnly=yes" ) Faudrait lancer la commande ssh en mode verbeux (ajouter "-v") et venir poster le résultat ici. Vérifier aussi, quand ça ne marche pas, le contenu du fichier /var/log/message du serveur *cible*. Ca pourrait donner des pistes. Et enfin, soit plus précis dans tes explications, quand tu écris "Je peux uniquement me connecter depuis le serveur sur lequel j'ai fait les clés" on ne comprend pas si tu peux te connecter *depuis* ce serveur ou *a partir de* ce serveur

Oups, bien vu! Voici le script corrigé: for nas in nas1 nas2 nas3 ; do for user in root admin ; do ssh $user@$nas "cat >> .ssh/authorized_keys" < /root/.ssh/id_rsa.pub done done Et bien entendu faut aussi déployer le id_rsa tel quel dans les .ssh de chaque compte sur chaque NAS.

Pour ma part j'ai trouvé une réelle utilité: il m'est arrivé de tomber sur le forum sur des demandes d'aide à propos d'opérations impossibles à reproduire sur mon propre NAS Syno sous peine de tout y effacer. Sur le NAS virtuel je peux reproduire la manip sans le moindre risque.

Dans ce cas grandes chances que le problème soit aussi coté box. Si tu parviens à une solution faudra la poster aussi sur le forum numericable, ça intéressera certainement ses utilisateurs n'ayant pas de NAS Syno et qui aurait par conséquent peu de chance de traîner par ici.

Si les sous-titres sont sous forme de fichiers externes (.srt par exemple), dans le cas d'un acces en mode DLNA je ne pense pas que ça puisse fonctionner.

Si j'ai bien compris te reste plus qu'a reconfigurer le plan d'addressage de ton réseau loal en 192.168.0.X, c'est ça?

Attention, dans la 2eme partie, tes commandes "scp" ont une syntaxe incorrecte: scp /var/service/homes/admin/.ssh/authorized_keys root@nas2 /root/.ssh/authorized_keys ne peut pas marcher, scp n'ayant qu'un seul argument Le plus propre est de procéder ainsi, cela ajoute le contenu de ~root/.ssh/id_rsa aux 6 authorized_keys : for nas in nas1 nas2 nas3 ; do for user in root admin ; do ssh $user@$nas "cat >> .ssh/authorized_keys" < /root/.ssh/id_rsa done done Pour compléter, je vais tenter de procéder par analogie te faire comprendre le mécanisme. On peut considérer le fichier ".ssh/authorized_keys" comme la "serrure" du compte auquel le fichier appartient. Mais, contrairement à une vraie serrure, ici il est possible d'accepter *plusieurs* clés différentes. La liste des clés autorisée est simplement déterminé par son contenu: pour toute clé publique qu'il contient (une clé par ligne), "présenter" la clé privée correspondante autorise la connexion. (je schématise un peu en disant "présenter" mais ça suffit pour avoir une idée) Lorsque tu te connectes sur un compte d'une machine distante (user@host) tu va donc "présenter" une ou plusieurs clés privées à la "serrure" via l'argument "-i" de la commande ssh. La premiere des clés présentées qui "matche" te donne accès. Donc, en copiant même clé privée sur *tous* les comptes root et admin de serveurs (ce qui je le répète n'est pas tip top niveau sécurité, mais je n'ai pas la patience de te proposer une solution plus complexe), et en copiant la clé publique correspondante dans *tous* les fichiers authorized_keys de ces memes comptes (en 6 exemplaires donc), tu pourra te connecter à partir de n'importe quel des 6 comptes vers chacun des autres, pour peu que ta commande ssh fasse reférence, via le switch "-i" au fichier contenant la clé privée. Chaque compte disposant d'une copie en propre de ce fichier. (le "-i <chemin fichier>" étant inutile si le fichier clé privée se nomme ~/.ssh/id_rsa qui fait partie des chemins essayés par défaut par la commande ssh)

Décidément, il y a une véritable épidémie de disques dur en panne ces jours ci sur le forum!

Pour faire ton test de connexion de l'extérieur es-tu bien à l'extérieur au moins? (un téléphone connecté en 3G fera l'affaire par exemple)