Journal SSHFS est un vrai système de fichiers en réseau

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
25
28
août
2015

Cher journal,

Comme tu dois le savoir, il y a (au moins) deux façons générales d'accéder à des fichiers à distance :

  • les protocoles de transfert de fichiers, tels que FTP ou HTTP ;
  • les systèmes de fichier en réseau, tels que SMB/CIFS et NFS.

La différence, c'est qu'un protocole de transfert sert… à transférer des fichiers, évidemment, tandis qu'un système de fichiers en réseau permettra des choses comme l'ouverture de fichiers, la lecture à une position arbitraire, l'écriture (sans tout envoyer), le renommage ou encore le verrouillage. Certains protocoles de transfert disposent de telles fonctionnalité, mais rarement de façon complète.

Sur SSH, on peut manipuler des fichiers :

  • par SCP, qui à ce qu'il me semble, transfère des fichiers en lançant par SSH des commandes telles que cat ;
  • par SFTP, un protocole spécifiquement développé pour SSH, dont il constitue un module.

Le nom SFTP laisse penser qu'il s'agit d'un protocole de transfert de fichiers, mais je viens de me rendre compte qu'il n'en était rien : ce protocole a été conçu pour pouvoir être utilisé aussi bien pour les transfert de fichiers, typiquement, avec un logiciel client comme sftp, avec lequel on fait des choses comme get et put, ou pour servir de système de fichiers en réseau, typiquement pour effectuer un montage avec un pilote comme sshfs.

Par conséquent, si vous êtes amenés à chercher un moyen d'accéder à vos fichiers en réseau local, autrement qu'en les transférant de machine en machine, ne vous laissez pas tromper par le nom d'sshfs et surtout du protocole SFTP qu'il utilise, vous pouvez le considérer comme une option sérieuse, au même titre que NFS ou CIFS !

  • # Oui

    Posté par  . Évalué à 8.

    Je l'utilise quotidiennement, c'est juste un peu chiant si on n'a pas le même UID sur les deux machines…

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Oui

      Posté par  . Évalué à 7.

      C'est pas propre à sshfs. Ca peut être rigolo avec NFS et CIFS aussi.

    • [^] # Re: Oui

      Posté par  (site web personnel) . Évalué à 2.

      Je l'utilise au quotidien aussi : une "VM" de développement par projet client (généralement des conteneurs LXC, mais pas que), et l'éditeur/IDE sur l'hôte qui va taper sur les systèmes de fichiers distants montés via SSHFS.

      Quelques problèmes avec les UID (ex : la manipulation de dépôts Mercurial ne fonctionne pas de base via SSHFS si les UID diverges, ça se contourne), et des performances pas terribles sur certaines opérations (hg/git clone, merge importants… à faire de préférence directement sur le système de fichiers cible et non via le montage). Cela fait plusieurs années que l'on travaille ainsi à mon taf, et on est plutôt satisfaits dans l'ensemble.

      Est-ce qu'il y aurait d'autres façons d'avoir ses outils de devs communs à plusieurs environnements de développement ?

      • [^] # Re: Oui

        Posté par  . Évalué à 3.

        Si tu lances tes conteneurs LXC en mode super-utilisateur (en root, quoi), tu peux partager des morceaux de système de fichier avec le système hôte. Il faut utiliser l'option lxc.mount.entry dans le fichier de config de ton conteneur.

    • [^] # Re: Oui

      Posté par  (site web personnel) . Évalué à 4.

      Apparemment on peut traduire les UIDS de façon transparente.

    • [^] # Re: Oui

      Posté par  (site web personnel) . Évalué à 10.

      Et c'est trèèès lent, malgré une excellente connexion internet entre les deux machines.
      Faire un find ou un grep sur un volume monté en sshfs est une erreur que j'évite de faire…

      Pour le reste cela fonctionne très bien.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Oui

        Posté par  (site web personnel) . Évalué à 3.

        Faire un find ou un grep sur un volume monté en sshfs

        C'est vrai que pour ce genre d'opération il vaut mieux utiliser directement le SSH.
        Idem pour rsync (sur de gros répertoires) il vaut mieux le faire en réseau plutôt que sur un volume monté en sshfs.

        Mais pour éditer des fichiers distants ou faire des simples copier coller c'est très pratique et puissant.

        kentoc'h mervel eget bezan saotred

        • [^] # Re: Oui

          Posté par  (site web personnel) . Évalué à 5.

          Mais pour éditer des fichiers distants ou faire des simples copier coller c'est très pratique et puissant.

          Alors je dirais que ça dépend. Utiliser un emacs avec des systèmes du genre ctags/gtags via une partoche montée en sshfs et sur de gros projets est une vraie boucherie, c'est quasiment inutilisable chez moi, même avec une VM qui tourne en local.

          Mais bon, c'est quand même un truc assez spécifique donc je suis d'accord qu'en général, l'édition via sshfs se passe bien.

          • [^] # Re: Oui

            Posté par  (site web personnel) . Évalué à 2.

            Utiliser un emacs avec des systèmes du genre ctags/gtags via une partoche montée en sshfs

            Petite question : as tu essayé en montant la partition avec NFS ? si oui quelles sont les performances ?

            kentoc'h mervel eget bezan saotred

          • [^] # Re: Oui

            Posté par  (site web personnel) . Évalué à 1.

            Bon en même temps, quand emacs est déjà dans le tableau, ne pas utiliser TRAMP pour l'édition à travers SSH, c'est dommage: TRAMP a le bon goût de lancer les processus directement côté serveur, du coup pas de pénalité particulière sur tout ce qui est ctags/make/git/… (petit bémol, il faut pouvoir travailler exclusivement avec des chemins relatifs, tout ce qui est absolu pose évidemment un problème de traduction dans la couche TRAMP)

    • [^] # Re: Oui

      Posté par  (site web personnel) . Évalué à 4.

      Je l'utilise quotidiennement

      Moi aussi et c'est génial.

      Sinon une erreur que je rencontre souvent :
      Ne pas confondre SFTP avec SFTP ou encore FTPS

      kentoc'h mervel eget bezan saotred

    • [^] # Re: Oui

      Posté par  . Évalué à 3.

      J'ai commencé à mettre ça en place au boulot, et je ne m'attend(ai)s pas à avoir de problèmes d'UID.

      J'ai un serveur sur lequel on va bosser à plusieurs, et donc plusieurs utilisateurs ont accès rwx à un répertoire.

      Je pensais le monter localement sur ma machine avec sshfs pour pouvoir travailler dessus graphiquement plutôt que me limiter à vi dans un terminal.

      Dois-je m'attendre à des problèmes ?

      A quels problèmes fais-tu référence avec les UID ?

      • [^] # Re: Oui

        Posté par  . Évalué à 3.

        Il est fort probable que tu n'auras aucun problèmes sérieux.
        En pratique tu auras les mêmes droits d'accès aux fichiers que le compte utilisé pour la connection ssh.

        Par défaut, les uid et gid des fichiers seront préservés mais ils ne seront pas utilisés pour déterminer les droits d'accès.

        En pratique, cela signifie que si l'uid de ton utilisateur ssh est 1005 sur le serveur alors les fichiers sembleront appartenir à l'utilisateur 1005 sur le client.

        Certains programmes qui testent les UID & GID des fichiers avant d'y accéder peuvent être perturbés mais c'est assez rare.

        • [^] # Re: Oui

          Posté par  . Évalué à 2.

          Merci.

          Une recherche rapide m'a amené à cette page qui donne quelques détails.

    • [^] # Re: Oui

      Posté par  . Évalué à 3.

      sshfs propose plusieurs possibilités pour traduire les user/group.

      Voir les options -o idmap, uidfile, gidfile, nomap=ignore, uid et gid

  • # Et si vous êtes fainéant : Xsshfs

    Posté par  (site web personnel) . Évalué à 5.

    Petite interface pour sshfs en Perl/GTK/glade :

    • [^] # Re: Et si vous êtes fainéant : Xsshfs

      Posté par  (site web personnel) . Évalué à 3.

      Petite annonce : je cherche un contributeur pour mettre Xsshfs dans les dépôts Debian.

    • [^] # Re: Et si vous êtes fainéant : Xsshfs

      Posté par  . Évalué à 3.

      Si on est fainéant, on peut aussi utiliser dans KDE l'accès à un autre serveur avec la commande fish:// ou sftp:// dans le gestionnaire de fichiers (dolphin) : http://www.binarytides.com/ssh-dolphin-konqueror-kde/

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

    • [^] # Re: Et si vous êtes fainéant : Xsshfs

      Posté par  (site web personnel) . Évalué à 1.

      Alors merci pour ton travail, c'est pas mal du tout !

      J'ai constaté les petits soucis suivants avec la version 0.6 packagée en RPM :
      - les demandes interactives (clé, mot de passe…) se font dans le terminal d'où xsshfs a été lancé, c'est peu intuitif et surtout on ne voit rien si le raccourci .desktop a été utilisé pour le lancer… Y aurait-il moyen d'afficher ça en GUI ?
      - ce serait bien d'avoir une confirmation de type "Succès !" si le montage s'est bien effectué ;
      - le bouton "Fermer" de la fenêtre "A propos" est inactif ; on peut fermer avec la croix, mais après la fenêtre ne réapparaît plus.

      • [^] # Re: Et si vous êtes fainéant : Xsshfs

        Posté par  (site web personnel) . Évalué à 1.

        • Pour le 1er point : est-ce que c'est pas dû au fait que tu lance Xsshfs dans le terminal ? Normalement le package installe une dépendance (ssh-askpass) qui t'affiche un prompte pour le mot de passe mais celui-ci ne se lance que si tu lance le logiciel hors terminal
        • Oui pourquoi pas
        • Effectivement c'est un petit bug que je n'arrive pas trop à résoudre mais que je ne trouve pas "bloquant" donc bon bon…

        Merci pour ces retours en tout cas.

  • # Résilience

    Posté par  (site web personnel) . Évalué à 8.

    À la maison j'utilise NFS pour partager certains systèmes de fichiers. En dépit de certaines limitations (les verrous, de mémoire) ce système a un atout de taille: sa très grande résilience.

    Par exemple si je mets le client en veille ou éteint le serveur pendant quelques heures, le système continue de fonctionner correctement, c'est à dire que si je m'abstiens de consulter les fichiers distants pendant que le serveur est éteint, puis rallume celui-ci, les fichiers distants sont toujours accessibles lorsque le serveur revient en ligne. Pour un réseau domestique, c'est une propriété très sympa.

    Qu'en est-il avec sshfs?

    • [^] # Re: Résilience

      Posté par  (site web personnel) . Évalué à 4.

      Ça fonctionne très bien (chez moi en tout cas). Il m'ait même arrivé de remarquer, plusieurs jours après l'avoir utilisé (donc après de nombreuses mise en veilles, déconnexions, etc…) que le montage était toujours là, et fonctionnel.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Résilience

        Posté par  (Mastodon) . Évalué à 6.

        SSHFS ne survit pas très bien à une coupure active longue de la connexion, c'est à dire si une des deux machines est active et l'autre en veille par exemple.
        Je crois que si les deux sont en veille ça va revenir sans soucis en rallumant les deux.

        Mais en bref, ça survit exactement aussi bien aux aléas de connexion qu'une connexion SSH classique. Puisque c'en est une en dessous.

        En comparaison, NFS sur le client ne se déconnecte pas tout seul, et les processus qui cherchent à accéder à la ressource NFS inaccessible vont être mis en attente par le système, selon comment le logiciel est écrit, ça peut le freezer sans espoir de rédemption (kill -9 est inutile). Mais tout repart comme si de rien n'était dès que la connexion NFS revient. Et la connexion NFS se recrée toute seule dès que le serveur redevient accessible.

        Il est possible (mais j'ai des résultats mitigés à ce sujet) de flinguer une connexion bloquée (connexion NFS active mais vers un serveur devenu indisponible) en tuant le démon RPC.
        À comparer : si ta connexion SSHFS est dans les choux, tu as le processus SSH à tuer et ça coupe la connexion proprement, les logiciels qui essayaient d'accéder aux données reprennent leur cours normalement avec une erreur d'entrée/sortie normale.

        Côté performance, même en réseau local je préfère utiliser le NFS, de loin, pour transférer des gros fichiers ou lire une vidéo depuis une autre machine : bien plus rapide.
        Mais le NFS est à la limite de l'inutilisable sur internet (de mon expérience uniquement) alors que SSHFS s'en sort bien mieux, et est plus facile à gérer en cas de soucis de connexion.

        Autre point notable, il n'y a rien à installer ou configurer sur le serveur pour faire fonctionner SSHFS, et aucun droits d'administration, juste un compte utilisateur. Il faut bien sûr avoir le serveur SSH actif, ce qui est facilement le cas. Tandis que pour le NFS il faut accéder au serveur en ROOT, configurer le fichier /etc/exports, relancer le démon NFS, blablabla…

        Bref, pas les mêmes usages, et très complémentaires !
        J'utilise fortement les deux dans un même environnement.

        Yth.

        • [^] # Re: Résilience

          Posté par  (site web personnel) . Évalué à 5.

          selon comment le logiciel est écrit

          Voir les options de montage NFS hard/soft et intr.

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: Résilience

            Posté par  (Mastodon) . Évalué à 3.

            Ça aussi, j'aurais dû dire que NFS se paramètre, et qu'on peut changer son comportement par défaut dans ces situations, merci !

            Yth.

  • # Ca fait de l'accès de fichier...

    Posté par  (site web personnel) . Évalué à 0.

    ne vous laissez pas tromper par le nom d'sshfs et surtout du protocole SFTP qu'il utilise

    Pourquoi tromper?
    C'est du réseau, c'est du transfert de fichier.
    On peut faire du "FTPFS", ou du "HTTPFS" aussi si on a envie, c'est pareil (on peut faire de tout, "xxxFS" tant qu'on peut transférer des données, le reste genre les UID ou les locks c'est plus ou moins optionnel et au pire on fait une extension non standard si personne d'autre y a pensé avant).
    Pour info, on peut même faire du S3FS, avec des possibilité de gestion de droit et tout et tout bref rien de neuf.

    Donc aucune tromperie.

    J'avoue qu'à lire "un vrai", je m'attendais à un comparatif genre un comparatif de perfs entre SSHFS et CIFS et NFS et pourquoi pas un FS sur FTPS, ou au minimum une liste de ce qui est possible (UID, lock… Je peux aussi bien vivre avec un FS qui ne gère pas les UID et lock, ce n'est pas obligatoire pour s'appeler FS) ou pas par rapport à d'autre.

    Finalement, la question est sans doute : pour toi (c'est très subjectif…), c'est quoi un "vrai FS"?

    • [^] # Re: Ca fait de l'accès de fichier...

      Posté par  . Évalué à 9.

      C'est du réseau, c'est du transfert de fichier.

      Non de ce qu'il dit (j'ai pas vérifié) tu peux envoyer des commandes (déplace le curseur à tel position, écris tels octets,…). Ce qui n'est pas du transfert de fichier (il le fait aussi très bien aussi).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Ca fait de l'accès de fichier...

      Posté par  (site web personnel) . Évalué à 9.

      On peut faire du "FTPFS", ou du "HTTPFS" aussi si on a envie, c'est pareil

      Ben non justement. Des pilotes de système de fichier par FTP ou HTTP émuleront certains trucs, genre à retransférer un fichier entier pour une simplement modification à l'intérieur, ces protocoles n'étant pas faits pour cela et ne fournissant vraiment pas tout ce qu'il faut pour les appels systèmes liés à la manipulation de fichiers.

      Finalement, la question est sans doute : pour toi (c'est très subjectif…), c'est quoi un "vrai FS"?

      Un truc qui fournit de quoi open(), write() read() lseek() et ce genre de truc.

      • [^] # Re: Ca fait de l'accès de fichier...

        Posté par  (site web personnel) . Évalué à -5.

        genre à retransférer un fichier entier pour une simplement modification à l'intérieur

        exemple avec FTP : possible en lecture. Si on veut faire en écriture, ok il faut faire une commande non standard (et encore, j'ai même un doute pour HTTP, un POSt avec un file offset me semble "valide" dans les header, faut juste que ce soit implémenté. Pas la mer à boire.

        Un truc qui fournit de quoi open(), write() read() lseek() et ce genre de truc.

        FTP pouvant faire ça (comme il veut, tu n'as pas explicité) autant que SSH, ça va donc.
        C'est donc bien ce que je disais : pas de différence entre "vrai" et "pas vrai" (les deux demandent de coder une couche intermédiaire à un protocole donné, ce uqi est logique)

        Bref, pas vraiment de révolution, surtout sans bench ou autre élément de différentiation sur les capacité précises (avec bench ou pas)

        • [^] # Re: Ca fait de l'accès de fichier...

          Posté par  . Évalué à 3.

          J'espère que je comprends mal ton propos, car pour faire une analogie avec l'automobile j'ai l'impression que tu nous dis qu'une berline et une voiture de course c'est la même chose, il suffit d'enlever les sièges à l'arrière, changer le moteur et les 4 roues, bref, pas la mer à boire…

  • # Reverse SSHFS

    Posté par  (site web personnel) . Évalué à 7.

    Pour info, il est aussi pratique parfois de pouvoir faire un montage "inversé" (machine locale vers machine distante).

    Du coup, j'avais écrit un petit script, si ça intéresse quelqu'un :
    https://github.com/rom1v/rsshfs

    blog.rom1v.com

  • # astuce sécurité pour les paranoïaques

    Posté par  . Évalué à 0.

    Si tu l'utilise en conjonction avec encfs sur le client, tu auras une solution où le risque pour les données qui quittent ton pc sera nul. Chiffrement local des données avant de les envoyer sur le réseau et protection Man in the middle/interception avec ssh. Probablement ce que l'on fait de mieux en terme de sécurité.

    • [^] # Re: astuce sécurité pour les paranoïaques

      Posté par  (site web personnel) . Évalué à 5.

      Dans le cadre d'un backup chiffré à distance, ça n'a aucun intérêt par contre : le rsync va tout rapatrier en local pour vérifier les données qu'il a besoin d'envoyer.

      Par ailleurs, encfs n'est plus considéré sûr depuis l'année dernière :
      https://en.wikipedia.org/wiki/EncFS#Security

      Debian t'en avertit quand tu l'installes d'ailleurs : 

       ┌────────────────────────┤ Configuration de encfs ├─────────────────────────┐  
 │                                                                           │  
 │ Encfs security information                                                │  
 │                                                                           │  
 │ According to a security audit by Taylor Hornby (Defuse Security), the     │  
 │ current implementation of Encfs is vulnerable or potentially vulnerable   │  
 │ to multiple types of attacks. For example, an attacker with read/write    │  
 │ access to encrypted data might lower the decryption complexity for        │  
 │ subsequently encrypted data without this being noticed by a legitimate    │  
 │ user, or might use timing analysis to deduce information.                 │  
 │                                                                           │  
 │ Until these issues are resolved, encfs should not be considered a safe    │  
 │ home for sensitive data in scenarios where such attacks are possible.     │  
 │                                                                           │  
 │                                  <Ok>                                     │  
 │                                                                           │  
 └───────────────────────────────────────────────────────────────────────────┘

      blog.rom1v.com

      • [^] # Re: astuce sécurité pour les paranoïaques

        Posté par  . Évalué à 2.

        J'envisage à long terme (le jour où j'aurai le temps) de mettre en place des sauvegardes croisées entre mon ordi et celui d'un copain distant (plus robuste qu'un NAS en cas d'incendie).

        Pas vraiment d'enjeu de sécurité, il s'agirait principalement de mes photos persos, peut-être de la musique, et j'ai confiance en le copain distant sus-mentionné, mais pour le principe, ça m'intéresse de savoir comment faire en sorte que ça soit crypté de son côté (qu'il ne puisse pas lire les fichiers).

        Je n'ai pas essayé de chercher comment faire, la paresse me pousse à demander avant de chercher.

        Est-ce possible simplement ?

        Le fait que mes partitions locales ne soient pas encryptées a-t-il une incidence ? Je pense que non, car j'agis au niveau fichier (copie de sous-répertoires de ma partition). Peut-être que si je copiais une partition cryptée dans son intégralité ça serait différent ?

        Je n'ai pas crypté mes partitions à l'installation car j'ai supposé que ça me demanderait un mot de passe supplémentaire à chaque démarrage, ce que je ne souhaitais pas. Peut-être que là aussi je me trompe, mais c'est une autre histoire.

        Notez que mon utilisation indifférente des mots crypté/encrypté traduit un peu mon incompétence, en tout cas ma paresse intellectuelle. En contrepartie, je n'attends pas une réponse détaillée, juste une pointeur vers un tuto pertinent et à jour.

        Merci !

        • [^] # Re: astuce sécurité pour les paranoïaques

          Posté par  (site web personnel) . Évalué à 3.

          Pour des backups incrémentaux chiffrés, je te conseille duplicity.

          Je n'ai pas crypté mes partitions à l'installation car j'ai supposé que ça me demanderait un mot de passe supplémentaire à chaque démarrage

          Si tu es seul utilisateur sur le pc, tu peux chiffrer le disque dur et désactiver la demande du mot de passe au login (tu devras alors uniquement donner la passphrase pour déchiffrer le disque).

          blog.rom1v.com

          • [^] # Re: astuce sécurité pour les paranoïaques

            Posté par  . Évalué à 2.

            Pour des backups incrémentaux chiffrés, je te conseille duplicity.

            Super. Merci pour le tuto que je me bookmarke derrière l'oreille pour plus tard.

            Si tu es seul utilisateur sur le pc, tu peux chiffrer le disque dur et désactiver la demande du mot de passe au login (tu devras alors uniquement donner la passphrase pour déchiffrer le disque).

            Oui, c'est vrai. J'aurais pu faire comme ça. J'ai fait dans l'urgence et mal préparé, et j'ai déjà tenté quelques trucs nouveaux (Raid 5 + LVM), donc j'ai pas souhaité compliquer.

        • [^] # Re: astuce sécurité pour les paranoïaques

          Posté par  (Mastodon) . Évalué à 1.

          Notez que mon utilisation indifférente des mots crypté/encrypté traduit un peu mon incompétence, en tout cas ma paresse intellectuelle. En contrepartie, je n'attends pas une réponse détaillée, juste une pointeur vers un tuto pertinent et à jour.

          Les mots « crypter » et « cryptage » n’existent pas !

      • [^] # Re: astuce sécurité pour les paranoïaques

        Posté par  (site web personnel) . Évalué à 2.

        Dans le cadre d'un backup chiffré à distance, ça n'a aucun intérêt par contre : le rsync va tout rapatrier en local pour vérifier les données qu'il a besoin d'envoyer.

        On n'est pas obligé de faire ses backups avec rsync on peut aussi utiliser des programmes qui marchent bien avec le chiffrement distant. Par exemple dump la commande de sauvegarde de FreeBSD.

        • [^] # Re: astuce sécurité pour les paranoïaques

          Posté par  (site web personnel) . Évalué à 2.

          on peut aussi utiliser des programmes qui marchent bien avec le chiffrement distant. Par exemple dump la commande de sauvegarde de FreeBSD.

          Intéressant. Mais comment ça marche pour du chiffrement distant concrètement?

          blog.rom1v.com

          • [^] # Re: astuce sécurité pour les paranoïaques

            Posté par  (site web personnel) . Évalué à 2.

            Dump n'a pas besoin de rapatrier les données distantes pour faire de la vérification lors des sauvegardes incrémentelles parcequ'il utilise les dates de modification et travaille au niveau du système de fichiers (il suffit donc de se souvenir d'une date par système de fichiers).

            Donc concrètement, tu dumpes, tu vérifies, tu chiffres et tu envoies.

            • [^] # Re: astuce sécurité pour les paranoïaques

              Posté par  (site web personnel) . Évalué à 2.

              Dump n'a pas besoin de rapatrier les données distantes pour faire de la vérification lors des sauvegardes incrémentelles parcequ'il utilise les dates de modification et travaille au niveau du système de fichiers (il suffit donc de se souvenir d'une date par système de fichiers).

              C’est le fonctionnement par défaut de rsync qui utilise la date de modification et la taille pour savoir si un fichier a changé.

              Si la date ou la taille ne sont pas un critère fiable dans ton contexte, tu peux utiliser l’option --checksum de rsync et là oui, la comparaison avec un système encfs sur un sshfs va tout retélécharger, mais si la date ou la taille te suffisent, rsync fait ça très bien, de base, et le monatge encfs sur sshfs va seulement télécharger ce qui est nécessaire pour comparer les metadata.

              ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: astuce sécurité pour les paranoïaques

                Posté par  (site web personnel) . Évalué à 2.

                C’est le fonctionnement par défaut de rsync qui utilise la date de modification et la taille pour savoir si un fichier a changé.

                C'est différent parceque rsync a besoin d'avoir un fichier et sa copie pour faire cette comparaison alors que dump se contente de se souvenir qu'il a fait une sauvegarde du système de fichiers le 29 août 2015. On n'a même pas besoin de la sauvegarde précédente pour faire la prochaine (la sauvegarde précédente est dans le coffre fort;) )

                Si la date ou la taille ne sont pas un critère fiable dans ton contexte, tu peux utiliser l’option --checksum de rsync et là oui, la comparaison avec un système encfs sur un sshfs va tout retélécharger, mais si la date ou la taille te suffisent, rsync fait ça très bien, de base, et le monatge encfs sur sshfs va seulement télécharger ce qui est nécessaire pour comparer les metadata.

                Vu que rsync a un support ssh ce serait assez maladroit de ne pas en profiter et d'utiliser rsync à travers sshfs :)

                • [^] # Re: astuce sécurité pour les paranoïaques

                  Posté par  (site web personnel) . Évalué à 2.

                  C'est différent parceque rsync a besoin d'avoir un fichier et sa copie pour faire cette comparaison alors que dump se contente de se souvenir qu'il a fait une sauvegarde du système de fichiers le 29 août 2015.

                  Ah OK je n’avais pas compris cela.

                  Vu que rsync a un support ssh ce serait assez maladroit de ne pas en profiter et d'utiliser rsync à travers sshfs :)

                  Sauf que dans le cas évoqué, encfs est par dessus ssh si j’ai bien compris (donc en dessous d’rsync).

                  D’façon, si c’est pour ne faire que du rsync (et ne jamais les fonctionnaliés fs de ssh), autant directment rsyncer les fichiers chiffrés (donc via ssh, oui).

                  ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: astuce sécurité pour les paranoïaques

      Posté par  . Évalué à 2.

      tu auras une solution où le risque pour les données qui quittent ton pc sera nul.

      Pas vraiment, en fait. Comme tout chiffrement de volume temps réel, à partir du moment où le volume est monté, les données sont accessibles en clair pour n'importe qui a des droits suffisants. Par exemple par le ver que tu auras téléchargé en zonant sur internet en tombant sur un site dont la régie de pub est comprise, et qui tournera avec tes droits (ou pire avec uid==0). Donc peut-être que tu seras protégé sur le transfert des données en ligne et quand la machine sera éteinte ou ta session fermée, mais tu pourras de faire exfiltrer tout tes trucs dès que tu auras ouvert une session.
      Sans parler des problèmes autres d'EncFS.

      Probablement ce que l'on fait de mieux en terme de sécurité.

      Bof.

      • [^] # Re: astuce sécurité pour les paranoïaques

        Posté par  . Évalué à 1.

        Je pense que ce qu'il voulait dire, c'est que tu synchronise les fichiers crypté de encfs, donc, si ton serveur est compromis (et pas seulement ta connexion ssh) tes données reste protégé.
        Il ne parle pas du cas ou ton PC lui même est compromis.

  • # Non

    Posté par  . Évalué à 3.

    Pour moi un fs en réseau c'est Gluster… ou Ceph.
    sshfs c'est pour monter un répertoire distant.

  • # Perfs

    Posté par  (site web personnel) . Évalué à 6.

    Par contre d'expérience les performances ne sont pas terribles, je pense que le protocole n'est pas super optimisé, notamment quand la latence est un peu élevée.

    • [^] # Re: Perfs

      Posté par  (site web personnel) . Évalué à 3.

      Oui, je confirme qu'il n'est pas idéal de faire sshfs machineA:/ /tmp/A ; sshfs machineB:/ /tmp/B ; diff -r /tmp/A /tmp/B pour comparer deux machines (intrusion, bug, mise à jour, etc.). Malgré tout ça marche si on n'est pas pressé (et que l'on ne paie pas le trafic consommé pour recopier l'intégralité de A et B sur la machine utilisée pour la comparaison).

  • # Comparer NFS avec un fs implémenté par FUSE faut oser comme meme

    Posté par  . Évalué à 8.

    Parler d'un vrai système de fichier en réseau alors que c'est implémenté en userpace (basé sur FUSE) et dire que ça tiens la comparaison avec NFS faut oser. Niveau perf c'est le jour et la nuit, dès que ta plein de petits fichiers les performances s'écroulent. SSHFS c'est juste pas la bonne architecture (comme tout ce qui est basé sur FUSE), c'est rigolo pour s'amuser mais niveau perf c'est pas bon.

  • # webdav

    Posté par  (site web personnel) . Évalué à 5.

    Tu as omis webdav :-) (basé sur HTTPS, éventuellement HTTP pour ceux qui sont joueurs).

    Par ailleurs, SCP n'est généralement qu'un sous-ensemble de SFTP : cela utilise le sous-système SFTP sur l'hôte distant. L'avantage par rapport à FTP (et FTPS d'ailleurs), c'est qu'il y a les garanties :

    • d'acheminement : le code retour indique si ça s'est bien passé, contrairement à FTP qui se termine généralement par exit ou quit qui renvoie un code ok correspondant à la fermeture de la connexion, que le fichier ait été transféré correctement ou pas
    • d'intégrité : pas de blague à la ascii/binary du FTP, en outre c'est chiffré ce qui évite les modifications malencontreuses à la volée par des intermédiaires

    • [^] # Re: webdav

      Posté par  (site web personnel) . Évalué à 6.

      Par ailleurs, SCP n'est généralement qu'un sous-ensemble de SFTP : cela utilise le sous-système SFTP sur l'hôte distant.

      Non, désolé, en tout cas pas avec la commande scp d'OpenSSH. On le voit bien en désactivant le sous-système SFTP sur le serveur distant : on ne peut alors plus s'y connecter en SFTP, mais on peut toujours y déposer ou y récupérer des fichiers avec scp.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.