Journal [Tuto/HowTo] SSHFS : mises en place et montage

Posté par  . Licence CC By‑SA.
19
1
nov.
2016

Sommaire

[Tuto/HowTo] SSHFS : mises en place et montage

Présentation rapide

SSHFS permet d'utiliser un serveur ssh afin de monter des dossiers distants disponibles dans le système de fichier grâce à fuse.
Il ne nécessite côté serveur que openssh-server et côté client fuse openssh-client sshfs et éventuellement tor.
N'hésitez pas à signaler toute erreur/faute.

Ce tuto est une mise en forme de ces deux-ci : [Tuto/HowTo] Configurer et monter SSHFS sécurisé via utilisateur dédié côté serveur et [Tuto/HowTo] [GNU/Linux] Montage SSHFS cross-canal (Lan, Wan, Tor, etc)

Configurer le serveur SSH

Installez les pré-requis

sudo apt-get install tor openssh-server

Créez un utilisateur dédié

sudo adduser userCommunSFTP

Générez de nouvelles clés de sécurité pour l'utilisateur précédemment créé

su userCommunSFTP
ssh-keygen -t ed25519 -o -a 1666
ssh-keygen -t rsa -b 4096 -o -a 1666

Configurer le(s) client(s) GNU/Linux

Installez les pré-requis

sudo apt-get install openssh-client sshfs fuse

Si vous ne l'avez jamais fait depuis votre installation, générez de nouvelles clés

ssh-keygen -t ed25519 -o -a 16669
ssh-keygen -t rsa -b 4096 -o -a 16669

-o -a 100 : permet de faire boucler l’algorithme 100 fois
-b 4096 : précise qu'on veut une clé à 4096 bits (au début des années 2k la France interdisait plus de 126 bit ;) )
-t rsa : on utilise l’algorithme RSA
-t ed25519 : on utilise l'algorithme EdDSA

Exportez votre clé publique sur le serveur

ssh-copy-id -i ~/.ssh/id_ed25519.pub userCommunSFTP@adresseServerSSH

Ajoutez votre utilisateur à la liste des utilisateurs autorisés à utiliser fuse

sudo adduser $USER fuse
  • Note : remplacez $USER par l'utilisateur de votre choix (par défaut $USER = votre utilisateur courant (celui qui a ouvert la session sur votre machine)). Sur Raspberry Pi cette commande peut échouer sans que cela ne pose problème.

Autoriser les autres utilisateurs à monter un dossier avec fusermount

sudo nano /etc/fuse.conf
  • Décommentez (enlevez le # devant) user_allow_other puis tapez CTRL+X pour sauver et quitter.

Pour effectuer le montage SSHFS au démarrage il est fort possible que la machine passe par root.

Connectez-vous en root (admin)

sudo su

Générez une paire de clés solide pour root

ssh-keygen -t rsa -b 4096 -o -a 16666
ssh-keygen -t ed25519 -o -a 16666
  • La deuxième (ed25519) ne fonctionne pas sur Raspberry Pi

Exportez la clé publique de root sur la machine distante

ssh-copy-id -i /root/.ssh/id_rsa.pub userCommunSFTP@adresseServerSSH

Testez si l'ajout a bien fonctionné (ne doit pas demander de mot de passe)

ssh userCommunSFTP@adresseServerSSH

Quittez root

exit

Montage au démarrage sur le(s) client(s) via fstab et hostname fixe

Installez les pré-requis

sudo apt-get install openssh-client

Créer le point de montage local (adaptez à vos envies)

sudo mkdir /media/monPointDeMontageLocal

Accorder les bons droits à notre point de montage

  • Spécifiez les propriétaires
sudo chown root:$USER -R /media/monPointDeMontageLocal
  • Note : $USER = votre utilisateur courant par défaut, changez si besoin

  • Spécifiez aussi les droits d'accès des propriétaires

sudo chmod 770 -R /media/monPointDeMontageLocal
  • Note : si vous souhaitez que le montage soit accessible à tous vos utilisateurs systèmes remplacez 770 par 774 pour lecture uniquement ou 777 s'ils (tous les utilisateurs) peuvent avoir les mêmes droits que votre utilisateur principal sur ce point de montage. ( voir chmod )

Éditez le fichier /etc/fstab (CTRL+X pour sauver&quitter)

sudo nano /etc/fstab

Ajoutez le montage afin de le monter au boot

userCommunSFTP@adresseServerSSH:/home/userCommunSFTP/                /media/monPointDeMontageLocal          fuse.sshfs           port=22,user,noatime,reconnect,_netdev,nofail,allow_other     0 0
  • Note : :/dossier/distant/ n'est pas obligatoire ; nofail permet d'empêcher le boot de crasher si le montage ne réussit pas, _netdev ordonne d'attendre que le réseau soit fonctionnel avant d'effectuer le montage; allow_other autorise les autres utilisateurs à monter le dossier. Ajoutez noauto si vous voulez que le montage ne s'effectue qu'à la demande et non au démarrage de la machine.

Testez votre montage

sudo mount /media/monPointDeMontageLocal

Montage au démarrage sur le(s) client(s) via script DIY compatible cross-canal (LAN, WAN, TOR)

Installez les pré-requis

sudo apt-get install openssh-client tor

Créer le point de montage local (adaptez-le à vos envies)

sudo mkdir /media/monPointDeMontageLocal

Accorder les bons droits à notre point de montage

  • Spécifiez les propriétaires
sudo chown root:$USER -R /media/monPointDeMontageLocal
  • Note : $USER = votre utilisateur courant par défaut, changez si besoin

  • Spécifiez aussi les droits d'accès des propriétaires

sudo chmod 770 -R /media/monPointDeMontageLocal
  • Note : si vous souhaitez que le montage soit accessible à tous vos utilisateurs système remplacez 770 par 774 pour lecture uniquement ou 777 s'ils (tous les utilisateurs) peuvent avoir les mêmes droits que votre utilisateur principal sur ce point de montage. ( voir chmod )

Créez le script

sudo nano /opt/scripts/mountSSHFS.sh

Collez le code suivant en l'adaptant

#!/bin/bash
#licence WTFPL - script infos : https://www.0rion.netlib.re/forum4/viewtopic.php?f=68&t=339&p=893#p893
#github : https://github.com/voxdemonix/divers-script/blob/master/mountSSHFS_crosscanal.sh
#work on raspbian, ubuntu, debian and possibly Arch


if [ ! "$SUDO_USER" ]; then
echo "i need root => $0"
exit 0
fi
sleep 60 # petit délai d'attente afin que le réseau soit prêt


IpServerLocale="192.168.1.42" # server IP LAN
AdresseServerOnion="blablablablabla1.onion" # tor hidden service OR Hostname WAN
MacServerLocale="00:00:00:00:00:00" #l'adresse mac du serveur SSH (tapez ifconfig dans un terminal sur votre server pour la voir)
UserRemoteForSsh="user_sur_server" # l'utilisateur à utiliser côté serveur ( /!\ n'utilisez jamais root !)
port="22" # le port sur le server
monPointDeMontageLocal="/media/monPointDeMontageLocal"
monPointDeMontageDistant="/home/user_sur_serveur/"

umount $monPointDeMontageLocal -f >> /dev/null 2>&1
ping $IpServerLocale -c 1 >> /dev/null 2>&1
macRecover=$(arp -n | grep -i -o $MacServerLocale)

if [ "$macRecover" == "$MacServerLocale" ]; then
   sshfs -o allow_other -o reconnect -o ServerAliveInterval=15 $UserRemoteForSsh@$IpServerLocale:$monPointDeMontageDistant $monPointDeMontageLocal -p $port -C
else
   sshfs -o allow_other -o reconnect -o ServerAliveInterval=15 $UserRemoteForSsh@$AdresseServerOnion:$monPointDeMontageDistant $monPointDeMontageLocal -p $port -C
fi
  • IpServerLocale="192.168.1.42" => l'adresse IP LAN de votre serveur
  • AdresseServerOnion="blablablablabla1.onion" => l'hostname de votre serveur. Au choix un Tor Hidden Service, une IP WAn ou un Hostname WAN (exemple.com)
  • MacServerLocale="00:00:00:00:00:00" => l'adresse MAC de votre server (tapez ifconfig sur votre serveur pour la voir)
  • UserRemoteForSsh="user_sur_server" => utilisateur sur le serveur SSH à utiliser pour la connexion
  • port="22" => le port d'écoute du serveur ssh (par défaut 22)
  • monPointDeMontageLocal="/media/monPointDeMontageLocal" => où rendre disponible le montage sur votre client
  • monPointDeMontageDistant="/home/user_sur_server/" => Le dossier sur le serveur à partir du quel effectuer le montage

Rendez le script exécutable

sudo chmod +x /opt/scripts/mountSSHFS.sh

Lancez-le au boot en éditant /etc/rc.local

sudo nano /etc/rc.local
  • Et ajoutez la ligne suivante avant "exit 0" ###
sudo /opt/scripts/mountSSHFS.sh

Rendez compatible votre client SSH avec le réseau tor

sudo nano /etc/ssh/ssh_config
  • Et collez les lignes suivantes puis tapez CTRL+X pour sauver&quitter
    Host *.onion
       ProxyCommand nc -xlocalhost:9050 -X5 %h %p

Testez votre montage

sudo /opt/scripts/mountSSHFS.sh
  • # Correction

    Posté par  . Évalué à -1.

    Aaaah je peux même pas m'éditer juste après poste :D

    bon pour ssh-copy-id -i ~/.ssh/id_ed25519 userCommunSFTP@adresseServerSSH il manque le .pub comme suit

    ssh-copy-id -i ~/.ssh/id_ed25519.pub userCommunSFTP@adresseServerSSH
    

    Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Correction

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

      et dommage ne pas avoir lu la partie code sur l'aide-édition pour ajouter des balises ```bash pour colorer le code :/

      ainsi que quelques coquilles :

      • s/ server/ serveur/g
      • s/users/utilisateurs/ (pas partout)
      • s/ user / utilisateur /
      • s/tout vos/tous vos/
      • s/reseau/réseau/

      Merci pour ce tutoriel bien détaillé en tout cas ;-)

      • [^] # Re: Correction

        Posté par  . Évalué à 0.

        Désolé je ne me suis pas encore complètement adapté aux balises ^ ^ Je n'ai pas réussi à utiliser la liste à puce numérotée non plus (elle restait à 1. alors j'ai mis des puces normales) ^ ^

        Merci pour tes corrections :)

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: Correction

          Posté par  . Évalué à 0. Dernière modification le 02/11/16 à 12:37.

          J'ai oublié d'ajouter ssh-add après chaque génération de clés

          Si un modo pouvait l'ajouter après chaque génération de clés svp

          Ajoutez vos nouvelles clés au trousseau de votre utilisateur

          ssh-add
          
          • Si vous avez l'erreur "Could not open a connection to your authentication agent.", corrigez via
          eval `ssh-agent -s`
          ssh-add
          

          Vous pouvez aussi supprimer les sections "Accorder les bons droits à notre point de montage" dans les deux méthodes de montage :)

          Merci d'avance :)

          Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # En Bonus

    Posté par  . Évalué à -1. Dernière modification le 02/11/16 à 00:50.

    Je le rajoute en commentaire si non on va me dire que je fais encore trop long ^ ^
    Vous pouvez augmenter la sécurité de votre installation en supprimant les algo déjà cassé et en désactivant UseRoaming (source) :

    Côté client

    Désactiver la feature UseRoaming

    Éditez le fichier de configuration générale du client ssh /etc/ssh/sshconfig_

    sudo nano /etc/ssh/ssh_config
    • Et ajoutez la ligne suivante avant les Host :
    UseRoaming no
    

    N'autoriser que les algorithmes de chiffrement symétrique sûr (non cracké actuellement)

    Éditez le fichier de configuration du client ssh /etc/ssh/sshconfig_

    sudo nano /etc/ssh/ssh_config
    • Et ajoutez dedans *1 :
    Host *
        Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    

    Côté server

    • Éditez le fichier de configuration du serveur ssh /etc/ssh/sshdconfig_
    sudo nano /etc/ssh/sshd_config

    Supprimez les algorithmes de chiffrement symétrique déjà crackés en ajoutant dedans notre petite liste des algo autorisé *1

    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    

    Supprimez les algorithmes de hashage trop fragile *1 qui sont utilisé pour la vérification d'intégrité en ajoutant aussi ces lignes

    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
    

    Entrez CTRL+X pour sauver & quitter.

    *1 : n'hésitez pas à partager toute amélioration que vous connaîtriez :)

    Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: En Bonus

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

      Attention, x2goclient ne fonctionne plus si on est trop sévère coté algo… Je pense que le problème doit être du coté du client ssh en python qui doit être un peu faible ?

    • [^] # Re: En Bonus

      Posté par  . Évalué à 4.

      cassé et en désactivant UseRoaming (source) :

      Je ne sais pas si c'est toi qui opère ce serveur, mais il faudrait dire à l'admin qu'activer HSTS avec un certificat autosigné, c'est vraiment pas une bonne idée.
      Les mecs qui n'y ont jamais accédé ne peuvent jamais le faire (sauf à faire des bricoles hardcore)

      • [^] # Re: En Bonus

        Posté par  . Évalué à 0. Dernière modification le 03/11/16 à 16:50.

        Oui je suis désolé pour le désagrément, je suis en train de revoir la configuration de mes serveurs suite a une cascade de panne (j'ai eu la totale ce mois-ci, aujourd'hui je me suis encore tapé un nouveau bug que j'avais jamais eu)
        Fait exceptionnel le site est accessible en http (sans TLS) pour compenser le https actuellement cassé.

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: En Bonus

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

          d'un autre côté…Ubuntu pour un serveur…

          • [^] # Re: En Bonus

            Posté par  . Évalué à 5.

            C'est ce qui fait tourner linuxfr si ça n'a pas changé.

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

          • [^] # Re: En Bonus

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

            y'a du fan boy à ce qu'on dirait ;)

            • [^] # Re: En Bonus

              Posté par  . Évalué à 2.

              Non, c'est juste que ton "argument" se résume à un troll de guerre de clocher :P

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # Utilisateurs virtuels

    Posté par  . Évalué à 1.

    Et pour ceux qui veulent des utilisateurs virtuels, ProFTPd gère aussi le sftp.

    Emacs le fait depuis 30 ans.

  • # manipulations inutiles

    Posté par  . Évalué à 4.

    Merci d'avoir pris le temps de rédiger cette doc. Quelques remarques cependant. Les commandes de changements de droits sur le point de montage ne servent à rien puisque ces droits seront écrasés par ceux du répertoire monté. Je n'ai pas non plus compris l'intérêt de générer des clés SSH pour l'utilisateur userCommunSFTP.

    • [^] # Re: manipulations inutiles

      Posté par  . Évalué à 2.

      Les commandes de changements de droits sur le point de montage ne servent à rien puisque ces droits seront écrasés par ceux du répertoire monté.

      Merci pour l'infos, je confirme (je viens d'essayer), ça va permettre de diminuer le nombre de procédure :)

      Je n'ai pas non plus compris l'intérêt de générer des clés SSH pour l'utilisateur userCommunSFTP.

      Ne pas utiliser celles par défaut qui pourraient être trop faible :)

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: manipulations inutiles

        Posté par  . Évalué à 3.

        Je n'ai pas non plus compris l'intérêt de générer des clés SSH pour l'utilisateur userCommunSFTP.

        Ne pas utiliser celles par défaut qui pourraient être trop faible :)

        mais ces clefs ne sont jamais utilisées puisqu'on se connecte de l'exterieur vers userCommun et non du serveur vers l'exterieur.

        • [^] # Re: manipulations inutiles

          Posté par  . Évalué à 1. Dernière modification le 02/11/16 à 15:13.

          mais ces clefs ne sont jamais utilisées puisqu'on se connecte de l'exterieur vers userCommun et non du serveur vers l'exterieur.

          Alors quelles sont les clés utilisées? (Si je ne m'abuse l'initialisation se fait dans un tunnel avec crypto asymetrique le temps d'échanger une clé temporaire qui va permettre de créer un second tunnel avec crypto symetrique qui va remplacer le premier. Si le serveur peut envoyer la clés symetrique via la clé publique du client, ça ne m'étonnerait (supposition) pas qu'il demande une confirmation avant de créer le tunnel en crypto symetrique.)

          PS: intéressant, y a un troll qui moinsse tout mes messages à chacun de mes journaux :D

          Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

          • [^] # Re: manipulations inutiles

            Posté par  . Évalué à 4. Dernière modification le 02/11/16 à 15:20.

            Le serveur génère sa propre paire de clef pour ce genre de choses (c'est l'identité du serveur qui est vérifiée et pas l'identité de l'utilisateur sur le serveur).

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

            • [^] # Re: manipulations inutiles

              Posté par  . Évalué à 2.

              Tu veux dire que l'emprunte et la paire de clés utilisée par openssh-server sont les mêmes peu importe l'user?

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

              • [^] # Re: manipulations inutiles

                Posté par  . Évalué à 4.

                Oui. Les clés utilisées par le serveur sont dans /etc/ssh. C'est logique vu qu'elles doivent être utilisées avant l'authentification du client (donc avant même de savoir quel compte va être utilisé).

                • [^] # Re: manipulations inutiles

                  Posté par  . Évalué à 1. Dernière modification le 02/11/16 à 16:36.

                  Ah oki ! J'étais persuadé que chaque user disposait de sa propre paire de clés et de sa propre emprunte. (un peu à la manière de TLS avec les hostnames)
                  Merci d'avoir rectifié le tir.
                  Alors oui à ce moment là la partie génération de clés pour l'user dédié sur le serveur est complètement inutile.

                  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

              • [^] # Re: manipulations inutiles

                Posté par  . Évalué à 0.

                Oui.
                D'où le nom du fichier : "~/.ssh/known_hosts"
                Au passage, les clés du serveur OpenSSH sont dans "/etc/ssh/"

  • # ip link et pas ifconfig

    Posté par  . Évalué à 10.

    MacServerLocale="00:00:00:00:00:00" => l'adresse MAC de votre server (tapez ifconfig sur votre serveur pour la voir)
    

    Non, non, et non.
    Tapez ip link s'il vous plaît. ifconfig est déprécié depuis de nombreuses années.

    • [^] # Re: ip link et pas ifconfig

      Posté par  . Évalué à 5.

      Ou netstat -ie :)

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

      • [^] # Re: ip link et pas ifconfig

        Posté par  . Évalué à 7.

        Netstat est déprécié aussi :) au profit de ss
        Cependant, pour ça, je préfère toujours netstat.

        Ifconfig n'est même plus installé par défaut (paquet iputils) sur les Fedora & CentOS & Red Hat récentes. En fait il faut préciser : les usages courant de ifconfig sont dépréciés au profit de nmcli (outils qui est über bien fait, quelque soit l'avis sur NetworkManager), et les usages plus avancés de ifconfig sont dépréciés au profit de ip.

        Une touche d'humour en disant que "nmcli pour les admins système & ip pour les admins réseaux et admins avancés" (désolé, pardon aux mamans, toussa :)

        • [^] # Re: ip link et pas ifconfig

          Posté par  . Évalué à 6.

          Netstat est déprécié aussi :) au profit de ss
          Cependant, pour ça, je préfère toujours netstat.

          Je ne connaissais pas et moi aussi je préfère netstat. Mon principal usage c'est netstat -lntp pour savoir qui écoute sur quel port. L'équivalent ss est proche (ss -ltp), mais il fait bien attention à prendre toute la largeur de l'écran pour 5 des 6 colonnes qu'il affiche. Donc a avoir systématiquement la sixième colonne sur une seconde ligne (alors que tu as pleins de place dans la ligne du dessus. J'ai pas encore trouver comment corriger ça (sans le wrapper).

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

          • [^] # Re: ip link et pas ifconfig

            Posté par  . Évalué à 5. Dernière modification le 04/11/16 à 01:13.

            mais il fait bien attention à prendre toute la largeur de l'écran pour 5 des 6 colonnes qu'il affiche. Donc a avoir systématiquement la sixième colonne sur une seconde ligne (alors que tu as pleins de place dans la ligne du dessus

            Je trouve ça sur illisible aussi. Mon astuce à 2 cents :

            ss -ltp | cat
            

            et là tu as un truc parfaitement lisible, tel qu'il devrait être sans bricoler.
            Remplacer « cat » par « less » s'il y a beaucoup de lignes, ou pour faire des recherches.

        • [^] # Re: ip link et pas ifconfig

          Posté par  . Évalué à 1.

          Netstat est déprécié aussi :) au profit de ss

          Tu rigoles? Franchement une commande ss?

    • [^] # Re: ip link et pas ifconfig

      Posté par  . Évalué à 2.

      Tiens, à propos du remplacement d'ifconfig, je l'utilise pour voir les statistiques de paquets Tx et Rx, comme ceci :

      eth0      ...
                RX packets:147472 errors:0 dropped:0 overruns:0 frame:0
                TX packets:70903 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000 
                RX bytes:86955615 (82.9 MiB)  TX bytes:17784893 (16.9 MiB)
                Interrupt:18 
      

      Comment obtient-on ces informations avec les commandes "ip" ?

      • [^] # Re: ip link et pas ifconfig

        Posté par  . Évalué à 8.

        ip -s -h link
        

        cf man ip-link

        • [^] # Re: ip link et pas ifconfig

          Posté par  . Évalué à 1.

          ouais pas mal, mais bon je viens d'essayer ip :

          -HP-HDX-18:~$ ip
          Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
          ip [ -force ] -batch filename
          where OBJECT := { link | address | addrlabel | route | rule | neighbor | ntable |
          tunnel | tuntap | maddress | mroute | mrule | monitor | xfrm |
          netns | l2tp | fou | tcp_metrics | token | netconf }
          OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
          -h[uman-readable] | -iec |
          -f[amily] { inet | inet6 | ipx | dnet | mpls | bridge | link } |
          -4 | -6 | -I | -D | -B | -0 |
          -l[oops] { maximum-addr-flush-attempts } | -br[ief] |
          -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] [filename] |
          -rc[vbuf] [size] | -n[etns] name | -a[ll] | -c[olor]}

          et ifconfig renvoie une valeur directement :/, quit a lire le man si on en veut plus, yaka faire des alias avec ip ok, suis assez decu de cette evolution peu sexy. ca en fait des truc nouveau a apprendre.

  • # Merci pour le partage

    Posté par  . Évalué à 5.

    Merci pour ton travail.

    J'aurais néanmoins quelques remarques :

    • pourquoi tu génère systématiquement 2 paires de clefs (une rsa et une ed25519) ?
    • plutôt que de présenter la liste des algo forts ou faibles actuellement je pense qu'il serait plus intéressant d'indiquer comment savoir qu'un algo est cassé ou non :)
    • il y a pas mal de manipulation dont l'intérêt n'est pas très clair (il y a beaucoup de génération de clef par exemple, rapidement je n'ai pas bien compris pourquoi la procédure pour le montage au démarrage est aussi complexe)

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

    • [^] # Re: Merci pour le partage

      Posté par  . Évalué à -1.

      pourquoi tu génère systématiquement 2 paires de clefs (une rsa et une ed25519) ?

      Il me semble (d'après mes souvenirs peut-être faussé) que RSA est moins solide que edDSA. Hors pour une raison que j'ignore edDSA ne fonctionne pas toujours sur raspbian.
      Donc dans le doute je propose une de chaque mais en effet l'utilisateur peut n'en générer qu'une seule ou 50 c'est au choix (le paramètre -i PathDeLaKey.pub permet de spécifier quelle clés utiliser).
      Ça me fait penser que j'ai oublié d'ajouter ssh-add dans le tuto.

      plutôt que de présenter la liste des algo forts ou faibles actuellement je pense qu'il serait plus intéressant d'indiquer comment savoir qu'un algo est cassé ou non :)

      Peut-être quelqu'un aura-t-il une réponse. Ma liste est originellement récupérée sur le net en recherchant "sécuriser ssh".

      il y a pas mal de manipulation dont l'intérêt n'est pas très clair (il y a beaucoup de génération de clef par exemple,

      Il y a deux générations de clés pour le client dans le tuto : une pour l'utilisateur courant et une pour root. Pour un montage au boot avec fstab l'utilisateur est root. Note que je n'ai pas vérifié si root est nécessaire pour le montage via script.

      rapidement je n'ai pas bien compris pourquoi la procédure pour le montage au démarrage est aussi complexe)

      Elle n'est pas complexe (6 points pour le montage via fstab et 9 point pour le montage via script).
      C'est juste que j'explique deux méthodes différentes de montage avec leurs avantages&inconvénients :

      • fstab : permet d'utiliser mount/umount, hostname statique uniquement
      • script lancé au boot : ne permet pas d'utiliser mount, compatible hostname dynamique

      Par contre dans ma mise en page les retours chariot que j'ai mis entre les différentes section/chapitre ont été supprimé automatiquement se qui donne cette impression d'un tas un peu indigeste

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: Merci pour le partage

        Posté par  . Évalué à -2.

        Après test, root ne semble pas nécessaire pour lancer le montage via script. Vous pouvez supprimer le sudo devant l'appel du script dans /etc/rc.local si vous suivez la partie sur le montage via script maison. :)

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: Merci pour le partage

        Posté par  . Évalué à 4.

        Donc dans le doute je propose une de chaque mais en effet l'utilisateur peut n'en générer qu'une seule ou 50 c'est au choix (le paramètre -i PathDeLaKey.pub permet de spécifier quelle clés utiliser).

        Tu ne pousse qu'une seule clef publique sur le serveur et comme tu te base sur le comportement implicite ça donne l'impression que ce n'est pas utilisé derrière.

        Il y a deux générations de clés pour le client dans le tuto : une pour l'utilisateur courant et une pour root. Pour un montage au boot avec fstab l'utilisateur est root. Note que je n'ai pas vérifié si root est nécessaire pour le montage via script.

        Ça en fait une de trop. Il n'y a pas d'intérêt (au contraire) à ce que root fasse le montage. Tu peut très bien faire un : su myuser /opt/scripts/mountSSHFS.sh pour être l'utilisateur que tu souhaite. Moins tu as de clef dans la nature mieux tu te porte (ça te ferra toujours une clef en moins à supprimer plus tard).

        Elle n'est pas complexe (6 points pour le montage via fstab et 9 point pour le montage via script).
        C'est juste que j'explique deux méthodes différentes de montage avec leurs avantages&inconvénients :

        • fstab : permet d'utiliser mount/umount, hostname statique uniquement
        • script lancé au boot : ne permet pas d'utiliser mount, compatible hostname dynamique

        Il y a un truc qui empêche à ce que ton script fasse juste un changement de la ligne qui va bien dans fstab ? Comme ça ta seconde méthode se limite à ajouter un l'option noauto et à lancer le script (et monter le périphérique). Une fois mis en place l'utilisateur ne voit plus la différence entre l'un et l'autre.

        Il a fallu que je lise ton script pour comprendre ce que tu entendais par « DIY compatible cross-canal (LAN, WAN, TOR) ».

        Tu dois pouvoir faire la même chose sans toucher au fstab et en modifiant le fichier ~/.ssh/config à la place. Ça simplifiera toutes tes commandes et tu peux te contenter d'avoir les 2 fichiers de config et faire un lien qui va bien pour que ça fonctionne.

        Faire un montage réseau au démarrage ce n'est pas forcément tip top, le réseau ça peut mettre du temps à s'initialiser. Personnellement, je préfère dire à nm de faire le montage lorsqu'il a trouvé la connexion et comme il sait sur quel réseau il est tu peux paramétrer la méthode de montage.

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

        • [^] # Re: Merci pour le partage

          Posté par  . Évalué à 1. Dernière modification le 02/11/16 à 15:37.

          Je prend note, merci de ton retour :)

          Il n'y a pas d'intérêt (au contraire) à ce que root fasse le montage.

          Avec le fstab il me semble qu'avec l'option allow_other dans fstab puis un mount fait par l'user ça fonctionne sans root.
          Par contre avec le script on peut l'appeler sans root pour effectuer le montage (ça fonctionne faut juste commenter le if qui vérifie si root comme ici), mais le umount (dans le script) lui ne fonctionne pas sans root (bon, il n'est utile que si l'utilisateur veut appliquer un démontage/remontage)

          Tu dois pouvoir faire la même chose sans toucher au fstab et en modifiant le fichier ~/.ssh/config à la place. Ça simplifiera toutes tes commandes et tu peux te contenter d'avoir les 2 fichiers de config et faire un lien qui va bien pour que ça fonctionne.

          Je suis ouvert à toute méthode :) (plus c'est "assimilé" par le système et mieux ça me convient ^ ^ )

          Faire un montage réseau au démarrage ce n'est pas forcément tip top, le réseau ça peut mettre du temps à s'initialiser.

          Avec fstab il y a l'option _netdev qui permet d'attendre que le réseau soit prêt si non dans mon script j'ai mis un délais d'une minute (se qui semble largement suffisant pour le RPI 1 sur lequel j'ai testé, sur un pc portable avec connexion automatique désactivée je privilégie 5 minutes)

          Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Merci pour le partage

      Posté par  . Évalué à 3.

      plutôt que de présenter la liste des algo forts ou faibles actuellement je pense qu'il serait plus intéressant d'indiquer comment savoir qu'un algo est cassé ou non :)

      Ça, c'est facile, on regarde

      (d'ailleurs, la partie sur les modules a été oubliée dans ce nourjal)

      • [^] # Re: Merci pour le partage

        Posté par  . Évalué à 4.

        Pas de changement depuis janvier 2015 ? C'est le blog de qui ? C'est vraiment à jour ? Sans dénigrer du tout le blog de cette personne, j'aurais plus imaginé quelque chose qui viennent d'une communauté ou d'une organisation.

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

  • # coquille

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

    Exportez la clés publique de root sur la machine distante

    la clé ou clef

    Système - Réseau - Sécurité Open Source

  • # Petite surprise...

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

    J'ai un serveur de fichier sur le réseau, je fais des montages sshfs depuis différentes machines avec mon yuser courant. Jusque là, c'est super pratique. Mais récemment, j'ai voulu graver une clef USB avec une image ISO qui est dans le serveur de fichier.

    Pour accéder au device, hop, sudo -i et voilà, je pensais y être. Hélas, le contenu du montage n'est pas accessible à root ;(

    Je n'ai pas RTFM plus que ça, parce que àlabourre-toussa, mais j'avoue que j'étais un peu étonné…

    foo = close(mavie);

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # udevil

    Posté par  . Évalué à 2.

    Pour monter un système de fichier sans être en root, j'ai découvert il y a peu udevil.
    Ça permet de monter du sshfs mais aussi du samba, ftp ou n'importe quel systèmes de fichiers!

    udevil mount ssh://user@sys.domain

    https://ignorantguru.github.io/udevil/

  • # Wiki

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

    Ceci devrait être une page du wiki.

    Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

    • [^] # Re: Wiki

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

      Ceci devrait être une page du wiki.

      plutôt une page astuce du forum que l'auteur peut continuer d'éditer :-) mais cela ne permet pas le travail à plusieurs :/ (uniquement via les commentaires). À renommer en « astuce / tutoriel » dans ce cas ?

      cela redorerait l'intérêt des forums :-) (ou en tout cas du forum astuce qui a arrêté d'être pollué par ceux ne sachant pas choisir dans une liste le bon forum du jour où astuce n'est plus le choix par défaut : qu'il faille choisir un forum est très bien).

      Bon, l'espace de rédaction pour autre chose que les dépêches (journaux aussi ?), ça peut être une idée ?
      C'est sur le sondage de contribuer à LinuxFr.org qu'il faudrait en parler puis le suivi

      Merci pour ta suggestion tout de même, cela pourrait être discuté un peu plus (à la prochaine rencontre IRL de LinuxFr.org :-) par exemple ou dans les commentaires ci-dessous)

Suivre le flux des commentaires

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