loli71

C'est exactement cela Gaetan, ca colorise lorsque l'on compose le message, mais pas une fois posté, comme si le choix du type de langage ne voulait pas s'enregistrer

Chose bizarre chez moi avec "Insérer un extrait de code", c'est que la coloration choisie lors de la saisie du texte ne semble pas prise en compte (bash dans mon cas) et le texte reste sans aucune coloration

​Que veux tu dire exactement par "J'ai besoin des mêmes ports sur les deux serveurs" exactement ? - tu as besoin d'utiliser le port TCP 80. et TCP 443 sur les deux syno en local ? Dans ce cas, il te suffit d'utiliser des ports différents dans ta redirection sur ta box DS213 TCP 80 xxx.xxx.x.xx 80 DS213 TCP 443 xxx.xxx.x.xx 443 DS115J TCP 8080 yyy.yyy.yyy.yyy 80 DS115J TCP 8443 yyy.yyy.yyy.yyy 443 - tu as besoin d'utiliser le port TCP 80. et TCP 443 depuis internet pour accéder aux deux syno ? dans ce cas là, tu dos effectivement passer par l'utilisation d'un reverse proxy et de deux noms FQDN différents comme l'a indiqué Fenrir

Euh, j'ai l'impression qu'il y a une confusion entre ce que je disais (port externe 5022 redirigé vers le port interne 22 sur l'ip du NAS) et la notion de port de départ et port de fin que demande la box numericable. Pour moi fabbe, soit tu n'as pas choisi la bonne page dans ton interface de gestion de la box (tu as choisi la page de gestion de plage de ports), soit tout simplement la box numéricable ne permet pas de transformer un port externe (5022 dans mon exemple) vers un port interne (22 dans mon exemple) différent, la box ne permettrait que de forwarder le port 5022 externe vers le port 5022 interne vers ton NAS (et c'est ce qu'il me semble me souvenir !) Du coup, tu vas devoir faire avec et apporter une modification sur le NAS le NAS qui reçoit les attaques dans la partie "Sauvegarde et réplication > Services de Sauvegarde" et renseigner le port 5022 au lieu du 22 : Cela te permet d'utiliser en écoute sur ce syno le port ssh 5022 pour la sauvegarde, et ca tombe bien puisque c'est le port que tu as forwardé sur ta box ;-) EDIT: oups, je n'avais pas vu que tu avais édité ton dernier post, tu as trouvé la solution tout seul ;-)

​C'est effectivement la chose à faire, il faut changer le port externe sur ton routeur (utiliser un port au dessus de 5000, par exemple 5022) et le forwarder sur le port 22 de ton NAS (celui qui recçoit les attaques). Ensuite, sur l'autre NAS, faut que tu configures dans la partie "destination de sauvegardes" la partie "Personnaliser le port de cryptage SSH" :

​Surtout que le script permet de ne rien envoyé d'après la description dans l'entête : Il suffit donc de changer le "1" en "0" dans le script avant de le lancer.

Absolument pas, le port source du PC n'est pas le port lorsque tu accèdes à un site web, c'est le port destination (sur le serveur web). En plus, le routeur change souvent le port source qu'il utilise lui même pour envoyer ta requête au serveur Web ... Le port source est souvent aléatoire ... et le routeur n'accepte que le paquet de retour provenant de l'adresse IP du site web que tu as contacté sur le port source qu'il a lui même défini, car c'est avec la table de correspondance (table de Nat) "adresse ip destination/port destination/port source (du routeur)" que le routeur sait à quelle adresse ip du lan il doit finalement renvoyer la réponse.

oui c'est normal, en fait /var/services/homes est un lien symbolique vers le répertoire réel /volume1/homes (si tu as choisi le volume1 dans ta config du service d'accueil des utilisateurs) : lolinas3> ls -lsa /var/services/ 0 lrwxrwxrwx 1 root root 14 2015-03-12 23:30 homes -> /volume1/homes en fait, c'est le même emplacement réel, juste que tu as 2 chemins pour y accéder (un chemin réel et un chemin par lien symbolique)

Absolument pas !!! Si tu n'ouvres aucun port sur ta box (règles de NAT), alors rien ne rentre chez toi ! Je pense que Domlas se trompe sur ce point, seuls les flux initiés par un équipement à l’intérieur de ton réseau sont autorisés à revenir (pour accepter la réponse) si ta box est configuré en mode routeur sans aucune règle de NAT implémentée.

Il est possible de rendre les répertoires se trouvant dans /volume1/homes non accessible pour les personnes sans autorisations et le rendre non visible depuis "mes emplacements réseaux windows" : Il faut donc ensuite que tu modifies les droits du dossier /volume1/homes/aizen pour être le seul à y accéder (gestion des permissions par Files station sur ton répertoire).

c'est exactement cela, NAS accessible uniquement depuis ton réseau local (LAN et Wifi de ta box) quelques soient (ou presque) les services lancés sur le NAS si tu n'as rien configuré comme NAT sur ta box. Je dis presque, car le seul service du NAS qui permettrait d'y accéder depuis internet sans toucher à la conf de ta box, c'est le service "QuickConnect" justement fait pour cela.

oui, et le dossier racine "/" est un dossier qui peut être écrasé à chaque upgrade DSM, c'est un dossier système. Donc tu fais comme tu le souhaites, je pense que tu as maintenant toutes les infos qu'il te faut.

Au moins, tu utilises un fonctionnement standard de Linux, ce qui t'évitera beaucoup de désagréments dans le futur ;-) Lorsque tu te connectes en ssh avec ton compte aizen + mot de passe, tu devrais maintenant arriver directement dans /volume1/homes/aizen/ non ?Si tu passes la command "pwd", ca te dit quoi ? Si c'est bien le cas, il ne te reste plus qu'à créer le répertoire ".ssh" et mettre ta clé

ben c'est mieux oui, et de préférence un endroit qui ne sera pas écrasé lors d'un upgrade de DSM .. donc dans /volume1 (ou /volume2 ..). Sinon tu risque de perdre la config de ta clé publique et autre ... Mais bon, fait comme tu le souhaites, le tout est que le répertoire ".ssh" se trouve dans le homedirectory défini dans le fichier /etc/passwd sinon sshd ne sera pas où cherche le fichier authorized_keys qui contient toutes les clé publiques que tu auras défini pour le compte.

Ah ben il faut soit le cocher, soit te connecter en tant que root ... ou alors tout faire manuellement si on part du principe que le nom d'utilisateur (username) que tu utilises pour te connecter en ssh est "aizen": 1) créer un répertoire où tu souhaites avoir ton homedirectory: mkidr -p /volume1/homes/aizen 2) donner les droits/propiétés corrects à ce répertoire : chown <username>:users /volume1/homes/aizen chmod 700 <username>:users /volume1/homes/aizen 3) modifier par vi le fichier /etc/passwd et la ligne correspondant à ton compte pour mettre le homedirectory correct : aizen:x:<id utilisateur>:100::/volume1/homes/aizen:/bin/ash Reconnexion en ssh puis ce que je t'ai indiqué avant ... mais ce n'est pas ce qu'il y a de plus standard ... et tu risque de rencontrer des problèmes si un jour tu actives le service accueil de l'utilisateur

Il faut savoir qu'avant le DSM5.0, les dossier partagées utilisaient par défaut les droits unix (d'où ton choix des mode R W X). Depuis le DSM 5.0, toute création de dossier partagé utilise par défaut (et même plus je dirais parce que l'on n'a plus le choix) les droits de type Windows ACL(d'où l'éditeur de permission). D'où ma question sur le type de mise à jour que tu as fait sur ton syno. Si ton dossier partagé a été créé sous un DSM antérieur à 5.0, alors il a des droits Unix, mais tu as la possibilité de les convertir en Windows ACL comme sur le DS115 à condition que les disques aient été installé en "ext4"

Déjà le dossier que l'on appelle "homedirectory" est celui où tu arrives lorsque tu te connectes avec ton user, et c'est dans ce dossier que tu dois créer le répertoire ".ssh" donc connectes toi avec putty et le compte que tu souhaites utiliser et passe les commandes suivantes : mkdir ~/.ssh cat ~/id_rsa.pub >> ~/.ssh/authorized_keys" chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys Où le fichier "id_rsa.pub" contient ta clé publique, ou alors si tu connais la commande vi, utilise "vi ~/.ssh/authorized_keys" et insère ta clé publique. le signe "~/" devant permet de dire à linux que tu parles du homedirectory de l'utilisateur avec lequel tu es connecté.

salut coyote, Pourrais être plus précis sur cette mise à jour récente du NAS stp ? upgrade mineur (style service Update 3 vers Update 4) ou majeur (DSM4.2 vers DSM5.1) ?

nop, si tu veux utiliser putty, il vaut mieux faire la clé avec puttygen .. sinon c'est la galère pour transformé la clé privée faite sous linux en format lisible par putty et pageant ;-)

DSA est plus sécurisé que RSA. Puttygen est effectivement ce qu'il te faut pour générer sur un windows une clé public/privée

Euh .. c'est surtout que la clé privée est censé être sur le PC et la clé publique sur le NAS (pour les connexions ssh sur le NAS). Donc en cas de perte de la clé privée sur ton PC, tu pourras toujours te connecter avec le mot de passe du compte et remettre une nouvelle clé publique sur ton NAS. Au pire, si tu interdisais dans la conf sshd la connexion par mot de passe, uniquement par clé, tu pourras toujours activer temporairement le telnet sur ton nas par le DSM, arrêter le ssh et changer la conf sshd par connexion telnet, et relancer le ssh par le DSM.

Salut Emmanuel, Clairement oui, ton synology semble déjà installé et configuré avec un compte administrateur ou utilisateur. Que vois tu comme version dans l'assistant Synolgoy pour ton NAS ? Le disque que tu as mis dans le NAS était-il aussi fourni par MacWay en même temps que le NAS ou as-tu réutilisé un disque à toi ? Pour ma part, je partirais sur un reset usine avec réinstallation de 0 de tout l'ensemble si le disque vient de chez MacWay .... pour cela, format ton disque en le connectant sur un PC ...

Non, pas de DoS activé sur ce syno, étant donné qu'il n'est pas accessible directement depuis internet.. je passe par un serveur de rebond ssh et port forwarding pour accéder chez moi ;-)

Tu as toujours la possibilité d'ajouter manuellement dans la partie "blocage Auto" une liste d'adresses IP toujours autorisées à se connecter, ajoute y les adreses ip principales de ton LAN pour éviter un futur blocage ;-)

Ok, donc TNT via la box (donc problème de réception qui pourrait être lié à un problème de débit internet), mais tu dis que le problème reste présent même lorsque tu débranches le câble réseau du NAS (NAS allumé) si j'ai bien compris ? Et tu n'as plus aucun problème de réception TNT lorsque tu éteins le électriquement le NAS ? Honnêtement, je n'ai jamais entendu parlé d'un NAS qui entraine des perturbations électromagnétiques :-(