Amsonia

Bonjour, Quand on a un souci sur notre gentille machine, on doit souvent mettre la main sur certains fichiers du NAS qui ne sont pas forcément aisément accessibles autrement que par la ligne de commande. La première chose à faire est alors à comprendre comment accéder à cette fameuse interface et cela est dépendant de notre système d'exploitation. Il existe désormais plusieurs solutions qui permettent d'avoir cette interface simplement depuis le bureau du DSM. Voici : 1/ Ouvrir le "Centre de paquets" 2/ Suivre ces étapes pour arriver à l'écran d'ajout d'une source Vous devez cliquer sur le bouton "Paramètres" pour qu'une autre fenêtre s'ouvre avec le bouton "Centre de paquets", etc. On arrive donc à l'écran d'ajout d'une source. Plusieurs sources sont disponibles (voir pour une liste complète), celui qui nous intéresse a pour adresse http://packages.missilehugger.com/ 3/ Installer le paquet "Web Console" Une fois votre source ajoutée, vous devriez avoir un nouvel onglet dans le Centre de Paquets : "Autres sources" et, dans ce nouvel écran, vous devriez voir un paquet nommé "Web Console" : installez-le ! 4/ Lancement du paquet et connexion Votre paquet doit maintenant être présent dans le menu démarrer de votre nas, lancez-le. Vous arrivez sur l'écran d'identification de Web Console. login : admin password : admin 4.1/ [iMPORTANT] Modifier le mot de passe admin Comme on vient de le voir, les identifiants par défaut sont triviaux, il faut absolument modifier le mot de passe de ce compte admin tout de suite. Pas d'inquiétude, ce n'est à faire que la première fois. Il faut modifier le mot de passe car la Web Console est directement accessible depuis le web via cette adresse : https://nom.de.domai...bconsole/wc.cgi Avec les identifiants par défaut, quiconque arrivant sur la Web Console pourrait se connecter et faire joujou... Pour changer le mot de passe, il vous suffit de taper la commande suivante : #users modify admin Et vous arriverez sur cet écran : Modifiez votre mot de passe par ce que vous voulez, renseignez également une adresse e-mail et sauvegardez. La Web Console vous confirme que le mot de passe a bien été mis à jour : Fermez maintenant la fenêtre de Web Console. 5/ Fin Relancez le paquet Web Console depuis le menu démarrer et renseignez vos identifiants : login : admin password : celui-que-vous-venez-de-choisir Web Console est plutôt capable, l'écran d'accueil vous donne quelques indications sur son utilisation. L'une des fonctions particulièrement utile est le file manager, vous y accédez en tapant : #manager[/code] Pour clore votre session et quitter Web Console, tapez simplement la commande suivante puis fermez la fenêtre de Web Console. [CODE]#close[/code] [size=4][b]Paquets similaires[/b][/size] Si, Web Console a l'avantage d'être indépendant de la plateforme (type de CPU) de son NAS, il existe d'autres paquets fournissant les mêmes services : - ShellinABox ; http://packages.missilehugger.com/ - GateOne ; http://packages.synocommunity.com (bientôt) [i]Si, après avoir ajouté la source valide, vous ne voyez pas le paquet dans la liste, c'est que votre NAS n'est pas compatible.[/i]

C'est comme un moteur thermique de voiture : le moment où il s'use le plus est lors du démarrage, quand l'huile n'est pas chaude, que le moteur n'est pas parfaitement lubrifié. Ton moteur s'usera donc moins à faire 500 km (sauf à faire une course de côte ) que le redémarrer toutes les heures pendant une journée. Je n'ai pas fait le calcul sur un an (certains ont du s'amuser à le faire) mais ça ne doit pas chercher bien loin. En tout cas, je préfère payer 10€ (nombre au hasard) de plus par an sur 4 ans plutôt que d'avoir à sortir 4x100€ (j'ai 4 disques, valeur basse d'un disque) tous les deux ans pour changer mes disques :-D En désactivant l'hibernation, je compte tenir 3 à 4 ans. Ensuite je change les disques (et en profite pour renouveler le NAS Es-tu certain que ton PhotoStation, qui est un service web, n'est pas accessible depuis l'extérieur ? Peut-être que ce sont des requêtes web "normales" (provenant d'un browser web classique) qui font sortir ton nas de son sommeil. Autre possibilité, le QuickConnect ainsi que le service DDNS de Synology : j'ai cru comprendre que Synology vérifiait régulièrement si le NAS avait une bonne connectivité sur ces services. Peut-être que Synology envoyant une requête, cela réveille le Nas ! La sortie de l'hibernation doit laisser des traces quelque part, commençons par le fichier de log le plus classique : /var/log/messages Pour ce faire, active le telnet dans le DSM (onglet Terminal) et connectes-toi à ton de cette façon en utilisant l'interface en ligne de commande (menu démarrer > exécuter > cmd) : telnet ip.du.nas ça te demande ton login, tu mets admin ça te demande ton mot de passe, tu mets ton mot de passe du compte admin et c'est normal si tu ne vois pas ce que tu tapes ensuite tu tapes la commande suivante : cat ../../../var/log/messages Et tu nous dis ce que tu vois aux horaires où le nas se réveille sans raison apparente. Si cette procédure te semble trop complexe, attends quelques minutes/heures, je vais poster un tutorial…

tu lis dans mes pensées c'est pas possible ^^ je cherchais justement comme faire taire le daemon : QUIET donc, logique o/ Quoique…ça peut être sympa d'avoir des logs plus détaillés pour comprendre tout ce qui se passe. Je vais voir ce qu'il faut que je fasse pour avoir un LogLevel INFO ou DEBUG sur l'ensemble des services du NAS. edit : il suffisait de faire ce que j'avais fait tout à l'heure : éditer le fichier /etc/syslog.deny et commenter la ligne info ou debug selon ce que l'on veut. # These priorities in this config file are not logged # refer to syslog.h #alert #crit debug #emerg #err info notice # Always keep these setting , as these are obselete # refer to syslog.h error none warn panic Et ensuite, redémarrer le daemon syslog killall syslogd && /sbin/syslogd[/code]

Oui, merci encore, j'arrive bien à me connecter en admin ou root, en ssh seul ou sftp. Il reste ce truc de setlogin qui, à tout le moins, bouffe du log et ce processus étrange -pour moi- de connexion : d'abord ça fail puis success :-s Sep 12 13:35:07 Asimov auth.info sshd[4081]: Failed none for root from 127.0.0.1 port 53093 ssh2 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Postponed publickey for root from 127.0.0.1 port 53093 ssh2 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Accepted publickey for root from 127.0.0.1 port 53093 ssh2

C'est ce que j'ai fait au début tu penses bien ! Mais ça me donnait ça : NAS> ssh -i~/ssh/test root@localhost -p 49442 Warning: Identity file ~/ssh/test not accessible: No such file or directory. Permission denied (publickey). Désolé de revenir en arrière mais je ne vois pas en quoi cela nous aide que de savoir que l'on peut initier une connexion du nas sur lui-même edit : en fait ça fonctionne en faisant ça : ssh -i ~/.ssh/test root@localhost -p 49442 (il manquait un espace après le -i et le point devant ssh) edit 2 : et voici le log de ladite connexion (même processus que lorsque je me connecte depuis le lan) : Sep 12 13:35:06 Asimov auth.info sshd[4081]: Set /proc/self/oom_adj to 0 Sep 12 13:35:06 Asimov auth.info sshd[4081]: Connection from 127.0.0.1 port 53093 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Failed none for root from 127.0.0.1 port 53093 ssh2 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Postponed publickey for root from 127.0.0.1 port 53093 ssh2 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Found matching RSA key: 6b:b7:2e:19:89:cc:9b:ab:6f:f0:c4:0c:fb:56:83:20 Sep 12 13:35:07 Asimov auth.info sshd[4081]: Accepted publickey for root from 127.0.0.1 port 53093 ssh2 Sep 12 13:35:07 Asimov auth.err sshd[4106]: error: setlogin failed: Function not implemented

Voici très simplement des paramètres de configuration qui fonctionnent pour moi. Elle est censée aussi fonctionner pour vous mais il est possible que d'autres configurations fonctionnent. DSM 4.1 - v2636 Connexion internet Orange Protocoles : SMTP et IMAP Serveur mail Dans le champs 'compte' en bas (authentification sur les serveurs d'Orange), ne mettre que votre nom d'utilisateur. Si votre adresse est "trucmuche@orange.fr", ne mettre que "trucmuche". (sans les guillemets bien sûr) Configuration admin de Roundcube Configuration user de Roundcbube Le nom d'utilisateur et mot de passe sont ceux de votre compte 'admin' sur le NAS. Ouvrir (et mapper si nécessaire) les ports 993, 587 et 25 vers votre syno. De cette manière, et si j'ai bien tout compris : - tous les clients qu'ils soient locaux comme roundcube ou distants comme votre client mail de téléphone portable ou votre client mail d'ordi quand vous utilisez une autre connexion que celle où est branché le syno, se connecteront de manière sécurisée au nas - le nas fera ensuite la différence entre un envoi de mail local et distant : si local alors le mail ne passe pas par internet et donc les serveurs d'orange Si vous avez des soucis avec cette config, ne pas hésiter à : - désinstaller puis réinstaller Mail Station (roundcube) - désinstaller puis réinstaller Mail Server Si vous avez plusieurs noms de domaine, il vous suffit de les ajouter en cliquant sur "domaines complémentaires" dans la config du serveur de mails. Il faut également modifier la zone DNS de vos domaines de façon à ce que les enregistrements MX pointent sur votre NAS. Appel à tous les experts du domaine : n'hésitez pas à critiquer (de manière constructive si vous voyez un point manquant et/ou une config plus sécurisée.

Ça fonctionne ! Connexion en ssh root depuis mon laptop puis ssh root localhost. Par contre je n'arrivais pas à trouver la clef au départ, parce que c'est /root/.ssh/test et pas /root/ssh/test. J'ai essayé de rajouter le point qqpart dans ta commande mais je suis apparemment trop mauvais alors je me suis directement mis dans /root/.ssh/ et j'ai tapé ssh -i/test root@localhost -p 49442 Asimov> ps | grep sshd 14921 root 4588 S sshd: root@pts/1 15108 root 4508 S /opt/sbin/sshd 16009 root 4588 S sshd: root@pts/0 19247 root 4508 S sshd: root@pts/2 20138 root 2968 S grep sshd [/code]

Concernant tes périphériques mobiles (mobiles et tablette), tu dis qu'ils ont le wifi de coupé quand ils sont en veille mais peut-être peuvent ils se connecter via 3G ? Sinon, c'est peut-être en effet ta freebox qui envoie une requête au media server du nas chaque fois que tu l'allumes (et peut-être même en veille, va savoir !) À ce niveau, et avec mes maigres connaissances, je dirais que le plus efficace est des tester en partant du plus bas : éteindre ou couper toute connectivité de tes androids et voir ; et tester ensuite ta freebox en débranchant le boîtier tv. question bête mais bon : tu n'as pas de service internet sur ton nas ? pas de serveur mail, http, ftp, etc. ? Enfin, d'un point de vue général, il est fortement déconseillé, d'activer la mise en veille du syno : les disques s'usent beaucoup plus vite en s'arrêtant et redémarrant régulièrement plutôt qu'en tournant continuellement.

Et pour recréer le raccourci sur le bureau, il suffit de faire un glisser-déposer de l'icône du menu vers le bureau.

Bon alors, retour des courses : 1/ l'activation des logs n'était pas si aisée. Il ne suffit pas de mettre le LogLevel à DEBUG, il fallait aussi modifier le fichier etc/syslog.deny comme indiqué ici => http://glr81.free.fr...01-ssh-logs.htm 2/ je n'arrive toujours pas à me connecter en root en ssh sur le localhost Voici un extrait de mon /var/log/messages. J'ai fait sauter toutes les lignes ne se rapportant pas à sshd (en modifiant le syslog.deny, j'ai les log du serveur mail, de transmission et d'autres qui apparaissent) Sep 12 11:11:15 Asimov auth.info sshd[10272]: Set /proc/self/oom_adj to 0 # aucune idée de ce que c'est Sep 12 11:11:15 Asimov auth.info sshd[10272]: Connection from 192.168.1.12 port 57022 # je me connecte en root depuis mon laptop Sep 12 11:11:15 Asimov auth.info sshd[10272]: Failed none for root from 192.168.1.12 port 57022 ssh2 # pareil, c'est quoi ce foutu "none" Sep 12 11:11:15 Asimov auth.info sshd[10272]: Failed publickey for root from 192.168.1.12 port 57022 ssh2 # et pourquoi là ça veut pas… Sep 12 11:11:15 Asimov auth.info sshd[10272]: Found matching DSA key: 61:f7:61:0c:72:ab:94:08:1c:d8:42:f6:ad:4b:d7:05 Sep 12 11:11:15 Asimov auth.info sshd[10272]: Postponed publickey for root from 192.168.1.12 port 57022 ssh2 Sep 12 11:11:15 Asimov auth.info sshd[10272]: Found matching DSA key: 61:f7:61:0c:72:ab:94:08:1c:d8:42:f6:ad:4b:d7:05 Sep 12 11:11:15 Asimov auth.info sshd[10272]: Accepted publickey for root from 192.168.1.12 port 57022 ssh2 # …alors que là, ça accepte ? o_O Sep 12 11:11:15 Asimov auth.err sshd[10273]: error: setlogin failed: Function not implemented # la désormais classique erreur Sep 12 11:11:30 Asimov auth.info sshd[10659]: Set /proc/self/oom_adj to 0 Sep 12 11:11:30 Asimov auth.info sshd[10659]: Connection from 127.0.0.1 port 54599 # 1ere tentative de connexion en localhost… Sep 12 11:11:30 Asimov auth.info sshd[10659]: Failed none for root from 127.0.0.1 port 54599 ssh2 Sep 12 11:11:35 Asimov auth.info sshd[10659]: Failed password for root from 127.0.0.1 port 54599 ssh2 #…en connexion par mot de passe Sep 12 11:11:37 Asimov auth.info sshd[10659]: Failed password for root from 127.0.0.1 port 54599 ssh2 # je réessaye. Sep 12 11:11:38 Asimov auth.info sshd[10659]: Connection closed by 127.0.0.1 Sep 12 11:11:42 Asimov auth.info sshd[10272]: Received disconnect from 192.168.1.12: 11: disconnected by user Sep 12 11:11:50 Asimov auth.info login[11111]: root login on 'ttyp0' from '192.168.1.12' Sep 12 11:13:59 Asimov auth.info sshd[12064]: Received signal 15; terminating. # modifition du sshd_config pour n'accepter que les connexions par clef et reboot du daemon Sep 12 11:14:25 Asimov auth.info sshd[15108]: Set /proc/self/oom_adj from 0 to -17 Sep 12 11:14:25 Asimov auth.info sshd[15108]: Server listening on :: port 49442. Sep 12 11:14:25 Asimov auth.info sshd[15108]: Server listening on 0.0.0.0 port 49442. Sep 12 11:14:38 Asimov auth.info sshd[15439]: Set /proc/self/oom_adj to 0 Sep 12 11:14:38 Asimov auth.info sshd[15439]: Connection from 127.0.0.1 port 54687 Sep 12 11:14:38 Asimov auth.info sshd[15439]: Failed none for root from 127.0.0.1 port 54687 ssh2 Sep 12 11:14:38 Asimov auth.info sshd[15439]: Connection closed by 127.0.0.1 # échec de la tentative de connexion par clef Sep 12 11:14:53 Asimov auth.info sshd[15811]: Set /proc/self/oom_adj to 0 Sep 12 11:14:53 Asimov auth.info sshd[15811]: Connection from 192.168.1.12 port 57178 # re-connexion depuis le laptop… Sep 12 11:14:53 Asimov auth.info sshd[15811]: Failed none for root from 192.168.1.12 port 57178 ssh2 Sep 12 11:14:53 Asimov auth.info sshd[15811]: Found matching DSA key: 61:f7:61:0c:72:ab:94:08:1c:d8:42:f6:ad:4b:d7:05 Sep 12 11:14:53 Asimov auth.info sshd[15811]: Postponed publickey for root from 192.168.1.12 port 57178 ssh2 Sep 12 11:14:53 Asimov auth.info sshd[15811]: Found matching DSA key: 61:f7:61:0c:72:ab:94:08:1c:d8:42:f6:ad:4b:d7:05 Sep 12 11:14:53 Asimov auth.info sshd[15811]: Accepted publickey for root from 192.168.1.12 port 57178 ssh2 Sep 12 11:14:53 Asimov auth.info sshd[15811]: subsystem request for sftp by user root # …en me connectant en sftp pour récupérer le présent log Sep 12 11:14:53 Asimov auth.err sshd[15812]: error: setlogin failed: Function not implemented 3/ pour le setlogin failed : function not implemented, il semblerait que ça le fasse 1 fois par connexion. Or, jusqu'à présent j'utilisais sur mon laptop un petit outil appelé "GeekTools" qui me permettait d'envoyer des commandes en ssh pour récupérer des infos telles que l'uptime, le nombre de connexions par protocole, etc. La chose ouvrait plusieurs connexions ssh root en même temps et à intervalles réduits ; c'est ce qui faisait apparaître toutes ces lignes d'erreur très rapprochées dans le temps. 4/ je te colle mon /opt/etc/openssh/sshd_config : # $OpenBSD: sshd_config,v 1.84 2011/05/23 03:30:07 djm Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/opt/sbin:/opt/bin:/usr/sbin:/usr/bin:/sbin:/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. Port 49442 # modif perso n°1 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # The default requires explicit activation of protocol 1 #Protocol 2 # HostKey for protocol version 1 #HostKey /opt/etc/openssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /opt/etc/openssh/ssh_host_rsa_key #HostKey /opt/etc/openssh/ssh_host_dsa_key #HostKey /opt/etc/openssh/ssh_host_ecdsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 1024 # Logging # obsoletes QuietMode and FascistLogging SyslogFacility AUTH # activation du log LogLevel DEBUG # activation du log # Authentication: #LoginGraceTime 2m #PermitRootLogin yes # le root login est autorisé par défaut #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #RSAAuthentication yes #PubkeyAuthentication yes # les connexions par clef sont autorisées par défaut # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /opt/etc/openssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no # modif perso n°2 #PermitEmptyPasswords no # Change to no to disable s/key passwords ChallengeResponseAuthentication no # modif perso n°3 - modification effectuée pour coller au plus près du /etc/sshd/sshd_config de Synology # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. #UsePAM no # ici le /etc/ssh/sshd_config est à 'yes' mais ça merdait alors j'ai remis la config par défaut soit 'no'. #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no UsePrivilegeSeparation no # paramètre par défaut du fichier même s'il est décommenté. (dans /etc/ssh/sshd_config c'est à 'yes' ) #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /opt/var/run/sshd.pid #MaxStartups 10 #PermitTunnel no #ChrootDirectory none # no default banner path #Banner none # override default of no subsystems Subsystem sftp /opt/libexec/sftp-server # utilisation du sftp d'optware. paramètre par défaut du fichier même s'il est décommenté. # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # ForceCommand cvs server

J'ai modifié ma config ssh pour accepter les connexions par mot de passe, j'ai killall sshd, activé le telnet et me suis connecté en root, relancé le service /opt/etc/init.d/S40sshd, me suis connecté en root en ssh pour tester si le service était bien lancé et ai essayé de ssh root@localhost => permission denied. J'ai donc réessayé de me connecter mais en admin et ça marche : NAS> ps | grep ssh 6733 root 4508 S /opt/sbin/sshd 7163 root 4588 S sshd: root@pts/0 8321 root 4440 S ssh admin@localhost -p 49442 8322 root 4508 S sshd: admin@pts/1 8774 root 4588 S sshd: root@notty 8952 admin 2964 S grep ssh Donc oui, ça marche. D'ailleurs, quelque que cela prouve ? Quant à la ligne , sshd[20462]: error: setlogin failed: Function not implemented voici les quelques dernières lignes. Comme tu peux le voir, ça s'accumule sans arrêt. Sep 11 21:54:30 sshd[20462]: error: setlogin failed: Function not implemented Sep 11 21:54:30 sshd[20469]: error: setlogin failed: Function not implemented Sep 11 21:54:31 sshd[20475]: error: setlogin failed: Function not implemented Sep 11 21:54:31 sshd[20508]: error: setlogin failed: Function not implemented Sep 11 21:54:40 sshd[20744]: error: setlogin failed: Function not implemented Sep 11 21:54:40 sshd[20751]: error: setlogin failed: Function not implemented Sep 11 21:54:40 sshd[20753]: error: setlogin failed: Function not implemented Sep 11 21:54:50 sshd[21054]: error: setlogin failed: Function not implemented Sep 11 21:54:50 sshd[21061]: error: setlogin failed: Function not implemented Sep 11 21:54:50 sshd[21063]: error: setlogin failed: Function not implemented Sep 11 21:54:56 sshd[21225]: error: setlogin failed: Function not implemented Sep 11 21:54:56 sshd[21228]: error: setlogin failed: Function not implemented

Ouf, désolé pour la frayeur ! 0/ NAS> ssh root@localhost -p 49442 Permission denied (publickey). Ce qui me semble plutôt bon signe puisque si j'ai généré une clef publique pour identifier l'ordi avec lequel je me connecte en ssh sur le nas comme indiqué ici, je n'ai pas fait cette manipulation pour l'utilisateur root du nas donc il s'éjecte lui-même. 1/ ok, va pour la méthode barbare 2/ ta commande a généré la clef mais j'ai toujours des tonnes de Sep 11 16:06:35 sshd[28185]: error: setlogin failed: Function not implemented[/code] 3/ … 4/ ok

ah euh…oups ? activation de telnet pour "ipkg remove openssh" ?

la connexion est refusée parce que je n'ai pas générée de clef pour l'user root, juste pour mon laptop. Je n'ai pas dit qu'openssh ne marchait pas, c'est le sshd de syno qui n'accepte pas le binaire sftp d'optware comme on l'a dit. Je dis que : 1/je n'arrive pas à arrêter le service proprement (juste par la commande kill) 2/ j'ai mon /var/log/messages rempli de Sep 11 16:06:34 sshd[28160]: error: Could not load host key: /opt/etc/openssh/ssh_host_ecdsa_key Sep 11 16:06:35 sshd[28185]: error: setlogin failed: Function not implemented 3/ je donnais les liens vers ma config, si jamais qqn voyait un truc pas net 4/ la commande uptime foirée, ça, c'est réglé

6438 root 4508 S /opt/sbin/sshd 19050 root 4588 S sshd: root@notty 19200 root 2968 S grep sshd 23883 root 4588 S sshd: root@pts/0 Même résultat non ? Le ssh est désactivé dans le DSM.

which sshd me donne /opt/sbin/sshd donc celui d'optware si je lis correctement.

Oui oui j'ai bien lu ton message, ce qui m'a conduit à installer openssh en plus de openssh-sftp-server. Je me disais seulement que peut-être le daemon ssh de syno opérait ainsi à cause d'un souci de mon côté.

Encore une fois merci à tous pour vos réponses et explications, en particulier PiwiLabruti pour ton explication Il se trouvait, allez savoir pourquoi, que la commande uptime était bien liée à l'exécutable d'optwaren, que ledit fichier est bien présent mais que ça me renvoie une erreur : /opt/bin/coreutils-uptime: couldn't get boot time: No such file or directory J'ai supprimé le lien comme indiqué par MrWaloo et tout est rentré dans l'ordre : NAS> which uptime /usr/bin/uptime Cette erreur de fichier soit-disant absent pourrait-elle être liée au fait que je n'ai pas réussi à remettre en fonction le serveur sftp de manière hybride, comme je le faisais sous DSM 4.0, à savoir suivre cela : Install ipkg following the following instructions. reboot ipkg update ipkg install openssh-sftp-server Edit /etc/ssh/sshd_config with the following: # override default of no subsystems #Subsystem sftp /usr/libexec/sftp-server Subsystem sftp /volume1/@optware/libexec/sftp-server

Merci à vous tous, le $PATH me retourne ceci : -ash: /opt/bin:/opt/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin: not found Et mon fichier /root/.profile est rempli ainsi : umask 022 PATH=/opt/bin:/opt/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin export PATH #This fixes the backspace when telnetting in. #if [ "$TERM" != "linux" ]; then # stty erase #fi HOME=/root export HOME TERM=${TERM:-cons25} export TERM PAGER=more export PAGER PS1="`hostname`> " alias dir="ls -al" alias ll="ls -la" [/code] Est-ce correct ?

Ok pour tout, sauf que /bin/uptime ne me retourne rien : "not found" Et d'ailleurs, comment se fait-il que cette commande soit passée de celle de busybox à ipkg ? o_O

Aux dernières nouvelles, ce comportement est souhaité par Synology ; pas de "risque" qu'un patch officiel voit le jour Sinon, j'ai installé OpenSSH comme je vous avais dit. J'ai essayé de comprendre les différentes options du fichier de conf sans trop y arriver mais bref, ça marche. Je peux de nouveau me connecter en root et admin en SFTP \o/ Seulement…j'ai quelques trucs bizarres : 1/ comment arrêter proprement le service ssh/sftp ? Pour l'instant je fais un ça ps | grep ssh puis kill {le pid de /opt/sbin/sshd}[/code] Il devrait quand même y avoir quelque chose de plus propre non ? 2/ Quand je lance le service via la commande ci-dessous j'ai cette erreur. [code] NAS> opt/etc/init.d/S40sshd Could not load host key: /opt/etc/openssh/ssh_host_ecdsa_key [/code] Elle ne semble pas être bloquante mais ça m'énerve un poil… 3/ J'ai essayé de reproduire dans /opt/etc/openssh/sshd_config les paramètres de /etc/ssh/sshd_config et j'imagine que je me suis planté et que tous mes petits tracas viennent de là… -> voir mon /etc/ssh/sshd_config (config de base) -> voir mon /opt/etc/openssh/sshd_config (avec des modifs sur le port, et connec par clef seulement) 4/ Je n'arrive plus à avoir l'uptime ! [CODE]uptime: couldn't get boot time: No such file or directory[/code] Merci d'avance pour votre aide.

Le package Audio Station vient d'être mis à jour en v4.0-2301 et cela résout, chez moi, le problème.

Des nouvelles du forum anglais : Syno confirme que l'on ne peut pas se logguer en root en SFTP et surtout que c'est un problème sur lequel ils travaillent. En attendant qu'un fix officiel ou pas ne sorte, je veux bien un peu d'aide pour configurer OpenSSH parce que les fichiers de conf standard ne comportent pas les mêmes options que pour la conf standard du SSH de Synology.

Bonsoir, Je constate un bug dans Audio Station v4.0-2298 (la dernière version à ce jour) : l'activation du téléchargement de la musique et la désactivation de la recherche de matériel UPnP ne sont pas pris en compte dans le paramétrage. On peut cocher les cases, faire "OK" mais les cases resteront décochées. Il y a d'autres personnes qui ont le souci sur le forum anglophone, je voulais savoir si c'était pareil ici et, le cas échéant, savoir s'il s'agit vraiment d'un bug ou si c'est une conséquence de divers autres paramétrages ailleurs dans le DSM. Je précise que les manips ont été faites via le compte admin.

Ah ! Il fallait mettre 'Debug', j'avais simplement décommenté la ligne. Mais à vrai dire le résultat est le même : rien dans les logs ce qui, si je comprends bien, confirmerait ce que tu dis plus haut à savoir que s'il n'y a pas d'erreur c'est que le ssh syno prend (une partie) de sa config ailleurs que dans /etc/ssh/sshd_config. Je ne sais pas trop, voici les permissions actuelles : [code] drwxr-xr-x 3 root root 4096 Sep 2 21:22 root [/code]