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

Posté par EauFroide le 01 novembre 2016 à 23:59. Licence CC By‑SA.

Étiquettes :

nov.

2016

Sommaire

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

[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)

Farm Link

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 EauFroide le 02 novembre 2016 à 00:03. É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 BAud (site web personnel) le 02 novembre 2016 à 00:24. É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 EauFroide le 02 novembre 2016 à 00:58. É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 EauFroide le 02 novembre 2016 à 12:32. Évalué à 0. Dernière modification le 02 novembre 2016 à 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 EauFroide le 02 novembre 2016 à 00:49. Évalué à -1. Dernière modification le 02 novembre 2016 à 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 Sytoka Modon (site web personnel) le 02 novembre 2016 à 08:14. É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 oinkoink_daotter le 03 novembre 2016 à 13:37. É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 EauFroide le 03 novembre 2016 à 16:48. Évalué à 0. Dernière modification le 03 novembre 2016 à 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 djibb (site web personnel) le 03 novembre 2016 à 22:43. Évalué à -5.
      
      d'un autre côté…Ubuntu pour un serveur…
      - [^] # Re: En Bonus
        
        Posté par barmic le 04 novembre 2016 à 01:00. É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 djibb (site web personnel) le 04 novembre 2016 à 17:40. Évalué à 2.
        
        y'a du fan boy à ce qu'on dirait ;)
        
        [^] # Re: En Bonus
        
        Posté par EauFroide le 04 novembre 2016 à 20:25. É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 Astaoth le 02 novembre 2016 à 01:58. É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 Bernez le 02 novembre 2016 à 09:28. É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 EauFroide le 02 novembre 2016 à 12:29. É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 NeoX le 02 novembre 2016 à 13:55. É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 EauFroide le 02 novembre 2016 à 15:10. Évalué à 1. Dernière modification le 02 novembre 2016 à 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 barmic le 02 novembre 2016 à 15:19. Évalué à 4. Dernière modification le 02 novembre 2016 à 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 EauFroide le 02 novembre 2016 à 15:40. É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 Bernez le 02 novembre 2016 à 16:29. É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 EauFroide le 02 novembre 2016 à 16:34. Évalué à 1. Dernière modification le 02 novembre 2016 à 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 Minux13 le 04 novembre 2016 à 09:12. É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 Glandos le 02 novembre 2016 à 10:30. É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 barmic le 02 novembre 2016 à 11:10. É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 bubar🦥 (site web personnel) le 02 novembre 2016 à 14:13. É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 barmic le 02 novembre 2016 à 14:34. É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 Kerro le 04 novembre 2016 à 01:12. Évalué à 5. Dernière modification le 04 novembre 2016 à 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 Albert_ le 02 novembre 2016 à 17:19. É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 goeb le 02 novembre 2016 à 13:50. É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 wismerhill le 02 novembre 2016 à 13:58. Évalué à 8.
```
ip -s -h link
```
    cf man ip-link
    - [^] # Re: ip link et pas ifconfig
      
      Posté par Anonyme le 02 novembre 2016 à 20:02. É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 barmic le 02 novembre 2016 à 11:39. É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 EauFroide le 02 novembre 2016 à 12:17. É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 EauFroide le 02 novembre 2016 à 12:52. É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 barmic le 02 novembre 2016 à 15:17. É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 EauFroide le 02 novembre 2016 à 15:33. Évalué à 1. Dernière modification le 02 novembre 2016 à 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 oinkoink_daotter le 03 novembre 2016 à 10:48. É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 là
  
  (d'ailleurs, la partie sur les modules a été oubliée dans ce nourjal)
  - [^] # Re: Merci pour le partage
    
    Posté par barmic le 03 novembre 2016 à 11:12. É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)
    - [^] # Re: Merci pour le partage
      
      Posté par oinkoink_daotter le 03 novembre 2016 à 11:41. Évalué à 3.
      
      Pas de changement depuis janvier 2015 ? C'est le blog de qui ? C'est vraiment à jour ?
      
      A ma connaissance, concernant SSH, il n'y a pas vraiment eu de sujet depuis cette époque. Le dernier machin à la mode, ce sont les modules, et c'est traité.
      
      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.
      
      Je n'en connais pas vraiment d'autres orienté crypto. Les autres pointent dessus (genre celui de mozilla pointe dessus)
    - [^] # Re: Merci pour le partage
      
      Posté par Benoît Sibaud (site web personnel) le 06 novembre 2016 à 14:11. Évalué à 3.
      
      Il y a eu des mises à jour en janvier 2016 sur cette entrée de blog. Cf https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md
# coquille

Posté par nono14 (site web personnel) le 02 novembre 2016 à 12:13. É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 Tonton Th (site web personnel, Mastodon) le 04 novembre 2016 à 01:54. É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);
- [^] # Re: Petite surprise...
  
  Posté par oinkoink_daotter le 04 novembre 2016 à 09:42. Évalué à 7.
  
  hop :
  
  […]
  -o allow_root
  allow access to root
  […]
# udevil

Posté par bnurb le 04 novembre 2016 à 12:19. É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 erdnaxeli (site web personnel) le 04 novembre 2016 à 21:51. É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 BAud (site web personnel) le 04 novembre 2016 à 22:11. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.

Sommaire

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

Présentation rapide

Farm Link

Configurer le serveur SSH

Installez les pré-requis

Créez un utilisateur dédié

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

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

Installez les pré-requis

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

Exportez votre clé publique sur le serveur

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

Autoriser les autres utilisateurs à monter un dossier avec fusermount

Connectez-vous en root (admin)

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

Exportez la clé publique de root sur la machine distante

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

Quittez root

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

Installez les pré-requis

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

Accorder les bons droits à notre point de montage

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

Ajoutez le montage afin de le monter au boot

Testez votre montage

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

Installez les pré-requis

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

Accorder les bons droits à notre point de montage

Créez le script

Collez le code suivant en l'adaptant

Rendez le script exécutable

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

Rendez compatible votre client SSH avec le réseau tor

Testez votre montage

Ajoutez vos nouvelles clés au trousseau de votre utilisateur

Côté client

Désactiver la feature UseRoaming

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

Côté server

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

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