Questions Sur Ssh Et Sftp

[Amsonia]

Bonjour,

Je viens de passer sans encombres en DSM 4.1 v2636 et j'ai deux petites questions concernant le SSH/SFTP.

1/ On peut choisir le port utilisé pour le SFTP mais est-il possible de changer celui du SSH ?

D'ailleurs je ne comprends pas très bien cette différence puisque, d'après mes maiges connaissances, le SFTP est du SSH donc si on change le port du SSH, on change obligatoirement celui du SFTP. Bref soit je ne comprends rien soit Synology a fait les choses à l'envers :s

2/ Étant donné que le service SFTP est classé dans le DSM au même niveau que le FTP, je me demandais s'il fonctionnait de la même manière et en particulier si l'activation du SFTP était valable pour tous les users du NAS ou seulement pour l'admin comme pour le SSH.

Je précise, quand même , que ces réponses ne semblent pas être présentes dans le manuel de ce nouveau firmware ou dans l'aide intégrée au DSM.

[CoolRaoul]

Le service sftp disponible depuis en 4.1, contrairement au ssh, s'applique a tous les comptes.

Par contre il ne laisse voir que les partages autorisés pour l'utilisateur (comme dans le cas du service ftp). Il ne donne par exemple pas acces à "/" et le compte "root" n'est pas autorisé (mais admin oui)

C'est donc un sftp a la sauce synology (qui par exemple gère la corbeille si on l'a activée)

[Amsonia]

Erf, moi qui me réjouissais de voir le SFTP dans le DSM et donc de ne plus avoir à faire quelques manips en SSH à chaque update, c'est raté

Je n'ai pas foncièrement envie de donner un accès SFTP à tout le monde (moins rapide que le FTPS) et si en plus l'user root n'y a pas accès, c'est franchement dommage parce que j'utilisais le SFTP principalement pour éditer mes fichiers via une GUI.

Bref, retour à openssh-sftp-server…

[bud77]

Tu n'es pas obligé de passer par le package IPKG openssh, tu as une manip "simple" ou tu as juste à dé commenter une ligne dans un fichier de conf et relancer le daemon ssh

(J'ai plus le fichier en tête, mais le tuto est sur le wiki UK)

Edit : retrouvé

http://forum.synology.com/wiki/index.php/How_to_setup_an_sftp-server

Method 3 (à tester en DSM 4.1 je dirais)

Modifié le 3 septembre 2012 par bud77

[CoolRaoul]

Edit : retrouvé

http://forum.synolog..._an_sftp-server

Method 3 (à tester en DSM 4.1 je dirais)

Semble plus marcher en 4.1: l'authentification se passe normalement (on se fait jeter avec le message ad hoc si mauvais mot de passe) mais immédiatement apres on se prend un "Connection closed"

et voici la la log :

Sep 3 17:24:51 sshd[1991]: Accepted password for clampin from 127.0.0.1 port 55746 ssh2

Sep 3 17:24:51 sshd[1991]: pam_unix(sshd:session): session opened for user clampin by (uid=0)

Sep 3 17:24:51 sshd[2192]: subsystem request for sftp by user clampin

Sep 3 17:24:51 sshd[2192]: Received disconnect from 127.0.0.1: 11: disconnected by user

Sep 3 17:24:51 sshd[1991]: pam_unix(sshd:session): session closed for user clampin

[bud77]

@Raoul : Vérifie si tu as bien ce binaire de présent :

/usr/libexec/sftp-server

[CoolRaoul]

@Raoul : Vérifie si tu as bien ce binaire de présent :

Absent mais de toutes façons Il est requis uniquement dans le cas de la config:

Subsystem sftp /usr/libexec/sftp-server

pas dans le cas suivant (celui que j'ai utilisé):

Subsystem sftp internal-sftp[/code]

[bud77]

Damned

Sinon, si tu fais un sftp sur le port SSH, tu as bien accès en root toujours ?

[CoolRaoul]

Damned

Sinon, si tu fais un sftp sur le port SSH, tu as bien accès en root toujours ?

en root non plus: me fait jeter

[Amsonia]

Tout pareil que CoolRaoul.

La méthode 3 fonctionne chez toi sur DSM4.1 bud77 ?

[bud77]

Bon, çà va pas me plaire cette histoire ... Moi qui suis encore en 3.2, je voulais monter ... Cà va ptet attendre ...

PS: tu le fais bien depuis ton réseau, ou depuis SIAB ?

[PiwiLAbruti]

Pour ma part, je n'ai pas réussi à remonter SFTP en DSM 4.1.

[CoolRaoul]

PS: tu le fais bien depuis ton réseau, ou depuis SIAB ?

Suis chez moi aujourd'hui, tout en local donc.

Mais on peut se passer de sftp, reste toujours "scp" apres tout.

[Amsonia]

Pour ma part, je n'ai pas réussi à remonter SFTP en DSM 4.1.

Et tu passais par la méthode 3 de http://forum.synology.com/wiki/index.php/How_to_setup_an_sftp-server ?

[bud77]

Suis chez moi aujourd'hui, tout en local donc.

Mais on peut se passer de sftp, reste toujours "scp" apres tout.

Pas sur mon tel

[PiwiLAbruti]

Et tu passais par la m

[Amsonia]

Oualala rien ne va pas plus, je n'arrive même plus à mettre en place openss-sftp-server selon la méthode 1 de http://forum.synolog..._an_sftp-server

Voici mon fichier etc/ssh/sshd_config : http://snipurl.com/24vkr9d

Vous remarquerez que j'ai :

- changé le port

- désactivé l'authentification par mot de passe

- activé -et par conséquent rendue obligatoire- l'authentification par clef

ce sont les paramètres que j'avais avant l'update du DSM et tout fonctionnait parfaitement.

Je pense que le problème vient du pavé de lignes suivantes :

# override default of no subsystems

#Subsystem    sftp    /usr/libexec/sftp-server

Subsystem	   sftp    /volume1/@optware/libexec/sftp-server

#Subsystem	   sftp    internal-sftp -f DAEMON -l VERBOSE -u 000


#Subsystem	   sftp    internal-sftp -f DAEMON -u 000

#Subsystem	   sftp    /usr/syno/sbin/sftp-server -l DEBUG3

J'ai bien rajouté la ligne du serveur d'optware commande demandé et re-commenté la ligne "internal-sftp -f DAEMON -u 000", pensant qu'il ne fallait y avoir qu'une seule ligne d'active.

Je reboote le ssh via le DSM et…rien. Impossible de me connecter, que ce soit en admin ou root.

(les modifs sont faites via VI sous ssh, les "espaces" sont bien des tabulations)

Voyant que ça ne fonctionnait pas, j'ai dé-commenté la ligne que j'avais précédemment re-commenté : internal-sftp -f DAEMON -u 000

Je reboote le SSH via le DSM et là c'est la grosse blague : le SSH ne veut pas s'activer ! Le DSM ne me met pas d'erreur mais la case "activer le SSH" reste décochée.

Où est-ce que je me suis encore planté ? :-/

[bud77]

Tu as sauvegardé le fichier original ?

Si oui, tu peux le restaurer via config file editor

Si non, tu peux éditer ton fichier actuel via config file editor

[Amsonia]

Je n'avais pas sauvegardé le fichier original mais j'ai activé le telnet (suis en local) pour re-commernter ladite ligne.

Mais si je peux ouvrir des sessions SSH, je ne peux toujours pas naviguer en SFTP :-(((

[Amsonia]

Je n'y comprends plus rien (qui a dit "comme d'hab" ? )

- le ssh avec mes modifs fonctionne (pas de pwd, que des clefs, port 49442)

- ipkg est ok

- openssh-sftp-server est installé et sshd_config pointe bien vers /volume1/@optware/libexec/sftp-server

- openssh n'est pas installé puisque je souhaite utiiiser le ssh du syno pour le ssh et le serveur sftp d'ipkg ; pas besoin/envie d'avoir 2 instances ssh en //

Et pourtant, c'est toujours la même chose "le nom d'utilisateur ou le mot de passe a été refusé par le serveur" ce qui est ahurissant puisque je me connecte par clef pub.

Il n'y a pas un moyen de rendre ce sftp-server un peu plus bavard ? Histoire d'avoir peut-être une chance de savoir où ça bloque !

[bud77]

Il doit y avoir un option "-verbose" à rajouter au daemon, le tout est de savoir ou/comment il le lance :/

[CoolRaoul]

Je pense que le problème vient du pavé de lignes suivantes :

# override default of no subsystems

#Subsystem sftp /usr/libexec/sftp-server

Subsystem	 sftp /volume1/@optware/libexec/sftp-server

#Subsystem	 sftp internal-sftp -f DAEMON -l VERBOSE -u 000


#Subsystem	 sftp internal-sftp -f DAEMON -u 000

#Subsystem	 sftp /usr/syno/sbin/sftp-server -l DEBUG3

J'ai bien rajouté la ligne du serveur d'optware commande demandé et re-commenté la ligne "internal-sftp -f DAEMON -u 000", pensant qu'il ne fallait y avoir qu'une seule ligne d'active.

en effet mais si il y en a plusieurs tu n'aura pas de message d'erreur, sshd va prendre en compte soit la première soit la dernière (me souviens plus)

Je reboote le ssh via le DSM et…rien. Impossible de me connecter, que ce soit en admin ou root. (les modifs sont faites via VI sous ssh, les "espaces" sont bien des tabulations) Voyant que ça ne fonctionnait pas, j'ai dé-commenté la ligne que j'avais précédemment re-commenté : internal-sftp -f DAEMON -u 000 Je reboote le SSH via le DSM et là c'est la grosse blague : le SSH ne veut pas s'activer ! Le DSM ne me met pas d'erreur mais la case "activer le SSH" reste décochée. Où est-ce que je me suis encore planté ? :-/

Dans le cas du ssh optware, ajoute la ligne suivante

Loglevel Debug[/code]

au fichier de config

et regarde dans /var/log/messages.

Sinon connectes-toi en telnet et relance le serveur ssh a la main

[CoolRaoul]

Oups! Je n'avait pas fait gaffe que tu utilisais la methode "hybride" (sshd DSM et sftp serveur optware)

Dans ce cas, il me semble bien que le sshd DSM soit sérieusement "customisé" par Synology et, par exemple, qu'il ne tienne pas compte de certaines clauses de sshd-config (telles que "Subsystem sftp")

En regardant le contenu du script de startup sftp ("/usr/syno/etc/rc.d/S99sftpd.sh") on trouve des choses bizarres telles que :

${SSHDUtils} --register ${ReferKeySFTP} ${ReferProcSFTP}

ce qui se traduit une fois les variables remplacées par:

/usr/syno/bin/synosshdutils --register sftpd internal-sftp[/code]

et donc on retrouve, comme par hasard, les lignes de config en question

M'étonnerait pas que le ssh DSM lise une partie de sa confguration ailleurs que dans /etc/ssh/sshd-config.

[PiwiLAbruti]

Ça viendrait d'un problème de droits sur le dossier /root ?

http://forum.synology.com/enu/viewtopic.php?f=19&t=55972

[Amsonia]

Oups! Je n'avait pas fait gaffe que tu utilisais la methode "hybride" (sshd DSM et sftp serveur optware)

Dans ce cas, il me semble bien que le sshd DSM soit sérieusement "customisé" par Synology et, par exemple, qu'il ne tienne pas compte de certaines clauses de sshd-config (telles que "Subsystem sftp")

En regardant le contenu du script de startup sftp ("/usr/syno/etc/rc.d/S99sftpd.sh") on trouve des choses bizarres telles que :

${SSHDUtils} --register ${ReferKeySFTP} ${ReferProcSFTP}

ce qui se traduit une fois les variables remplacées par:

/usr/syno/bin/synosshdutils --register sftpd internal-sftp[/code]




et donc on retrouve, comme par hasard, les lignes de config en question



M'étonnerait pas que le ssh DSM lise une partie de sa confguration ailleurs que dans /etc/ssh/sshd-config.





C'est étrange -et énervent- cette affaire. Je suis quasi certain que j'ai toujours utilisé ce mode hybride comme tu dis, je ne me rappelle pas avoir déjà installé et surtout configuré le daemon openssh soit toucher aux fichiers /opt/etc/openssh/ssh_config et/ou /opt/etc/openssh/sshd_config



Peut-être est-ce du à l'arrivée du SFTP made in Synology dans le DSM4.1 ? Synology en aurait "profité" pour castrer son deamon SSH aussi à sa façon…

Il serait intéressent que qqn vérifie ce que tu dis CoolRaoul sur un DSM antérieur au 4.1



Bref. J'ai installé OpenSSH et j'ai copié les deux fichiers de config, et les ai rajouté dans Config File Editor. J'ai donc :

/opt/etc/openssh/ssh_config

/opt/etc/openssh/ssh_config-defaults

/opt/etc/openssh/sshd_config

/opt/etc/openssh/sshd_config-defaults



J'imagine que l'étape suivante consiste à remettre tous les paramètres de /etc/ssh/sshd_config à leur valeur par défaut et de customiser la config d'OpenSSH mais j'avoue ne pas savoir s'il suffit de toucher la conf globale (/opt/etc/openssh/ssh_config) ou également celle individuelle à chaque user (/opt/etc/openssh/sshd_config).

en effet mais si il y en a plusieurs tu n'aura pas de message d'erreur, sshd va prendre en compte soit la première soit la dernière (me souviens plus) Dans le cas du ssh optware, ajoute la ligne suivante

[code]Loglevel Debug[/code]

au fichier de config et regarde dans /var/log/messages. Sinon connectes-toi en telnet et relance le serveur ssh a la main

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.

Ça viendrait d'un problème de droits sur le dossier [font=courier new,courier,monospace]/root[/font] ? http://forum.synolog...hp?f=19&t=55972

Je ne sais pas trop, voici les permissions actuelles :

[code] drwxr-xr-x 3 root root 4096 Sep 2 21:22 root [/code]