Sommaire
-
[Tuto/HowTo] SSHFS : mises en place et montage
- Présentation rapide
- Farm Link
- Configurer le serveur SSH
-
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
-
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
[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
- Man Page adduser [EN]
- [Tuto/HowTo] [GNU/Linux] SSH
- [Tuto/HowTo] Monter dossier distant sur Raspberry Pi & Ubuntu/Debian
- [Tuto/HowTo] Garder un contrôle discret sur son serveur avec tor et ssh
- LinuxTricks - Autour du protocole SSH, utiliser le canal de communication
- LinuxFR Journal - SSHFS est un vrai système de fichiers en réseau
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 . É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
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Correction
Posté par BAud (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 :
Merci pour ce tutoriel bien détaillé en tout cas ;-)
[^] # Re: Correction
Posté par EauFroide . É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 . É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
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 . É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_
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_
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
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) . É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 . Évalué à 4.
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 . É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) . Évalué à -5.
d'un autre côté…Ubuntu pour un serveur…
[^] # Re: En Bonus
Posté par barmic . É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) . Évalué à 2.
y'a du fan boy à ce qu'on dirait ;)
[^] # Re: En Bonus
Posté par EauFroide . É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 . É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 . É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 . Évalué à 2.
Merci pour l'infos, je confirme (je viens d'essayer), ça va permettre de diminuer le nombre de procédure :)
Ne pas utiliser celles par défaut qui pourraient être trop faible :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: manipulations inutiles
Posté par NeoX . Évalué à 3.
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 . Évalué à 1. Dernière modification le 02 novembre 2016 à 15:13.
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 . É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 . É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 . É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 . É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 . É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 . Évalué à 10.
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 . É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🦥 (Mastodon) . É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 deip
.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 . Évalué à 6.
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 . Évalué à 5. Dernière modification le 04 novembre 2016 à 01:13.
Je trouve ça sur illisible aussi. Mon astuce à 2 cents :
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_ . Évalué à 1.
Tu rigoles? Franchement une commande ss?
[^] # Re: ip link et pas ifconfig
Posté par goeb . Évalué à 2.
Tiens, à propos du remplacement d'ifconfig, je l'utilise pour voir les statistiques de paquets Tx et Rx, comme ceci :
Comment obtient-on ces informations avec les commandes "ip" ?
[^] # Re: ip link et pas ifconfig
Posté par wismerhill . Évalué à 8.
cf man ip-link
[^] # Re: ip link et pas ifconfig
Posté par Anonyme . É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 . Évalué à 5.
Merci pour ton travail.
J'aurais néanmoins quelques remarques :
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 . Évalué à -1.
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.
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 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.
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 :
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 . É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 . Évalué à 4.
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.
Ç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).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 . Évalué à 1. Dernière modification le 02 novembre 2016 à 15:37.
Je prend note, merci de ton retour :)
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)
Je suis ouvert à toute méthode :) (plus c'est "assimilé" par le système et mieux ça me convient ^ ^ )
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 . Évalué à 3.
Ç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 . É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 . Évalué à 3.
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é.
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) . É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) . Évalué à 2.
la clé ou clef
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# Petite surprise...
Posté par Tonton Th (Mastodon) . É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 . Évalué à 7.
hop :
[…]
-o allow_root
allow access to root
[…]
# udevil
Posté par bnurb . É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!
https://ignorantguru.github.io/udevil/
# Wiki
Posté par erdnaxeli (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 BAud (site web personnel) . Évalué à 4.
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.