Outils pour utilisateurs

Outils du site


Accès ssh/sftp

Le but est de fournir un moyen simple de faire des échanges de fichiers dans les deux directions.

D'abord, expliquons un peu pourquoi on disqualifie d'autres solutions, notamment rsync et syncthing.

rsync

A priori, rsync ça pourrait le faire. On peut envoyer et recevoir.

Le soucis, c'est d'avoir un front-end simple à utiliser. Pas sûr qu'il y ait un front-end un peu moderne (grsync…).

En terme de besoin, il faut que ce front-end liste tous les fichiers, et pas uniquement des répertoires pré-définis. Plutôt qu'une arborescence, les outils rsync ont tendance à s'en tenir à des répertoires “source” et “destination” prédéfinis.

L'idéal, c'est plutôt qu'on nous présente l'arborescence complète des fichiers, et que je puisse sélectionner au peigne fin les répertoires/fichiers que je souhaite récupérer/envoyer, comme un midnight commander, ou un filezilla.

syncthing

syncthing correspond à un cas d'usage que je trouve un peu particulier. Il s'agit vraiment de synchronisation complète entre plusieurs utilisateurs.

Cela signifie que les utilisateurs peuvent difficilement choisir quels fichiers les intéressent/ne les intéressent pas.

J'imagine syncthing utile pour faire un développement collaboratif, ou bien peut-être pour faire transiter ses fichiers de config/profils d'utilisateur de logiciels, mais pas pour “faire ses courses” et télécharger de gros fichiers.

La synchronisation s'effectue en effet sur *tout* le répertoire. Il est possible d'ignorer certains fichiers, mais il faut écrire les patterns dans un fichier de config à la main.

Un avantage de syncthing, c'est que la synchro se fait automatiquement, et dès que possible (donc dès qu'un hôte est en ligne). On n'a donc pas besoin d'aller vérifier si de nouveaux fichiers sont disponibles : il nous prévient.

Le carton rouge, c'est donc qu'il n'y a pas de contrôle fin des fichiers que l'on souhaite rapatrier.

Semble aussi que y'ait 2 modes de synchro : émission/réception, ou seulement émission (ce qui devrait impliquer “uniquement réception” à l'autre bout). Mais je n'ai pas trouvé ça très clair.

Lecteurs virtuels, dérivés de sshfs

Il existe par expl ce truc : https://github.com/billziss-gh/winfsp

Le fait que la description insiste sur “développe ton FS” est peu rassurant.

Ca peut servir pour du partage public si on met un site web genre https://larsjung.de/h5ai/ derrière.

Par contre, il faut l'installer sur tous les postes (ça semble logique) si on veut que ça marche dans les 2 sens. Mais dans ce cas, si ce n'est que pour soi et ballader des fichiers d'un poste à l'autre, autant utiliser une clé USB.

Winfsp + sshfs

Ca fonctionne, mais parfois ça mouline un peu et c'est peu réactif.

Login + modp Vs. Clé publique SSH

De base le mode d'authentification c'est login+mdp.

Mais semblerait que d'autres aient repéré le filon, aient essayé avec des “agents ssh” (en expliquant que l'auth par clés, c'est quand meme mieux), et ce remuage est assez récent (courant 2017).

On essayera en générant une clé SSH depuis une autre poste (ssh-keygen étant absent).

Sans succès, je me prends un “reset by peer”. Voir les issues pour : https://github.com/billziss-gh/sshfs-win

D'après Issue#1, j'ai essayé celle en ligne de commandes avec le PATH, etc, sans agent. Mais je n'ai pas checké la proposition du Issue#15.

Répertoire d'origine

La connexion n'aboutit pas si j'indique un répertoire d'origine.

\\sshfs\user@domaine!12345
\\sshfs\user@domaine!12345\\var\www\fichiers\

umask

Les droits sont en 0700, c'est chiant, l'umask du profil n'est pas pris en compte.

Voir aussi cette discussion : https://github.com/billziss-gh/sshfs-win/issues/14

Relou, utiliser inotify pour contourner le problème ?

rssh

Alors rssh est un shell restreint. Mais le projet n'est plus très maintenu, et ça semble bizarre.

openssh est déjà fourni avec certaines solutions pour “chrooter” un utilisateur dans son /home/$USER, et le cantonner à un accès sftp.

Ça fonctionne, mais je me rend compte que finalement, si, j'ai aussi besoin d'accéder aux autres fonctions du shell. Il y a des solutions à base de bash-static, et donc peut-être de rssh. Mais ça m'inspire pas trop.

Donc je vais renoncer au chroot.

Pour mettre en place un accès sftp-only, voir: https://debian-facile.org/doc:reseau:ssh:tp-sftp-via-openssh-server

Solution retenue

Donc finalement, on s'en tient à du ssh classique, qui fournit un accès sftp configurable dans filezilla.

Authentification par mot de passe ou par fichier de clé ?

Tant qu'à faire, j'aimerais éviter l'authentification par mot de passe.

Filezilla requiert un fichier au format PPK ou PEM. Détails : https://wiki.filezilla-project.org/Howto

Sous Windows, putty et puttygen semblent pouvoir générer un fichier PPK ou PEM qui sera accepté par filezilla.

Sous Linux, on se repose sur authorized_keys et la génération classique de clés SSH.

Pour le test, voyons si on peut convertir un id_rsa.pub en fichier de clé PEM.

Et apparemment, ça, ça le fait :

ssh-keygen -e -m PEM -f id_rsa.pub

Pourquoi un chroot ?

Peut-être qu'on peut se passer d'un chroot…

Ce qui est gênant, c'est surtout que par défaut, tous les dossiers/fichiers ont des droits r_x pour “others”. Donc, pour éviter que d'autres puissent se ballader dans l'arborescence de mes fichiers perso, il suffit de régler les droits de quelques répertoires situés à la base. Typiquement, penser à ceux dans /home, et dans /mnt.

Un petit…

chmod 700 /sur /ces /répertoires

… et c'est réglé.

article/linux/mplx/synchronisation-fichiers.txt · Dernière modification: 2018/01/13 00:36 par fab