CoolRaoul

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)

Tout semble indiquer que ton disque est défectueux, ce sont des choses qui arrivent (la période critique pour un disque est dans ses premières semaines, c'est là que le taux de panne est le plus important). Donc, pour en avoir le coeur net tu peux essayer de le monter sur un PC mais le diagnostic est quasi certain. Par conséquent: retour SAV du disque. (et stp, évites d'écrire en caractères gras)

Sans le moindre doute

Tu veux pouvoir te connecter de n'importe lequel des 3 NAS vers n'importe lequel avec toutes les combinaisons de comptes admin et root? Es-tu *sur* d'avoir besoin de la matrice compléte de connexions : (NAS1, NAS2, NAS2) x (root,admin) -> (NAS1, NAS2, NAS2) X (root,admin) ? Si oui, tu vas avoir besoin de 6 clés privées root@NAS<i> et admin@NAS<i> pour i = 1..3! Quel interêt de generer 2 clés (une dsa et une rsa) par compte? Comprend pas en quoi consiste ce "fichier unique de clé". Pour chaque clé privée générée ssh-keygen t'a generé simultanément une clé publique associée (qui peut être regenérée si necessaire). C'est cette clé publique qui doit figurer dans le authorized_keys du compte du NAS cible C'est franchement compliqué ton truc, déja tu t'emm*** à utiliser root *et* admin, je ne comprend pas bien pourquoi. Focalise toi sur la connexion qui ne marche pas et pose toi les deux question suivantes: quelle est la clé privée utilisée dans ce cas (pour ne pas dépendre des défaut, utilise le switch "-i" de la commande ssh) est-ce que la clé publique correspondant à cette clé privée figure bien dans le authorized keys du répertoire .ssh du compte cible TIP: l'utilisation du switch "-v" de la commande ssh pourrait te donner des pistes sur ce qui coince. Et si tu ne parviens pas a désembrouiller tout ça, il y a beaucoup plus simple: rien ne t'empêche d'utiliser la *même* clé pour tous les comptes, c'est pas dans les "best practices" niveau sécurité, mais ça simplifiera d'un facteur considérable tes problèmes. Pour cela: tu génère une seule clé sans passphrase (de type rsa par exemple) sur le compte root d'un des NAS Ca va te donner un fichier id_rsa et un id_rsa.pub tu copie le id_rsa dans les 5 autres répertoires .ssh tu ajoute le contenu du id_rsa.pub aux chacun des authorized_keys des 6 comptes (admin et root sur les 3 NAS)

Ca risque d'être assez long Il va falloir commencer par faire des redirection de port (celui que j'ai indiqué dans un message précédent) dans la box du site où se trouve le NAS. La méthode à employer dépend de quel modèle il s'agit. Si c'est une FreeBox V5 je saurais t'aider, sinon va falloir attendre d'autres membres du forum. Pour l'activation du serveur VPN sur le NAS c'est plus dans mes cordes. Tu n'active que le mode PPTP, en reproduisant la configuration ci dessous: Ensuite faudra aller dans "privilège" et choisir le(s) compte(s) utilisateur autorisés en mode connexion VPN entrante. Ensuite faudra activer le client VPN coté windows, mais la on sort du périmètre Synology (quoique ça fait un moment qu'on déborde...). Si tu ne connais pas ce coté la non plus, daudra envisager d'aller chercer aussi de l'aide sur des forums windows Il va falloir aussi configurer le service DDNS. Toujours sur le NAS, panneau de configuration -> DDNS -> "ajouter" et tu te laisse guider (en choisiant synology comme fournisseur de service) Voila pour commencer, mais je t'engage à prendre le temps de lire la doc de ton NAS. (Faut comprendre qu'on est la pour aider les utilisateurs qui ont des problèmes, mais assurer une formation complète à partir de zéro c'est une autre paire de manches).

J'ai l'impression que tu ne maitrises pas tout. Déja tu parles de 3 serveurs, mais j'ai du mal a comprendre dans quels sens se font les connexions SSH. Si tu les nommait A, B et C pour l'exemple et énumérait les différentes connexions dont tu as besoin (pas plus de 2 j'imagine) ça serait plus clair, comme cela par exemple root@A -> admin@B : OK root@A -> admin@C : OK root@A -> root@C : echec etc .. Ou à tu mis tes deux clés privées? Est-ce que les clés publiques correspondantes sont biens dans *chacun* des authorized_keys cibles? Est-tu sur que la commande ssh utilise bien la bonne clé privée? Lorsque tu fais une connexion ssh d'une machine A vers le compte U de la machine B, tu va devoir indiquer à ton client ssh quelle clé privée utiliser (on va partir de l'hypothese que tu n'utilise pas d'agent pour ne pas compliquer) Par défaut il va chercher les clés privés ~/.ssh/id_dsa et ~/.ssh/id_rsa si elles sont la. Mais tu peux en ligne de commande lui indiquer d'autres clés privée à essayer (sous la forme "-i <chemin fichier clé>", option pouvant être répétée). Il est même possible d'indiquer les clés privées à utiliser dans le fichier ~/.ssh/config: Host * IdentityFile <chemin1> IdentityFile <chemin2> Si tu veux dédier une clé pour chaque host cible, tu peux mettre plusieurs sections "Host" avec le nom de host à la place de "*" (le test est fait avec le nom de host utilisé en paramètre de la commande ssh, en utilisant des alias tu peux avoir des config différentes). Bref, plein de possibilités. Pour que la connexion soit acceptée il est faut qu'au moins une des clé publiques correspondant à une des clés privées spécifiés soit présente sur la machine B dans ~U/.ssh/authorized_keys. Vérifie bien tout ça dans le cas du couple <user>X<server> -> <user2>X<server2> qui ne marche pas. le prefixe ssh-rsa ou ssh-dss indique le type de clé (rsa ou dss respectivement), le nombre de bits permet de régler la force du cryptage, mais, à part ça, ça ne change rien fonctionnellement

La partie qui suit les "=" de padding est du commentaire, donc ton problème est ailleurs. Vérifier que les droits du fichier authorized_keys et du répertoire .ssh soient assez "serrés" (en fait par défaut le démon ssh refuse de prendre en compte authorized_keys si ce dernier et *tout répertoire intermédiaire* qui y mène est modifiable un autre utilisateur que "root" ou le compte cible). Dans ce cas L'erreur est loggée dans /var/log/messages; comme cela: May 6 15:16:23 sshd[26590]: Authentication refused: bad ownership or modes for file /volume1/homes/admin/.ssh/authorized_keys

Une fois les logiciels installés sur les deux PC, s'assurer que tout les logiciels de compta fonctionnent en multiposte avec les deux PC connectés sur le même réseau local (et pour ça ne pas compter sur mon aide: EBP je ne connais absolument pas) et ce n'est qu'après qu'il faudra valider l'acces VPN En attendant tu peux déjà t'atteler à faire fonctionner le VPN, avec ton PC portable en mode client et le NAS en serveur. Différentes choses a faire pour cela: faire les redirections de ports dans le routeur ou la box adsl (et particulièrement 1723 pour le VPN en mode PPTP, je te conseille ce mode si tu à un PC Windows, c'est natif) Configurer DDNS sur le Syno (choisir Synology comme fournisseur de service). Ca n'est normalement obligatoire que si tu n'a pas d'IP fixe, mais dans tous les cas ça sera plus confortable de pouvoir utiliser un nom qu'une IP pour ta connexion externe. Valider la connexion VPN -> syno a partir du PC portable (à faire PC connecté sur un *autre* réseau Ces sujets ont été déjà abordés des dizaines de fois sur le forum, utiliser la recherche pour avoir de l'aide.

Normalement onduleur (sur lequel il sera possible de de brancher aussi le NAS), mais si c'est un portable il doit savoir continuer sur sa batterie. Dans tout les cas ne pas faire d'investissement avant d'avoir validé de bout en bout le bon fonctionnement de la solution

Oups, j'ai merdé. Je voulais dire "ne pas mettre le poste hors tension" bien entendu (je vais corriger)

C'est plutôt une "non manip" en fait: ne pas mettre le poste soushors tension désactiver la veille Puisque c'est un portable, s'assurer que l'évacuation de l'air chaud ne soit pas obstruée (ne pas le laisser poser sur un support mou par exemple)

Le truc important est qu'il devra rester sous tension avec la partie serveur du logiciel de compta activée pour pouvoir travailler à distance, ça peut être une contrainte.