Journal Utiliser Avahi et SSH pour du partage de fichiers

Posté par .
Tags : aucun
29
17
oct.
2010

Hello tout le monde,


À la demande générale de JoelTheLion, et comme ça peut servir à d'autres, je me propose dans ce journal de décrire la mise en place de répertoires partagés sur un serveur « à la Windows » mais en mieux.


J'utilise SSH comme protocole de transfert de fichier, Avahi pour déclarer les partages et Nautilus ou Dolphin pour y accéder sans taper au clavier.



Pourquoi c'est mieux :

  • parce que c'est libre et ne met en œuvre que des technologies ouvertes,

  • parce que c'est du pur Unix & KISS,

  • parce que c'est sécurisé,

  • parce que c'est fiable, même entre distributions très différentes (essayez de partager un dossier entre Seven et Vista, vous aurez envie de vous pendre avec le câble réseau...),

  • parce que c'est ergonomique côté client (deux ou trois clics sous GNOME et KDE).



Dans l'ensemble il n'y a rien ni compliqué ni de nouveau, mais ça permet de compiler toutes les commandes et remarques intéressantes en une page, comme ça pas besoin de chercher. Et puis ça peut donner des idées à d'autres.



Bien sûr, Avahi doit être installé et fonctionnel sur les serveurs et clients (un simple « ping server.local » suffit à valider ce point). KDE a besoin de kde-zeroconf, et GNOME utilise GVFS qui prend ça en charge (bien qu'il vaille mieux avoir gvfs-fuse).



Tout d'abord, rien à faire sur le client si ce n'est créer le couple de clef SSH. Il suffira de lancer avec l'utilisateur à autoriser un bête :


$ ssh-keygen -t dsa

La clef publique à récupérer par la suite est ~/.ssh/id_dsa.pub.



Côté serveur, les manipulations sont plus nombreuses.



On créé le répertoire à partager, ainsi qu'un utilisateur qui en sera propriétaire :


# mkdir /srv/share

# useradd -m -c "Share user" user
# chown -R user /srv/share

Pas besoin de mot de passe puisqu'on va utiliser des clefs.



Personnellement, j'utilise scponly qui n'autorise que les connexions SSH via SCP mais pas l'ouverture de shell, sinon il faut utiliser un shell standard, ce qui laisse un risque potentiel. De plus, utiliser /bin/false ou /sbin/nologin empêchent les transferts SFTP.



Pour ce faire :


# chsh -s /usr/bin/scponly user

On autorise les clefs publiques en ajoutant le contenu des ~/.ssh/id_dsa.pub des clients dans le fichier ~/.ssh/authorized_keys sur le serveur.



Ici, on peut déjà vérifier que ça se monte sur les clients, même si ça n'est pas automatique. Sous GNOME, on peut lancer :


$ gvfs-mount sftp://user@server.local

$ gvfs-mount -l
Mount(0): sftp en tant que user sur server.local -> sftp://user@server.local/
Type: GDaemonMount


Si c'est bon, on peut démonter :


$ gvfs-mount -u sftp://user@server.local

(je préfère GNOME entre autres parce qu'on ne peut pas vraiment scripter des trucs comme ça sous KDE, encore que ça doit pouvoir se faire avec Dbus mais ça me semble beaucoup moins évident)



La dernière étape, la déclaration réseau, se fait en créant un fichier .service dans le répertoire /etc/avahi/services, par exemple share.service.



Normalement c'est en XML mais je n'ai pas trouvé comment l'insérer, donc ici c'est avec des crochets :-).

De toute manière il y a des exemples dans /usr/share/doc/avahi-daemon :



[?xml version="1.0" standalone='no'?][!--*-nxml-*--]
[!DOCTYPE service-group SYSTEM "avahi-service.dtd"]
[service-group]
[name replace-wildcards="yes"]Nom du partage sur %h[/name]
[service]
[type]_sftp-ssh._tcp[/type]
[port]22[/port]
[txt-record]path=/srv/share[/txt-record]
[txt-record]u=user[/txt-record]
[/service]
[/service-group]


On y précise donc juste le répertoire et l'utilisateur avec lequel se connecter.



Pas besoin de relancer Avahi, c'est pris en compte immédiatement.



On vérifie que ça se déclare bien sur le client en lançant :


$ avahi-browse -tr _sftp-ssh._tcp

= eth0 IPv4 Partage sur server.local SFTP File Transfer local
hostname = [server.local]
address = [x.x.x.x]
port = [22]
txt = ["u=user" "path=/srv/share/"]


Avec ça, a-priori tout est bon.



On vérifie avec Nautilus ou Dolphin en ouvrant l'URI network:/ .



Sous Nautilus, le partage doit apparaître directement à la racine et en l'ouvrant, il est monté dans ~/.gvfs si on a gvfs-fuse.



Avec Dolphin, il faut descendre dans « Network Services » puis « Remote disk (sftp) » et on doit voir le partage.



Voilà, j'espère avoir clair et utile. En tout cas, chez moi ça marche tout seul : j'utilise ce système quotidiennement et je n'ai plus les problèmes que j'avais avec le couple NFS/Automount (qui notamment ne supportait pas les coupures réseau). Bon c'est plus lent mais ça reste utilisable.



Quelques remarques :


  • pour un réseau domestique c'est super (deux ou trois utilisateurs), pour une entreprise il y a certainement des choses à adapter, toutefois ça ne me paraît pas irréaliste,

  • pour plus de sécurité, je désactive les connexions SSH par mot de passe, avec PasswordAuthentication=no dans /etc/ssh/sshd_config,

  • comme c'est basé sur SSH et Avahi, il y a de grandes chances que ça fonctionne aussi sous Mac OSX; si quelqu'un peut nous faire un retour, nous en saurions plus,

  • en cas de problème au montage, vérifier la configuration SSH et en particulier les permissions de ~/.ssh et de ses fichiers. SSH est très tatillon sur ce point.

  • # OpenSSH intègre déjà de quoi limiter

    Posté par (page perso) . Évalué à 10.

    OpenSSH intègre déjà, dans sa version actuelle, de quoi limiter un utilisateur au SFTP et le contraindre dans un répertoire. scponly n'a plus de raison d'être.

    http://formation-debian.via.ecp.fr/ftp.html#id575203
  • # Merci!

    Posté par (page perso) . Évalué à 3.

    Je teste ça dès que j'ai un moment. C'est juste dommage que tu n'aies pas fait une dépêche! :)
  • # Comme c'est complique...

    Posté par . Évalué à 1.

    parce que c'est fiable, même entre distributions très différentes (essayez de partager un dossier entre Seven et Vista, vous aurez envie de vous pendre avec le câble réseau...),

    net share monpartage=c:\repertoire

    Ah ouais, ouhlala c'etait super-complique...
    • [^] # Re: Comme c'est complique...

      Posté par (page perso) . Évalué à 9.

      C'est authentifié ?

      DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Comme c'est complique...

      Posté par . Évalué à -2.

      Tu n'as pas froid aux yeux toi ! Rappelle toi que, après celui de GCU-Squad, ce site est le deuxième repaire des ennemis acharnés du monopole crosoftien dans la francophonie.
    • [^] # Re: Comme c'est complique...

      Posté par . Évalué à 3.

      J'ai essayé, mais c'est pas mieux...

      J'ai découvert que Seven avait implémenté une nouvelle notion qui est le « réseau résidentiel » qui donne un mot de passe commun à tout le réseau et permet de faciliter les accès aux partages. Une bonne idée, sauf que c'est actif par défaut et que ça empêche les machines hors-Seven d'accèder aux partages. Dans un monde où XP est encore la norme, c'est un peu bloquant...

      J'ai fini par trouver une option à décocher pour permettre cet accès, dommage que je ne l'ai pas notée (en même temps, je ne pense pas avoir à le refaire).

      Bref aujourd'hui, à moins d'être administrateur Windows ou très bidouilleur, c'est un peu la galère. Qui a dit que Windows était adapté au grand public ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Comme c'est complique...

        Posté par (page perso) . Évalué à -7.

        Je pense que les parts de marché le disent clairement. Si windows était si mal adapté, il serait vendu autre chose avec les machines.

        Envoyé depuis mon lapin.

        • [^] # Re: Comme c'est complique...

          Posté par . Évalué à 10.

          Si plusieurs OS étaient proposés lors de l'achat d'un PC, je ne suis pas sûr qu'on verrait les mêmes parts de marché.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Comme c'est complique...

            Posté par (page perso) . Évalué à -7.

            Donc tu penses que tout les constructeurs de PC mettent un OS totalement inadapté sur leurs machines, tout ça pour garder les bons prix que fait microsoft ?

            Ah d'accord…

            Envoyé depuis mon lapin.

            • [^] # Re: Comme c'est complique...

              Posté par (page perso) . Évalué à 10.

              Oui, ce serait aussi débile que de faire des lois inadaptées uniquement pour favoriser des grands groupes financiers.
              Mais heureusement, personne ne le ferait.

              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # Txt record

    Posté par . Évalué à 2.

    Merci, je savais pas qu'on pouvait filtrer par utilisateur et par dossier via les text record...c'est quand même mieux ;)
    • [^] # Re: Txt record

      Posté par . Évalué à 2.

      Se n'est pas un filtrage dans ce champ TXT. Ce n'est qu'une information sur un utilisateur utilisable pour ce connecter en sftp sur ce répertoire. Rien n'interdit par ces déclarations de se connecter avec un autre utilisateur ou sur un autre répertoire. Sauf si tu l'interdis dans la configuration de sshd.
  • # Super

    Posté par . Évalué à 5.

    Je prépare justement un serveur de fichier à la maison et je compte utilisé sftp pour cela.

    Toutefois, ce serveur ne sera pas allumé en permanence (suspend to ram). Il faudra le réveiller d'abord. La mise en veille sera assuré par un petit service qui regarde s'il y a des connexion ssh active et s'il n'y a pas de jeton à durée limitée d'actif.

    Il me reste la partie client à faire. Je ne sais pas trop quelle techniques je vais employer pour cela ou si la technique sera la même entre les machines fixes et les portables.

    Je posterai sùrement un journal une fois la plateforme prête.
    • [^] # Re: Super

      Posté par . Évalué à 3.

      Tu te prends beaucoup le tête je trouve. Tu pourrais « simplement » prendre un serveur avec un suspend to RAM correct et configurable, de manière à ce qu'il se réveille quand on lui adresse un paquet de n'importe quel type.
      • [^] # Re: Super

        Posté par . Évalué à 4.

        Ce n'est pas si facile, il faut une carte qui supporte le bon mode WOL.

        La carte intégrée ne supporte que le mode WOL MagicPacket et ne marche pas en suspend to RAM. Pas bien grave car je comptais utiliser une carte 1Gbit.

        Ma carte 1Gbit ne supporte que les modes WOL MagicPacket et activité physique. C'est une carte premier prix. Malheureusement, je suis chez neuf et la box TV envoie des packets en broadcast ce qui réveille de suite le serveur en mode activité physique.

        Par contre, je viens de vois que les cartes utilisant le driver 8139too (carte très courante) peuvent supporter plus de modes WOL. Je m'en vais en essayer quelques-unes.

        Tant pis pour le 1Gbit. Je pourrais toujours racheter une carte 1Gbit plus tard.Le serveur est pour l'instant de la pure récup.
        • [^] # Re: Super

          Posté par . Évalué à 3.

          J'ai trouvé une carte qui supporte le mode WOL unicast. Ça fonctionne très bien, mais il faut mettre en dur l'adresse MAC dans la table arp. Bon une ligne dans /etc/ethers et arp -f /etc/ethers (ajouter cette commande au boot des machines si nécessaire) et tout roule pour les machines en local.

          Le problème, pour réveiller le serveur depuis internet, il faut faire les mêmes modifications sur le routeur. Heureusement (dans notre cas), je suis chez SFR mais neufbox en prêt. Je ferai ces modifications si je trouve une neufbox4 d'occassion.
      • [^] # Re: Super

        Posté par . Évalué à 2.

        Ce n'est pas si facile, il faut une carte qui supporte le bon mode WOL.

        La carte intégrée ne supporte que le mode WOL MagicPacket et ne marche pas en suspend to RAM. Pas bien grave car je comptais utiliser une carte 1Gbit.

        Ma carte 1Gbit ne supporte que les modes WOL MagicPacket et activité physique. C'est une carte premier prix. Malheureusement, je suis chez neuf et la box TV envoie des packets en broadcast ce qui réveille de suite le serveur en mode activité physique.

        Par contre, je viens de vois que les cartes utilisant le driver 8139too (carte très courante) peuvent supporter plus de modes WOL. Je m'en vais en essayer quelques-unes.

        Tant pis pour le 1Gbit. Je pourrais toujours racheter une carte 1Gbit plus tard.Le serveur est pour l'instant de la pure récup.
  • # mDNS et DNS-SD

    Posté par (page perso) . Évalué à 3.

    Si j'ai bien compris la configuration, tu utilises Avahi et donc mDNS pour annoncer le partage aux clients. Il faut donc préciser que, par défaut, seuls les clients qui sont dans le même sous-réseau que le serveur recevront l'annonce mDNS du partage. Si on veut y accéder depuis un client qui est dans un autre sous-réseau, il faut une passerelle mDNS sur le routeur, ce qui peut se faire, de mémoire, en installant avahi sur le routeur et en activant la fonction de reflector.

    Sinon, il doit être possible de faire du DNS-SD, ce qui supprime la limitation au sous-réseau. Dans ce cas, la config se fait dans le serveur DNS du domaine, plus besoin d'Avahi.
    • [^] # Re: mDNS et DNS-SD

      Posté par . Évalué à 3.

      Il me semble (j'ai pas vérifié) que DNS-SD (pour « Service Discovery », c'est bien d'expliciter tous ces acronymes) est juste la convention (nommage, type d'enregistrement, etc) pour la publication de ces infos. Et que mDNS (multicast DNS) est une alternative au DNS classique, surtout utile quand on n'a pas l'autorité pour modifier ce DNS classique, ce qui est quasiment toujours le cas. Bref, ta proposition me semble utile même si mal nommée, mais je suis pris d'un doute quant à son fonctionnement : t'as plus d'infos ?

Suivre le flux des commentaires

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