loli71

C'est l'une des nombreuses raisons qui m'ont fait fuir Orange .....

Dans ce cas, il faut configuré ton routeur comme suit : - affecter une ip fixe à ton routeur en 192.168.1.X/24 en dehors de la plage DHCP utilisée par ta livebox - désactiver le DHCP sur ton routeur - connecter ton routeur à ta box avec l'un des port LAN (pas le port WAN) - utiliser les autres ports LAN pour connecter tes autres équipements. De cette façon là, tu utilises uniquement la partie switch de ton routeur et c'est bien ta livebox qui porte tous les services (DHCP, Wifi, NAT, etc...). Après il existe des petits swichs giga pas cher et très bien ;-)

Bon, si on met de côté ce problème d'adressage IP, je suppose que lorsque tu parles de changement de Box puis de livebox, c'est que tu viens de passer chez Orange et qu'avant tu étais chez un autre opérateur non ? J'ai connu le même problème que toi lors de mon court passage chez Orange, leur box est plus que capricieuse, et selon les réglages de firewall sur la box, les choses ne marchent pas, de plus il est impératif pour t'éviter tout problème dû à la livebox que l'ip de ton synology soit fourni par le DHCP de la livebox (avec réservation d'ip pour avoir tout de même ne pseudo IP fixe affecté à ton syno)

Il n'y aurait pas un petit problème dans ton montage ? Ton NAS est d'après toi situé derrière un routeur mais dans le meme plan d'adressage que ta box et non pas dans le plan d'adressage de ton routeur .. j'ai du mal à comprendre l'intêret d'un routeur au milieu dans ce cas là .. ou alors il s'agit d'une erreur de frappe ?

Plusieurs pistes à voir : - Sur DSM6, plus d'accès ssh avec le compte root+mot de passe (uniquement ssh avec le compte root+clé SSH), il faut donc utiliser un compte se trouvant dans le groupe admin si tu souhaites utiliser ssh avec mot de passe. - Sur DSM6, l'utilisation d'un compte du groupe admin pour se connecter en ssh avec une clé peut ne pas fonctionner, lire tout le post suivant si besoin:

Ne serais-tu pas en DSM6 par hasard ? Dans ce cas là, fait une petite recherche sur ce forum concernan tConnexion SSH impossible dsm 6.0

tu peux créer un fichier vide avant avec la commande : sudo touch my.cnf

La commande fournie dans le post va créer le fichier s'il n'existe pas ou éditer le fichier s'il existe déjà:

Ben si, il y a bien une release note au bout de ton lien;-)

ca dépend peut être de la config de la box derrière la quelle tu te trouves en dehors de chez toi ... il peut y avoir des règles de sécurité qui interdisent la sortie sur internet du protocole de montage réseau.

gaetan, J'ai trouvé cela sur le web : A vérifier sur les SDM6 finaux, moi je suis resté en 5.2 lol EDIT : Sinon j'ai jeté un coup d'oeil au contenu du paquet "Advanced Power Manager for Synology DS" qui est en perl et qui semble avoir été mis à jours pour fonctionner sur DSM6 ... on y trouve effectivement quelques indications quant à l'utilisation de "/usr/syno/synoman/webman/modules/authenticate.cgi" qui semble faire référence à SynoToken .... Paquet téléchargeable ici pour voir le contenu: http://downloads.sourceforge.net/project/advpowermgr4ds/release-3/advpowermgr-3.4-5.spk?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fadvpowermgr4ds%2Ffiles%2Frelease-3%2F&ts=1459697670&use_mirror=iweb je mets ici le bout de code en perl utilisé pour vérifier les privilèges dans cette application: #!/usr/bin/perl use JSON qw( to_json from_json ); my $VERSION_FILE = "/etc.defaults/VERSION"; my $LOGIN_CGI = "/usr/syno/synoman/webman/login.cgi"; my $AUTH_CGI = "/usr/syno/synoman/webman/modules/authenticate.cgi"; # initdata: Pre DSM6.0 (Build 7307) my $INITDATA_CGI = "/usr/syno/synoman/webman/initdata.cgi"; # synowebapi: DSM6.0 (Build 7307) my $SYNOWEBAPI = "/usr/syno/bin/synowebapi"; my $version; sub version { unless(defined($version)) { if (open(my $fh, "$VERSION_FILE")) { while (<$fh>) { next unless m#^buildnumber="(\d+)"$#; $version = $1; last; } close($fh); } else { warning("No '%s' file found", $VERSION_FILE); $version = -1; } info("DSM version is %d", $version); } return $version; } sub check_privilege { my $class = shift; my $appname = "SYNO.SDS._ThirdParty.App.AdvancedPowerManager"; open(my $fh, '-|', $LOGIN_CGI) or die_exec($LOGIN_CGI); my @out = (<$fh>); chomp(@out); close($fh); # Skip HTTP header my $raw_data = join('', @out); $raw_data = substr($raw_data, index($raw_data, "{") - 1); my $ret = from_json($raw_data); my $token = $ret->{SynoToken}; if (defined($token)) { $ENV{"QUERY_STRING"} = "SynoToken=$token"; $ENV{"X-SYNO-TOKEN"} = "$token"; } open($fh, "$AUTH_CGI |") or die_exec($AUTH_CGI); my $user = <$fh>; chomp($user); close($fh); return ('', '', 0) if $user eq ""; my ($appprivilege, $is_admin); if (version() >= 7307) { # DSM 6.0 open($fh, "$SYNOWEBAPI --exec api=SYNO.Core.Desktop.Initdata method=get version=1 runner=$user |") or die_exec($SYNOWEBAPI); @out = (<$fh>); close($fh); $raw_data = join('', @out); $ret = from_json($raw_data); $appprivilege = defined($ret->{'data'}->{'AppPrivilege'}->{$appname}) ? 1 : 0; $is_admin = defined($ret->{'data'}->{'Session'}->{'is_admin'} && $ret->{'data'}->{'Session'}->{'is_admin'} eq JSON->true()) ? 1 : 0; } else { open($fh, "$INITDATA_CGI |") or die_exec($INITDATA_CGI); @out = (<$fh>); close($fh); $raw_data = join('', @out); $raw_data = substr($raw_data, index($raw_data, "{") - 1); $ret = from_json($raw_data); $appprivilege = defined($ret->{'AppPrivilege'}->{$appname}) ? 1 : 0; $is_admin = $ret->{Session}->{is_admin} eq JSON->true(); } return ('', '', 0) unless ($appprivilege || $user eq "admin"); return ($token, $user, $is_admin); }

Cà, c'est ce qu'on appelle payer de son corps :-)

on est bien d'accord CoolRaoul

Tu dois être obligé de passer par la page du DSM et te déconnecter non ?

Ben si, iPhilGood a donné la solution 2 posts plus haut: Appropriate PHP CLI --> /usr/local/bin/php56

il a dû juste lire ce que j'ai écris plus haut ..... mise en place de clé SSH pour le compte root, ce qui permet de se connecter avec putty ET winscp ...

http://www.generation-nt.com/automatiser-connexions-ssh-avec-putty-article-24811-1.html

Quelques petites recherches sur google t'auraient données le résultat suivant par exemple: http://www.generation-nt.com/automatiser-connexions-ssh-avec-putty-article-24811-1.html http://blog.oceanet-technology.com/vision-expert/authentification-ssh-par-paire-de-cles-priveepublique/ Mais si tu es à ce point newbie au point de ne pas savoir enregistrer la clé ssh sur le syno (et ce n'est pas un reproche ou un jugement quelconque), je ne suis pas certain que l'utilisation de SSH soit un solution SANS risque pour toi ;-)

As-tu comparé les permissions des répertoires ~/.ssh et des fichiers ~/.ssh/authorized_keys entre tes deux synos ? L'une des premières causes d'erreur d'authentification par clé ssh vient des permissions trop grande sur le répertoire ou le fichier. Le répertoire doit être en 700 et le fichier en 600

Il faut utiliser les paquets de gaetan qui sont beaucoup plus à jours, en attendant que synocommunity veuille bien bien intégrer les Pull Requests de Gaetan. https://www.cambier.org/2016/01/29/depot-de-packages-synology/#more-4884

Il doit te suffire de le rajouter à nouveau dans l'interface SDM non ?

Pour Winscp, c'est plutôt là qu'il faut regarder : A voir si la page d'aide WinSCP sur le sudo peut t'aider: https://winscp.net/eng/docs/faq_su

Je suis d'accord avec cela, mais quand on voit l'évolution du proxy squid fourni par synology ... ben j'ai peur que le premier jet reste identique pour la suite c'est tout ;-)

C'est surtout une modification d'accès du compte root décrite dans la release note du DSM6 https://www.synology.com/fr-fr/releaseNote/DS214play Mais il semblerait que l'accès en root soit toujours possible en utilisant uniquement une clé ssh

J'ai comme l'impression qu'ils ont encore fait uniquement le minimum syndical dans leur ReverseProxy, c'est fou quand même...