Questions Sur Ssh Et Sftp

[Amsonia]

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.

[Amsonia]

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.

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.

[MrWaloo]

4/ Je n'arrive plus à avoir l'uptime !

uptime: couldn't get boot time: No such file or directory[/CODE]

Ça m'est aussi déjà arrivé...

Avec coreutils de ipkg, l'exécutable uptime est celui se trouvant sous /opt/bin/uptime, tu peux le vérifier en faisant "which uptime". Ce fichier est un lien symbolique vers "/opt/bin/coreutiles-uptime". Tu peux le vérifier en listant le contenu de /opt/bin.

Si tel est le cas, il te suffit de supprimer le lien "rm /opt/bin/uptime", et le tour est joué.

Avant ça tu peux faire "/usr/bin/uptime" pour être sûr que ça te retourne bien quelque chose de correct.

A+

Michel

edit: mise à jour du path vers uptime dans /usr/bin et pas dans /bin

Merci Piwi !

Modifié le 11 septembre 2012 par MrWaloo

[Amsonia]

Ça m'est aussi déjà arrivé...

Avec coreutils de ipkg, l'exécutable uptime est celui se trouvant sous /opt/bin/uptime, tu peux le vérifier en faisant "which uptime". Ce fichier est un lien symbolique vers "/opt/bin/coreutiles-uptime". Tu peux le vérifier en listant le contenu de /opt/bin.

Si tel est le cas, il te suffit de supprimer le lien "rm /opt/bin/uptime", et le tour est joué.

Avant ça tu peux faire "/bin/uptime" pour être sûr que ça te retourne bien quelque chose de correct.

A+

Michel

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

[CoolRaoul]

Et d'ailleurs, comment se fait-il que cette commande soit passée de celle de busybox à ipkg ? o_O

Tu trouvera l'explication en observant le contenu de la variable "$PATH"

[PiwiLAbruti]

La commande uptime se situe dans /usr/bin/.

Elle est peut-être passée à ipkg à cause du path modifié par ipkg ? (> echo $PATH)

--------

edit: Grillé par CoolRaoul

Modifié le 11 septembre 2012 par PiwiLAbruti

[MrWaloo]

En effet dans /usr/bin, j'ai tapé trop vite...

J'ai mis mon post à jour pour ceux qui auront le problème plus tard...

[Amsonia]

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 ?

[CoolRaoul]

Est-ce correct ?

C'est correct, et pour que ce soit la commande "uptime" de DSM qui soit utilisée à la place de celle d'optware ajoute la ligne suivante dans ton .profile:

alias uptime=/usr/bin/uptime[/CODE]

[PiwiLAbruti]

Lorsqu'on demande à exécuter un programme, le système le recherche en utilisant la variable $PATH de manière séquentielle.

La recherche s'arrête dès que le programme est trouvé, dans ton cas la recherche de la command uptime se fait comme suit :

PATH=/opt/bin:/opt/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin


/opt/bin/uptime # Trouvé, la recherche s'arrête ici

/opt/sbin/uptime

/sbin/uptime

/bin/uptime

/usr/sbin/uptime

/usr/bin/uptime

/usr/syno/sbin/uptime

/usr/syno/bin/uptime

/usr/local/sbin/uptime

/usr/local/bin/uptime

Pour que ipkg ne remplace pas les programmes existants, il suffirait de modifier l'ordre de recherche dans la variable $PATH en plaçant les chemins vers ipkg à la fin.

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin:/opt/bin:/opt/sbin


/sbin/uptime

/bin/uptime

/usr/sbin/uptime

/usr/bin/uptime # Trouvé, la recherche s'arrête ici

/usr/syno/sbin/uptime

/usr/syno/bin/uptime

/usr/local/sbin/uptime

/usr/local/bin/uptime

/opt/bin/uptime

/opt/sbin/uptime

[MrWaloo]

Lorsqu'on demande à exécuter un programme, le système le recherche en utilisant la variable $PATH de manière séquentielle.

La recherche s'arrête dès que le programme est trouvé, dans ton cas la recherche de la command uptime se fait comme suit :

PATH=/opt/bin:/opt/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin


/opt/bin/uptime # Trouvé, la recherche s'arrête ici

/opt/sbin/uptime

/sbin/uptime

/bin/uptime

/usr/sbin/uptime

/usr/bin/uptime

/usr/syno/sbin/uptime

/usr/syno/bin/uptime

/usr/local/sbin/uptime

/usr/local/bin/uptime

Pour que ipkg ne remplace pas les programmes existants, il suffirait de modifier l'ordre de recherche dans la variable $PATH en plaçant les chemins vers ipkg à la fin.

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin:/opt/bin:/opt/sbin


/sbin/uptime

/bin/uptime

/usr/sbin/uptime

/usr/bin/uptime # Trouvé, la recherche s'arrête ici

/usr/syno/sbin/uptime

/usr/syno/bin/uptime

/usr/local/sbin/uptime

/usr/local/bin/uptime

/opt/bin/uptime

/opt/sbin/uptime

Oui en effet, mais ce n'est pas le but recherché pour tous les paquets installés...

Certains paquets ont des fonctionnalités plus proches de ce qu'on a l'habitude d'avoir sur nos système Linux (rsync, find, etc.) dans ipkg alors que la version de BusyBox du Syno ne les ont pas.

Le principe étant d'installer un paquet pour s'en servir, mais que uptime de coreutils ne convient pas, alors il faudrait plutôt supprimer le lien symbolique comme je l'ai indiqué.

C'est sûr ta manière fonctionne également mais court-circuite complètement les paquets installés avec ipkg.

La manière de CoolRaoul fonctionne également, mais sera perdue à la prochaine mise à jour DSM.

Un fichier installé par ipkg ne sera recréé que lors d'un upgrade de ipkg, et que ce paquet est mis à jour.

Dans tous les cas, il faut savoir ce que l'on fait....

A+

Michel

[CoolRaoul]

Pour que ipkg ne remplace pas les programmes existants, il suffirait de modifier l'ordre de recherche dans la variable $PATH en plaçant les chemins vers ipkg à la fin.

Oui mais cela va avoir l'inconvénient de masquer toutes les commandes optware pour lesquelles un équivalent DSM existe, et il peut y en avoir un paquet comme on peut le constater avec la commande ci dessous:

ls /bin /usr/bin /sbin /usr/sbin | sed -e 's-^.*/--' |xargs which |grep /opt [/CODE]

C'est pourquoi je préfère l'approche au coup par coup par alias.

[CoolRaoul]

La manière de CoolRaoul fonctionne également, mais sera perdue à la prochaine mise à jour DSM.

Pas forcément: je met ce genre de chose dans "/usr/local/etc/profile", qui n'est pas touché (comme tout ce qui est sous /usr/local) en cas de mise a jour DSM

Suffit d'ajouter ". /usr/local/etc/profile" dans /etc/profile en cas d'update.

Et cela peut même être fait automatiquement par un script de startup dans "/usr/local/etc/rc.d" (pas touché donc) , qui ferait un truc du genre de

grep -q "/usr/local/etc/profile" /etc/profile || echo ". /usr/local/etc/profile" >> /etc/profile[/CODE]

[MrWaloo]

Ah là OK...

Mais pourquoi tu dis pas tout, tout de suite ?

[Amsonia]

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

[CoolRaoul]

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

Je pencherait plutôt, comme je le disais dans à penser que la raison est que la nouvelle version de sshd intégrée dans DSM4.1 ne prend plus en compte toutes les clauses de "/etc/ssh/sshd_config", et en particulier "Subsystem sftp" (depuis que Syno a intégré son propre client sftp)

[Amsonia]

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é.

[CoolRaoul]

Oui oui j'ai bien lu ton message, ce qui m'a conduit à installer openssh en plus de openssh-sftp-server.

Quel est le sshd qui tourne sur ta machine, celui d'optware ou celui natif DSM ?

[Amsonia]

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

[CoolRaoul]

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

ce que je veux savoir est quel sshd est en cours d'exécution

fait plutot:

ps -ef |grep sshd[/CODE]

[Amsonia]

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.

Modifié le 11 septembre 2012 par Amsonia

[CoolRaoul]

et donc qu'est ce qui ne marche pas?

que se passe-t-il, lorsque, connecté au syno, tu tapes

ssh root@localhost

et/ou

sftp root@localhost

.

[CoolRaoul]

Merde!!!

j'ai voulu installer ssh optware pour t'aider et voila le résultat juste apres le "ipkg install"

root@fserv> ls -l / | grep etc

ls: cannot access /etc: No such file or directory

d????????? ? ? ? ? ? etc

drwxr-xr-x 15 0 0 4096 2012-09-04 10:59 etc.defaults

[Amsonia]

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é

[CoolRaoul]

je ne vais plus pouvoir t'aider pour le moment, cf mon message précédent