Amsonia

Personnalisation Je rajoute rapidement quelques liens vers des blogposts -en anglais certes- mais très clairs. Ces modifications sont souvent synonymes d'une sécurité accrue par le simple fait que votre configuration n'est plus standardisée. Pour ceux qui ont suivi le tutoriel pour le DSM 4.1 v2636 (et probablement ultérieurs), les modifications ne se font pas sur /etc/ssh/sshd_config mais sur /opt/etc/openssh/ssh_config Toutes les modifications nécessitent un redémarrage du daemon SSH pour être prises en compte. Je vous conseille de désactiver le blocage automatique durant vos tests, ce serait bête de se retrouver bloqué dehors ! 1/ Changer le port Si vous utilisez le terminal d'OS X, la connexion se fera désormais en ajoutant l'argument -p leport ssh root@votresyno -p 12345 2/ Se connecter par échange de clefs plutôt qu'avec un mot de passe 2.1/ Pour l'utilisateur root 2.2/ Pour tout autre utilisateur À noter, pour ceux qui ont suivi le tutoriel pour le DSM 4.1 v2636, il vous faut entrer une commande supplémentaire à la fin de la procédure : ssh-keygen -t ecdsa -C '' -N '' -f /opt/etc/openssh/ssh_host_ecdsa_key [/code] [font=lucida sans unicode,lucida grande,sans-serif][b]3/ Désactiver les connexions par mot de passe (= forcer les connexions par clef)[/b][/font] [font=lucida sans unicode,lucida grande,sans-serif][b]4/ Raccourci de connexion (pour les gros fainéants comme moi )[/b][/font]

Et voilà le tutoriel ==> (on peut fermer ce sujet maintenant non ?)

Avant le DSM 4.1 v2636 On peut mettre en place le SFTP par 4 manières différentes, classées ici par ordre décroissant d'efficience. 1/ En activant le serveur SFTP interne source : http://forum.synolog...server#Method_3 On utilise le serveur SSH interne et on va simplement modifier une ligne de configuration pour activer le serveur SFTP interne. 1.1/ Le fichier à modifier : /etc/ssh/sshd_config 1.1.1/ Faire une sauvegarde cp etc/ssh/sshd_config etc/ssh/sshd_config_default[/code] [font=lucida sans unicode,lucida grande,sans-serif]1.1.2/ Modifier le fichier de telle sorte que la liste des serveurs SFTP soit égale à celle-ci :[/font] [code]# override default of no subsystems #Subsystem sftp /usr/libexec/sftp-server Subsystem sftp internal-sftp[/code] Ce fichier de configuration est déjà présent dans la liste proposée par Config File Editor. [font=lucida sans unicode,lucida grande,sans-serif]1.2/ Enfin, relancer le daemon SSH via le DSM.[/font] [i]Panneau de configuration > Terminal > SSH[/i] Pour arrêter le serveur SFTP il vous suffit de désactiver le SSH dans le DSM. [u][font=lucida sans unicode,lucida grande,sans-serif][b][size=4]2/ En utilisant un système hybride : SSH interne + SFTP optware[/size][/b][/font][/u] [size=3][i]source : http://forum.synolog...server#Method_1[/i][/size] On utilise le serveur SSH interne, on installe de SFTP d'IPKG et on modifie la configuration du serveur SSH interne pour qu'il utilise les binaires du SFTP d'IPKG. Il nous faut travailler en lignes de commande, (re-)lire l'avant-propos à ce sujet. [font=lucida sans unicode,lucida grande,sans-serif]2.1/ Tout d'abord, installer IPKG.[/font] Voir ce tutoriel pour de l'aide. [font=lucida sans unicode,lucida grande,sans-serif]2.2/ Installer le serveur SFTP optware en entrant les commandes suivantes :[/font] [code]ipkg update ipkg install openssh-sftp-server[/code] [font=lucida sans unicode,lucida grande,sans-serif]2.3/ Le fichier à modifier :[/font] [font=courier new,courier,monospace]/etc/ssh/sshd_config[/font] [font=lucida sans unicode,lucida grande,sans-serif]2.3.1/ Faire une sauvegarde[/font] [code]cp etc/ssh/sshd_config etc/ssh/sshd_config_default[/code] [font=lucida sans unicode,lucida grande,sans-serif]2.3.2/ Modifier le fichier de telle sorte que la liste des serveurs SFTP soit égale à celle-ci :[/font] [code]# override default of no subsystems #Subsystem sftp /usr/libexec/sftp-server Subsystem sftp /volume1/@optware/libexec/sftp-server[/code] Si vous désirez utiliser CFE pour modifier le fichier, ajoutez la ligne suivante dans son fichier de configuration puis relancez CFE pour accéder au nouveau fichier. [font=courier new,courier,monospace]etc/ssh/sshd_config,config ssh[/font] [font=lucida sans unicode,lucida grande,sans-serif]2.4/ Enfin, relancer le daemon SSH via le DSM.[/font] [i]Panneau de configuration > Terminal > SSH[/i] Pour arrêter le serveur SFTP il vous suffit de désactiver le SSH dans le DSM. [u][font=lucida sans unicode,lucida grande,sans-serif][b]3/ Troisième méthode[/b][/font][/u] [size=3][i]source : http://forum.synolog...server#Method_2[/i][/size] Je ne vois pas l'intérêt de cette méthode, que ce soit dans le fond ou sur la forme. Utilisateurs curieux (et initiés) suivez "simplement" le guide du wiki. [u][font=lucida sans unicode,lucida grande,sans-serif][b]4/ En passant complètement par les paquets optware/IPKG[/b][/font][/u] Voir la méthode complète ci-dessous. Cette méthode est ici déconseillée puisque les deux premières sont bien plus simples à mettre en place et à utiliser. [size=5][font=lucida sans unicode,lucida grande,sans-serif][b]Depuis le DSM 4.1 v2636[/b][/font][/size] Depuis le DSM 4.1 v2636, les méthodes décrites plus haut (au moins les deux premières) sont inopérantes. De plus, le SFTP est inclus au DSM mais se comporte comme l'accès FTP : - l'activation vaut pour tous les utilisateurs du NAS… - …sauf l'utilisateur root ! Nombreux seront ceux qui soutiendront -et à raison- qu'il est dangereux de se connecter directement en root via SSH/SFTP même si l'on est un utilisateur chevronné et qu'il vaut mieux se connecter en admin et utiliser la fameuse commande [font=courier new,courier,monospace]sudo[/font] pour s'octroyer temporairement des droits de root. Par ailleurs, nombreux seront également ceux qui nous conseilleront d'opérer des transferts de fichiers en SFTP plutôt qu'en FTPS parce que cela est plus sécurisé, surtout si l'on se connecte par échange de clef plutôt que par mot de passe. (Il n'empêche que, chez moi, le transferts SFTP sont plus lents qu'en FTPS et FTP) Il existe donc de nombreuses raisons de ne pas utiliser l'utilisateur root directement et Synology a fait un choix logique, celui de la sécurité. Soit. Mais si l'on souhaite tout de même avoir un accès SFTP en root "comme avant", voici ce qu'il faut faire : installer et configurer les serveurs SSH et SFTP d'optware. Nous allons donc complètement court-cicuiter les outils livrés avec le NAS pour n'utiliser que ceux d'IPKG. [font=lucida sans unicode,lucida grande,sans-serif]1/ Tout d'abord, installer IPKG.[/font] Voir ce tutoriel pour de l'aide. [font=lucida sans unicode,lucida grande,sans-serif]2/ Installer OpenSSH et OpenSSH-SFTP-server en entrant les commandes suivantes :[/font] [code]ipkg update ipkg install OpenSSH ipkg install openssh-sftp-server[/code] [font=lucida sans unicode,lucida grande,sans-serif]3/ Le fichier à modifier :[/font] [font=courier new,courier,monospace]/opt/etc/openssh/ssh_config[/font] [font=lucida sans unicode,lucida grande,sans-serif]3.1/ Faire une sauvegarde[/font] [code]cp /opt/etc/openssh/ssh_config /opt/etc/openssh/ssh_config-defaults[/code] [font=lucida sans unicode,lucida grande,sans-serif]3.2/ Les modifications[/font] Repérez les passages correspondants dans le fichier et faire les modifications pour coller à la configuration ci-dessous. Je vous ai mis le paquet pour le contexte mais seules 2 ligne sont à modifier. [code] # Change to no to disable s/key passwords ChallengeResponseAuthentication no [/code] [code] #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no UsePrivilegeSeparation no #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 [/code] Si vous désirez utiliser CFE pour modifier le fichier, ajoutez la ligne suivante dans son fichier de configuration puis relancez CFE pour accéder au nouveau fichier. [font=courier new,courier,monospace]/opt/etc/openssh/sshd_config,opt sshd_config[/font] À noter que je suis tout sauf un expert de SSH donc si quelqu'un voit une meilleure configuration, qu'il se fasse connaître ! [font=lucida sans unicode,lucida grande,sans-serif]4/ Lancer le service en exécutant la commande suivante :[/font] [code]/opt/etc/init.d/S40sshd[/code] [font=lucida sans unicode,lucida grande,sans-serif]4.1/ Vérifier qu'il fonctionne[/font] [CODE]ps | grep ssh[/code] Vous devez retrouver le chemin de l'executable : [font=courier new,courier,monospace]/opt/sbin/sshd[/font] Pour arrêter le service, faire un simple [CODE]killall sshd[/code] Vous remarquerez ici que le lancement et l'arrêt du SSH/SFTP se fait uniquement en ligne de commande. Vous savez maintenant comment installer et utiliser SFTP sur votre NAS Pour les personnalisations, on verra une autre fois ;-)

ahah oui pourquoi pas

Pour ceux qui ne seraient pas encore au courant, OVH va abandonner le webDAV d'ici 3 ou 4 semaines pour passer sur de l'OpenStack Swift (pour mettre en place la synchronisation notamment). Donc, hormis s'il y a un paquet IPKG pour du Swift et/ou si qqn nous sort un SPK bien fait, on ne pourra plus avoir hubic sur nos syno. Ceci étant dit, il est aussi dit qu'OVH va sortir de nouvelles offres pro (probablement plus chères), une offre PCS où l'on paye uniquement ce que l'on consomme (là aussi, probablement plus cher que hubic actuel) et enfin une offre "hubic archive" pour concurrencer Amazon Glacier. Toutes les infos ici => http://www.presence-pc.com/actualite/hubic-cloud-48770/#xtor=RSS-11

Oui, bien sûr qu'un véritable terminal est plus confortable et puissant. Ce SPK ainsi que Shellinabox sont toutefois utiles parce qu'ils indépendant de l'OS de son ordi ;-)

Si, comme moi, vous avez régulièrement des problèmes pour configurer proprement des accès IMAP sur vos différents devices (laptop, smartphone, client mail lourd, webmail, etc.), voici la configuration qui fonctionne à tous les coups chez moi et qui, j'imagine, doit être celle par défaut. Cela se configure dans l'interface de Roundcube et ce pour chaque compte. Brouillons : Drafts Messages envoyés : Sent Indésirables (spam) : Junk Corbeille : Trash J'ai remarqué que le roundcube du NAS ne mettait pas "Sent" par défaut mais "Sent messages", ce qui perturbait certains clients peu configurables comme les clients mail de smartphone. J'ai testé avec succès cette configuration sur : - Sparrow OS X - Postbox v3 (donc j'imagine aussi Thunderbird v3) - MailDroid sur Android

Exact sauf que Shellinabox n'est pas compatible avec toutes les architectures (manque au moins les PowerPC) au contraire de Web Console.

N'être que deux à avoir les droits de visualisation des photos ne veut pas dire que quelqu'un d'autre (moi par ex) ne puisse pas afficher la page d'accueil de photo station. Donne-moi l'adresse de ton syno (en pm si tu le souhaites) et dis-moi quand le syno est en veille ; j'irai voir alors la page et on verra si le syno se réveille ou pas Ok pour quickconnect. Qu'en est-il pour DDNS, celui de Synology en particulier ? edit : le tuto est là au fait :

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.