Acces Ftp Securise

[guig]

Salut !

Tous mes voeux pour cette nouvelle année !

Je viens vers vous concernant un pb de connexion FTP sécurisé ...

Quoi que je fasse, impossible de se connecter en mode sécurisé, SSL, TLS ou SSH, rien n'y fait ?!

La connexion arrive bien sur le NAS (donc visiblement pas un pb de ports) mais l'authentification ne fonctionne pas ...

Plus précisément, avec SSL, la négociation commence, et s'ensuit une déconnexion pur et simple ... ou un message "AUTH SSL : 500 : command not understood", ce qui a le mérite d'être clair ;-)

Avec SSH, le certificat arrive, je l'accepte, mais la combinaison login/pass n'est pas reconnue ?!

Testé avec WS_FTP et Filezilla ... même chose ...

Le tout fonctionne parfaitement en FTP non sécurisé.

Si qq'un a un tuyau, je suis preneur :-)

Merci d'avance.

[EDIT] :

Après qq. tests supplémentaires, l'accès en SSL/TLS fonctionne à travers un VPN ... ce qui supposerait un pb. de connexion uniquement à partir de l'extérieur ... mais rien dans les logs. du firewall ... donc pas de pb. d'ouverture de ports, à priori.

En revanche, en SSH, impossible, le couple login/pass semble coincer ... et pourtant ... !

[Tof]

> impossible de se connecter en mode sécurisé, SSL, TLS ou SSH, rien n'y fait ?!

pour le ssl, je peux guère t'aider

> avec SSL, la négociation commence, et s'ensuit une déconnexion pur et simple ... ou un message "AUTH SSL : 500 : command not understood",

chez moi j'ai 504 AUTH type not supported mais le serveur ftp n'est pas configuré pour

changer de chiffrement (explicite/implicite) ou de méthode ssl/tls ou tls ou ssl ?

> Avec SSH, le certificat arrive, je l'accepte, mais la combinaison login/pass n'est pas reconnue ?!

j'utilise winScp sans problèmes. ça ne pourrait pas convenir à tes besoins ?

je viens d'essayer avec FileZilla en ssh, j'ai effectivement un problème:

Commande : CONNECT user@192.168.1.10:22

Réponse : Remote working directory is /volume1/home/user

Etat : Connecté

Etat : Récupération de la liste de répertoires...

Commande : CD /usr/mmchen/

Réponse : Directory /usr/mmchen: no such file or directory

Erreur : N'a pas pu récupérer la liste du répertoire

tout à l'air correct, sauf que je ne vois pas trop d'où vient ce dossier CD /usr/mmchen/

> en SSH, impossible, le couple login/pass semble coincer ... et pourtant ... !

avec root / synopass c'est pas mieux ?

[guig]

Merci pour ces infos !

Pour continuer :

SSL/TLS : ok en mode "Explicit" sur LAN ou à travers un VPN

mode "Implicit" ne fonctionne pas non plus, ce qui expliquerait également ton message d'erreur.

SSL/TLS : ne fonctionne pas depuis accès exterieur, message d'erreur :

Commande : AUTH SSL

Réponse : 500 Command not understood.

Erreur : Impossible de se connecter !

je comprends pas ? pas d'erreur dans le log du firewall, donc pas d'erreur de protocole ou d'ouverture de ports ?!

pourquoi la commande est-elle correctement interprétée en local ou VPN, et pas en accès exter ?

je soupçonne une amputation partielle de la trame IP soit par le firewall du site qui tente d'accéder, soit à mon firewall local ... mais va savoir qui ?

SSH : ne fonctionne pas avec Filezilla ni WS_FTP ...

Etat : Connecté à "ip_address", initialisation de la connexion SFTP...

Commande : CONNECT user<at>IP:22

Réponse : Fatal: Unable to authenticate

> j'utilise winScp sans problèmes. ça ne pourrait pas convenir à tes besoins ?

merci pour le tuyau, je vais essayer ça et te tiendrai au courant.

>je viens d'essayer avec FileZilla en ssh, j'ai effectivement un problème:

Commande : CONNECT user@192.168.1.10:22

Réponse : Remote working directory is /volume1/home/user

Etat : Connecté

Etat : Récupération de la liste de répertoires...

Commande : CD /usr/mmchen/

Réponse : Directory /usr/mmchen: no such file or directory

Erreur : N'a pas pu récupérer la liste du répertoire

tout à l'air correct, sauf que je ne vois pas trop d'où vient ce dossier CD /usr/mmchen/

je ne sais pas à quoi correspond ce dossier (je débute avec mon Syno ;-)

quant à la combinaison root/synopass, j'avais aussi testé, sans succès ...

je continue de chercher et te tiens informé si je trouve qq chose ...

merci pour ton aide !

[Tof]

> pourquoi la commande est-elle correctement interprétée en local ou VPN, et pas en accès exter ?

> je soupçonne une amputation partielle de la trame IP soit par le firewall du site qui tente d'accéder, soit à mon firewall local ... mais va savoir qui ?

pas simple ton truc. tu es bien en passif?

j'ai oublié de te préciser que j'avais essayé dans mon lan

mon serveur ftp n'est pas configuré pour ssl (à ma connaissance)

> je ne sais pas à quoi correspond ce dossier (je débute avec mon Syno ;-)

je suppute un répertoire programmé par défaut dans filezilla si mal configuré, mais j'ai pas travaillé la question.

pour mon usage avec le syno, winscp correspond mieux à mes besoins

(edition du fichier distant directement dans mon éditeur et upload auto quand sauvegarde, je suis pas prêt de maitriser vi avec ça;)

[guig]

pas simple ton truc. tu es bien en passif ?

eh oui, justement, mais ça ne change rien coté client ... actif ou passif, même résultat !

j'ai oublié de te préciser que j'avais essayé dans mon lan

mon serveur ftp n'est pas configuré pour ssl (à ma connaissance)

l'accès en SSL ne pose pas de problème ... mais uniquement sur le LAN ... enfin, chez moi, à partir d'une adresse WAN, ça plante ... :-(

pour mon usage avec le syno, winscp correspond mieux à mes besoins

(edition du fichier distant directement dans mon éditeur et upload auto quand sauvegarde, je suis pas prêt de maitriser vi avec ça;))

sur tes conseils, j'ai testé winscp, c'est bien, mais j'obtiens les mêmes résultats ... du coup, je commence à me demander si SSH est supporté sur FTP ?!

y'a plus qu'à continuer à chercher ;-))

[Tof]

sur tes conseils, j'ai testé winscp, c'est bien, mais j'obtiens les mêmes résultats ... du coup, je commence à me demander si SSH est supporté sur FTP ?!

à deux, on va peut-être y arriver...

j'ai installé openssh, rien fais de particulier pour winscp. ça a marché de suite, lan ou wan.

pour le wan, c'est le port 22 à ouvrir. le ftp n'intervient pas, c'est sftp qui est utilisé (secure ftp qui fait partie de ssh) et non ftps (ftp over ssl).

sauf pour essais, je n'ai pas de ftp.

[guig]

J'ai installé openssh ... effectivement, ça fonctionne nettement mieux ;-)

seul détail : je tombe directement sur un dossier racine plutôt que l'arborescence du syno; ceci dit, c'est pas gênant outre mesure puisque j'accède à tout le reste.

maintenant, je me pose la question de l'intérêt de ssh par rapport à SSL ... est-il vraiment plus sécurisé ?

désolé si mes questions paraissent idiotes, mais je débute dans le domaine !

par curiosité, je cherche aussi un genre d'interface style web toute faite pour accéder aux contenus des différents éléments présents sur le syno, genre phtostation, mais qui permette de voir l'ensemble des données ... tu connais qq. chose qui ressemblerait à ça ?

sachant que la gestion de site web, c'est pas trop ma tasse de thé ? ;-)

en tout cas, merci pour ton coup de main !

[Tof]

> seul détail : je tombe directement sur un dossier racine plutôt que l'arborescence du syno;

regarde dans ton fichier /etc/password, tu dois avoir ou sinon corriger :

root:x:0:0:root:/root:/bin/ash

de mémoire admin (l'utilisateur par défaut) est foireux dans ce fichier, le corriger, genre:

admin:x:1024:100:System default user:/volume1/home/admin:/bin/bash

/volume1/home/... sont des répertoires à créer pour les autres utilisateurs

/bin/bash, à l'origine, il y avait /bin/csh je crois

> maintenant, je me pose la question de l'intérêt de ssh par rapport à SSL ...

dans SSH, il y a la partie sécurité ET le transfert de fichier ET le transfert de port (tunneling)

dans ssl, ce n'est que la partie cryptage devant package dans les applis (serveur web, ftp, vpn...) c'est bien aussi, mais pas clé en main.

> est-il vraiment plus sécurisé ?

oui, si ton pass l'est ou mieux si tu utilises des clés rsa ou dsa > 1028bits (pas encore cassée à ce jour)

voir ici pour t'aider Utilisation de openSSH pour l'accès distant

> désolé si mes questions paraissent idiotes, mais je débute dans le domaine !

nous sommes deux, je débute sous nunux

> genre phtostation, mais qui permette de voir l'ensemble des données ... tu connais qq. chose qui ressemblerait à ça ?

photostation tourne sous le compte root (partie synoman apache système)

sous la partie web, qui tourne sous admin (utilisateur) il y aura moins de possibilité

il est possible (relativement) facilement de modifier des fichiers de conf dans /usr/syno/synoman pour ajouter (ou supprimer) des menus dans la console et exécuter des scripts en conséquence. mais c'est modifier des parties qui ne devrait pas être accessible à l'utilisateur courant

> sachant que la gestion de site web,

pour dépanner qqu'un je vais reprendre des anciens scripts pour afficher le contenu d'un répertoire, gérer les authorisations d'accès et permettre l'upload.

ça sera frustre mais si j'ai pas trop honte (dans le php, je peine un peu) je te ferai partager

[guig]

>regarde dans ton fichier /etc/password, tu dois avoir ou sinon corriger :

root:x:0:0:root:/root:/bin/ash

de mémoire admin (l'utilisateur par défaut) est foireux dans ce fichier, le corriger, genre:

admin:x:1024:100:System default user:/volume1/home/admin:/bin/bash

/volume1/home/... sont des répertoires à créer pour les autres utilisateurs

/bin/bash, à l'origine, il y avait /bin/csh je crois

j'ai fait tout ça, mais c'est là que tout a commencé à merdouiller ;-)

un coup j'arrivais à me connecter en "admin" avec mon pass ... suite au changement, pas moyen d'y accéder autrement qu'avec le compte root ... du coup, j'ai rebidouillé de le fichier passwd, ça a fonctionné, mais pas l'accès à la bonne racine ... du coup, j'ai rebricolé et là, bah ... a marche pu ! ... et évidemment, j'ai paumé le fichier original ! ... simplet !

bref, je crois que je vais faire un gros ménage ce soir, genre sortir le disque, formater, le remettre dans le syno et repartir de zero ...

euh, pour info, les paquets installés en plus sont stockés où ? parce que, si c'est dans le système sur la carte, ça sert à rien que je m'excite à tout reformater ?!

>dans SSH, il y a la partie sécurité ET le transfert de fichier ET le transfert de port (tunneling)

dans ssl, ce n'est que la partie cryptage devant package dans les applis (serveur web, ftp, vpn...) c'est bien aussi, mais pas clé en main.

ok ... merci pour l'info, je comprends mieux !

>... si tu utilises des clés rsa ou dsa > 1028bits (pas encore cassée à ce jour)

à ce propos, au moment où tu généres tes clés avec la commande "ssh-keygen", cette manip doit elle être faite pour chaque compte ou bien est-elle valable pour l'ensemble des accès, quelque soit le login ?

dans le cas contraire, faut-il créer les users sous telnet ou bien l'accès est-il ok pour les users déjà configurés dans le syno via l'interface web ? (je sais pas si je me fais bien comprendre, là ? ;-) )

> nous sommes deux, je débute sous nunux

eh bah, ça promet d'allonger le topic ... ;-)

> pour dépanner qqu'un je vais reprendre des anciens scripts pour afficher le contenu d'un répertoire, gérer les authorisations d'accès et permettre l'upload.

ça sera frustre mais si j'ai pas trop honte (dans le php, je peine un peu) je te ferai partager

sympa ! ça m'intéresse !

[Tof]

> j'ai fait tout ça, mais c'est là que tout a commencé à merdouiller ;-)

attention à l'éditeur que tu utilises, notamment au niveau des fins de lignes (différence entre win et unix) mais suis pas sûr que ça puisse être ton problème

perso c'est pspad (beaucoup beaucoup de fonctionnalités, donc un peu d'abord) sans soucis

pour info le passwd:

root:x:0:0:root:/root:/bin/ash

	   lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin

	   ftp:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin

	   anonymous:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin

	   smmsp:x:25:25:Sendmail Submission User:/var/spool/clientmqueue:/sbin/nologin

	   nobody:x:1023:1023:nobody:/home:/sbin/nologin

	   admin:x:1024:100:System default user:/volume1/home/admin:/bin/bash

	   guest:x:1025:100:Guest:/nonexist:/bin/sh

pour info les mots de pass sont stockés cryptés, à côté, dans un fichier shadow. le tout dans le répertoire /etc autre info, un fichier important à sauvegarder, c'est /etc/synoinfo.conf si problème la console d'administration ne marche plus, mais le syno lui oui. suffit de recharger le fichier. > un coup j'arrivais à me connecter en "admin" avec mon pass pour les pass, c'est presque un sytème de protection original ) voir Mot de passe root > je crois que je vais faire un gros ménage ce soir, genre sortir le disque, formater, le remettre dans le syno et repartir de zero ... n'oublies pas que tu n'est plus sous windows a priori ton pb n'est pas grave, en telnet tu peux récupérer aussi si pb ssh

telnet: root/PassUtilisateurParDéfaut ssh: root/synopass

valable si tu n'as pas modifié les pass biensûr > les paquets installés en plus sont stockés où ? /opt qui est lié à /volume1/opt (partition 3) > si c'est dans le système sur la carte, ça sert à rien que je m'excite à tout reformater ?! le firmware (linux sans options optware) est en flash (pour le démarrage mini j'imagine) et l'install se fait sur la partition 1 montée en / théoriquement (pas encore essayé attention) suffit de reformater la partition 1 (mke2fs -j /dev/hda2) et de relancer l'assistant synology >>... si tu utilises des clés... j'utilise PuTTY Gen, 2048 bits perso, c'est une clé par utilisateur, et j'ajoute la clé publique à la main pour chaque, chacune dans un compte /volume1/home/user/.ssh/authorized_keys je réussis pas à centraliser toutes les clés dans /root/.ssh/authorized_keys, je sais pas pourquoi, je verrais plus tard mais on peut imaginer que les utilisateurs ont une clés communes. dans ce cas compromission facilitée mais surtout, le root doit en avoir une unique car tous les droits sont possibles sous ce compte. je n'utilises pas telnet, mais je le garde sous le coude si je merde quand j'interviens sur le serveur ssh je sais pas si je t'ai bien compris, là ? ;-) ) > faut-il créer les users sous ... voilà un morceau de script que j'utilise

adduser -h /volume1/home/Login -G users -s /bin/ash Login  

	   # ajout user Login et création repertoire home

	   #-h répertoire home 

	   #-G groupe 

	   #-s shell au démarrage 

	   chown Login /volume1/home/Login			  #changement de proprio du repertoire home/user

	   mkdir /volume1/home/Login/.ssh									#création du répertoire ssh

	   chmod 700 /volume1/home/Login/.ssh								#changement de masque du répertoire ssh

	   chown Login /volume1/home/Login/.ssh								#changement de proprio du répertoire ssh

	   touch /volume1/home/Login/.ssh/authorized_keys					#création de authorized_keys

	   chown Login /volume1/home/Login/.ssh/authorized_keys				#changement de proprio de authorized_keys

	   chmod 400 /volume1/home/Login/.ssh/authorized_keys				#changement de masque de authorized_keys

	   /usr/syno/cfgen/s30_synocheckuser					#test synology user

	   /usr/syno/cfgen/s42_synocheckgrp					#test synology user

y' surement mieux à faire, mais je débute avec les scripts sh

bien si tu scriptes, faut passer les paramètres en lignes de commandes dans des variables, j'ai mis ça ici pour que ceux que ça intéresse puissent utiliser

> sympa ! ça m'intéresse !

noté, pour l'instant je négocie les fonctionnalites de base avec mon utilisateur beta testeur et je vous tiens informés.

<teasing>

l'idée de base est de permettre le partage et la modification de documents dans des projets avec des permissions adéquates d'accès, sur des répertoire web, sans toucher à la configuration de l'utilisateur et en facilitant la vie à l'administrateur qui n'a pas du tout envie de se pencher sur l'utilisation de vi.

l'upload sera lui aussi géré pour les utilisateurs.

je fais ça rapidement pour dépanner en assemblant des vieux bouts de scripts.

après si qqu'un à le niveau et le temps pour améliorer, je lui laisse la main.

</teasing>

[guig]

oki !

je vais voir tout ça de près dès que j'aurai un peu plus de temps ...

pour ce qui est du fait de ne plus être sous windows, ça, c'est sûr, mais disons que j'ai fait une tonne de manip hier et maitenant que j'ai des infos plus claires, j'aimerai faire ça proprement en repartant sur une base clean !

ensuite, réinstall du bootstrap et enfin openssh.

je verrai après pour l'ajout des users/pass et génération des clés ...

à ce propos, pour le moment, les histoires de scripts et de variables, c'est un peu du chinois pour moi ... disons que je comprends le principe, mais dans la pratique, j'ai encore du boulot (je ne sais ni élaborer, ni même executer un script sous Linux alors tu vois le niveau ;-)

pour l'aspect génération des clés, c'est ok ... il faut juste que je regarde comment ça fonctionne ... et d'abord créer mes users ...

si je comprends bien, les users du syno ne sont pas forcément les users SSH, et ces derniers sont gérés sur le serveur SSH lui-même ?

pour résumer, on pourrait schématiser un accès sftp comme ça :

client sftp ---> login serveur SSH --> cryptage --> install. du certificat --> login ftp syno --> accès données

euh, j'ai bon là ? ou carrément tout faux ?

désolé d'être un peu envahissant ...

[Tof]

> si je comprends bien, les users du syno ne sont pas forcément les users SSH,

non non, c'est les mêmes, mais par la console d'administration du syno, tu règles moins de choses

ssh utilise les infos système

y'a qu'en telnet où y'a une 'plaisanterie' qui mélange le pass admin avec le compte du root

> et ces derniers sont gérés sur le serveur SSH lui-même ?

non, par le système.

ssh se charge de gérer l'authentification en vérifiant avec les données système concernant l'utilisateur

> client sftp ---> login serveur SSH --> cryptage --> install. du certificat --> login ftp syno --> accès données

> j'ai bon là ?

pas sûr. je dirais (mais j'approche de la limite de mes compétences)

client ssh->authentification du serveur (le client accepte ou non la clé serveur) ET authentification sur serveur ssh (par pass ou clés publique/privée)->accès système

tout est chiffré dès le départ

accès système : terminal (genre console) pour exécution de commandes ou client graphique (avec utilisation de sftp-server et winscp par exemple) pour listage/copie

sftp est un protocole différent de ftp, à priori, notamment parce que tout est chiffré.

les accès sftp se font sans démarrage obligatoire du serveur ftp.

[operron]

> client sftp ---> login serveur SSH --> cryptage --> install. du certificat --> login ftp syno --> accès données

> j'ai bon là ?

pas sûr. je dirais (mais j'approche de la limite de mes compétences)

client ssh->authentification du serveur (le client accepte ou non la clé serveur) ET authentification sur serveur ssh (par pass ou clés publique/privée)->accès système

tout est chiffré dès le départ

accès système : terminal (genre console) pour exécution de commandes ou client graphique (avec utilisation de sftp-server et winscp par exemple) pour listage/copie

sftp est un protocole différent de ftp, à priori, notamment parce que tout est chiffré.

les accès sftp se font sans démarrage obligatoire du serveur ftp.

sftp et scp sont 2 "sous protocoles" de ssh, et donc totalement idépendant de ftp (et donc du serveur ftp du syno).

C'est donc le serveur ssh qui gère et sert les requêtes sftp ou scp.

On peut se servir de scp/sftp soit avec un client graphique comme l'excellent winscp ou par les clients en ligne de commande scp, sftp de openssh ou dropbear ou encore pscp et psftp de putty pour les windowsiens.

[guig]

Merci à Vous pour toutes ces infos !

Maintenant, j'y vois plus clair ... ne baignant pas du tout dans le Linux, je découvre ...

Encore une question (eh oui ...) : la méthode d'échange de clés semble, selon le lien que Tof m'a donné, plus efficace en terme de sécurité que le couple user/pass ?

dans ce cas, comment choisir et paramétrer correctement le serveur ssh pour utiliser l'une ou l'autre méthode ?

y'a t'il un moyen, ou est-il conseillé de coupler les deux méthodes ?

derniere chose : est-il impératif d'installer openssh sur le syno pour y accéder via winscp ?

parce que, pour le moment ... accès refusé avec le couple user/pass ?!

euh, si je vous saoule, faut le dire, hein ?!

merci pour votre patience

[Tof]

> plus efficace en terme de sécurité que le couple user/pass ?

c'est différent...

s'il est faible, le pass ne résiste pas bien longtemps à une attaque. S'il est dur, on l'oublie.

les clés sont plus sûres dans le sens où l'on ne dépend pas de la faiblesse d'un pass (que les utilisateurs ont aussi beaucoup de mal à supporter).

si on perd la clé privée, on en change. faut pas la perde c'est tout.

c'est bien de protéger la clé privé (par un pass faible ou moyen, généralement suffisant)

c'est aussi plus simple à gérer, à mon goût. mais c'est aussi une histoire d'environnement, hostile ou non. le net l'est.

> dans ce cas, comment choisir et paramétrer correctement le serveur ssh pour utiliser l'une ou l'autre méthode ?

1.3 Configuration du serveur OpenSSH pour un accès par clé publique

> est-il conseillé de coupler les deux méthodes ?

non, plutôt déconseillé de garder le pass, considéré plus faible. si on installe des clés, on désactive l'authentification par pass (une histoire de maillon faible)

> est-il impératif d'installer openssh sur le syno pour y accéder via winscp ?

oui, winscp ne travaille qu'en sftp ou scp (pas en ftp).

> accès refusé avec le couple user/pass ?!

encore une erreur de manip j'imagine