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 oinkoink_daotter . Évalué à 7.
C'est pas propre à sshfs. Ca peut être rigolo avec NFS et CIFS aussi.
[^] # Re: Oui
Posté par Seb (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 Antoine . É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.entrydans le fichier de config de ton conteneur.[^] # Re: Oui
Posté par Michaël (site web personnel) . Évalué à 4.
Apparemment on peut traduire les UIDS de façon transparente.
[^] # Re: Oui
Posté par Ontologia (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 reynum (site web personnel) . Évalué à 3.
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 Guillaume Denry (site web personnel) . Évalué à 5.
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 reynum (site web personnel) . Évalué à 2.
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 Guillaume Denry (site web personnel) . Évalué à 2.
Non, pas encore tenté puisqu'entre temps, je me suis débrouillé pour utiliser un autre système de build.
[^] # Re: Oui
Posté par Yann Hodique (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 reynum (site web personnel) . Évalué à 4.
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 jihele . É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 SChauveau . É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 jihele . Évalué à 2.
Merci.
Une recherche rapide m'a amené à cette page qui donne quelques détails.
[^] # Re: Oui
Posté par SChauveau . É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 David (site web personnel) . Évalué à 5.
Petite interface pour sshfs en Perl/GTK/glade :
[^] # Re: Et si vous êtes fainéant : Xsshfs
Posté par David (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 zurvan . É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 Tarnyko (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 David (site web personnel) . Évalué à 1.
Merci pour ces retours en tout cas.
# Résilience
Posté par Michaël (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 Ontologia (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 Yth (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 lolop (site web personnel) . Évalué à 5.
Voir les options de montage NFS
hard/softetintr.Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Résilience
Posté par Yth (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 Zenitram (site web personnel) . Évalué à 0.
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 barmic . Évalué à 9.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
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.
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 Zenitram (site web personnel) . Évalué à -5.
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.
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 Petit_Scarabee . É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 ®om (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 cedric . É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 ®om (site web personnel) . Évalué à 5.
Dans le cadre d'un backup chiffré à distance, ça n'a aucun intérêt par contre : le
rsyncva tout rapatrier en local pour vérifier les données qu'il a besoin d'envoyer.Par ailleurs,
encfsn'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 :
blog.rom1v.com
[^] # Re: astuce sécurité pour les paranoïaques
Posté par jihele . É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 ®om (site web personnel) . Évalué à 3.
Pour des backups incrémentaux chiffrés, je te conseille duplicity.
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 jihele . Évalué à 2.
Super. Merci pour le tuto que je me bookmarke derrière l'oreille pour plus tard.
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 rewind (Mastodon) . Évalué à 1.
Les mots « crypter » et « cryptage » n’existent pas !
[^] # Re: astuce sécurité pour les paranoïaques
Posté par BAud (site web personnel) . Évalué à 4.
tiens, il a oublié les deux exemples classiques :
[^] # Re: astuce sécurité pour les paranoïaques
Posté par rewind (Mastodon) . Évalué à 5.
J'adore aussi ce site : cryptage digital.
[^] # Re: astuce sécurité pour les paranoïaques
Posté par barmic . Évalué à 6.
On voit plus de monde hurler au scandale pour « crypter » que pour « librairie », c'est marrant ؟
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: astuce sécurité pour les paranoïaques
Posté par BAud (site web personnel) . Évalué à 3.
j'ai les deux sur traductions-classiques, mais c'est surtout support qui m'insupporte :-)
[^] # Re: astuce sécurité pour les paranoïaques
Posté par rewind (Mastodon) . Évalué à 4.
librairie est un mot qui existe (même s'il est mal employé dans le cas d'une bibliothèque logicielle), alors que crypter non, ceci explique peut-être cela.
[^] # Re: astuce sécurité pour les paranoïaques
Posté par Michaël (site web personnel) . Évalué à 2.
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 ®om (site web personnel) . Évalué à 2.
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 Michaël (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 Thomas Debesse (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é.
Si la date ou la taille ne sont pas un critère fiable dans ton contexte, tu peux utiliser l’option
--checksumde 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 Michaël (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. 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;) )
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 Thomas Debesse (site web personnel) . Évalué à 2.
Ah OK je n’avais pas compris cela.
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 oinkoink_daotter . Évalué à 2.
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.
Bof.
[^] # Re: astuce sécurité pour les paranoïaques
Posté par Fabien PRORIOL . É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 MTux . É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 JoeltheLion (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 Benoît Sibaud (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/Bpour 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 Tangi Colin . É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.
[^] # Re: Comparer NFS avec un fs implémenté par FUSE faut oser comme meme
Posté par ®om (site web personnel) . Évalué à 5.
La perte de performance due à FUSE/SSHFS n'est-elle pas négligeable par rapport au fait que les données soient distantes?
Ou alors la gestion n'est pas optimale pour fonctionner sur le réseau?
blog.rom1v.com
[^] # Re: Comparer NFS avec un fs implémenté par FUSE faut oser comme meme
Posté par homer242 (site web personnel) . Évalué à 1.
J'ai un freebsd avec ZFS dessus. Et bien NFS c'est catastrophique. J'ai de bien meilleur résultat avec CIFS ou SSHFS.
D'ailleur, y'aurais pas un lutin qui aurait une solution pour améliorer les performances avec le duo ZFS / NFS ?
# webdav
Posté par BAud (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 :
[^] # Re: webdav
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
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.