Samedi 21 décembre 2019

Secure Shell (SSH )

Authentification

L’échange de clés permet de s’assurer que le serveur et le client ont partagé un secret sans que personne d’autre ne le sache. Mais il nous faut aussi s’assurer qu’ils ont bien partagé ce secret entre eux UNIQUEMENT.

Authentification du SERVEUR

Le serveur prouve son identité au client en signant la clé résultant de l’échange de clés. Il y a quatre algorithmes pour l’authentification d’une clé publique :

1 DSA avec SHA1

2 ECDSA avec SHA256, SHA384 ou SHA512 (selon la taille de la clé)

3 Ed25519 avec SHA512

4 RSA avec SHA1

Les clés DSA font 1024 bits, on désactive.Le numéro 2 implique le NIST et devrait être aussi désactivé. Autre inconvénient de DSA et ECDSA, ils utilisent l’aléatoire de la machine pour chaque signature. Si cet aléatoire n’est pas d’une grande qualité, il est possible de retrouver la clé. Heureusement, RSA avec SHA1 n’est pas un problème ici puisque la valeur à signer est déjà un hachage SHA2 (voir la section précédente). La fonction de hachage SHA1(SHA2(x)) est aussi sûre que SHA2 seule (le résultat est moins long, certes, mais il n’est pas vulnérable pour autant).

Modifier le fichier serveur /etc/ssh/sshd_config

Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

A la prochaine connexion, accepter les nouvelles empreintes

La configuration ci-dessus désactive aussi la v1 du protocole SSH, troué de partout et qui de toute manière ne devrait JAMAIS être activée. Nous pouvons aussi supprimer les clés inutilisées et générées par OpenSSH lors de son installation afin de regénérer des clés RSA et Ed25519 plus longues et plus robustes.

cd /etc/ssh
rm ssh_host_*key*
ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

Authentification du CLIENT

Le client doit prouver son identité au serveur. Il existe principalement 2 méthodes

Méthode 1 : authentification par mot de passe

Elle peut laisser fuiter les mots de passe en cas de compromission de serveur et est vulnérable aux attaques par bruteforce.

A désactiver dans les meilleurs délais

SERVEUR : Désactiver la connexion par mot de passe ,modifier le fichier /etc/ssh/sshd_config

PasswordAuthentication no
ChallengeResponseAuthentication no

CLIENT : Désactiver la connexion par mot de passe ,modifier le fichier /etc/ssh/ssh_config

Host *
    PasswordAuthentication no
    ChallengeResponseAuthentication no

Méthode 2 : utilisation d’une clé publique

SERVEUR : ,modifier le fichier /etc/ssh/sshd_config

PubkeyAuthentication yes

CLIENT : ,modifier le fichier /etc/ssh/ssh_config

Host *
    PubkeyAuthentication yes
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

Les clés

OpenSSH supporte 8 protocoles d’échange de clés :

1 curve25519-sha256: ECDH avec Curve25519 et SHA2

2 diffie-hellman-group1-sha1: DH 1024 bits avec SHA1

3 diffie-hellman-group14-sha1: DH 2048 bits avec SHA1

4 diffie-hellman-group-exchange-sha1: Custom DH avec SHA1

5 diffie-hellman-group-exchange-sha256: Custom DH avec SHA2

6 ecdh-sha2-nistp256: ECDH avec NIST P-256 et SHA2

7 ecdh-sha2-nistp384: ECDH avec NIST P-384 et SHA2

8 ecdh-sha2-nistp521: ECDH avec NIST P-521 et SHA2

  • Eliminer les protocoles 6 à 8 parce que le NIST est considéré comme nuisible
  • La taille en bits du modulo utilisé par DH : ce qui élimine le protocole 2. 1024 bits ne sont pas suffisants.
  • La sûreté de la fonction de hachage : ce qui élimine les protocoles 2 à 4 car SHA1 est cassé.

Le protocole 1 est le meilleur mais pour des raisons de compatibilité on garde le protocole 5.

Ajouter une ligne au fichier serveur /etc/ssh/sshd_config

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Et deux lignes au fichier client /etc/ssh/ssh_config

Host *
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Pour activer le protocole 5, ouvrir le fichier /etc/ssh/moduli ,s’il existe, et supprimez les lignes où la cinquième colonne est inférieure à 2000 :

$ awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
$ wc -l "${HOME}/moduli" # Assure-vous que le fichier généré ne soit pas vide
$ mv "${HOME}/moduli" /etc/ssh/moduli

fichier /etc/ssh/moduli inexistant , création

ssh-keygen -G /etc/ssh/moduli.all -b 4096
ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
mv /etc/ssh/moduli.safe /etc/ssh/moduli
rm /etc/ssh/moduli.all

ATTENTION Opération très longue en temps

Génération

Utiliser la commande suivante

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

Déploiement

Le déploiement des clés publiques .pub

ssh-copy-id -i .ssh/id_ed25519.pub utilisateur@serveur

Authentification ciblée

Même avec l’authentification par clé publique, vous devriez autoriser les connections SSH uniquement depuis un nombre restreint d’utilisateurs. Ceux susceptibles d’accéder aux serveur via SSH. La directive AllowUsers dans /etc/ssh/sshd_config vous permet de spécifier quels sont les utilisateurs autorisés à se connecter via SSH.

Mais cela peut s’avérer compliqué si vous avez à gérer un nombre important d’utilisateurs. D’autant plus que si vous supprimez l’un d’entre eux, celui-ci ne sera pas retiré de /etc/ssh/sshd_config, ce qui alourdit encore plus la maintenance.

Une solution possible est de se tourner vers AllowGroups à la place, et d’ajouter un groupe ssh-users sur votre machine par exemple, en modifiant **/etc/ssh/sshd_config **:

AllowGroups ssh-users

Pour créer le groupe et lui ajouter un utilisateur :

sudo groupadd ssh-users
sudo usermod -a -G ssh-users utilisateur

Utilisation de SSH avec des clés

Pour faciliter la connexion de l’ordinateur distant à l’ordinateur local, nous pouvons configurer des clés SSH.

Sur l’ordinateur distant, tapez cette commande:

ssh-keygen 

ssh-keygen dans une fenêtre de terminal

Vous serez invité à entrer un mot de passe. Vous pouvez appuyer sur Entrée pour ignorer les questions de phrase secrète, mais cela n’est pas recommandé. Cela signifierait que n’importe qui sur l’ordinateur distant pourrait établir une connexion SSH avec votre ordinateur local sans demander de mot de passe.

Trois ou quatre mots séparés par des symboles constitueront un mot de passe complexe.

Génération de clé ssh dans une fenêtre de terminal

Vos clés SSH seront générées.

Nous devons transférer la clé publique sur l’ordinateur local. Utilisez cette commande:

ssh-copy-id dave@sulaco.local

Vous serez invité à entrer le mot de passe du compte d’utilisateur auquel vous vous connectez, dans ce cas, dave@sulaco.local.

transfert de clés SSH vers l'ordinateur local dans une fenêtre de terminal

La première fois que vous effectuez une demande de connexion de l’ordinateur distant à l’ordinateur local, vous devrez fournir le mot de passe complexe. Vous n’aurez plus besoin de le saisir pour vos futures demandes de connexion, tant que la fenêtre du terminal restera ouverte.

Boîte de dialogue de demande de phrase secrète

CONNEXES: How to Create and Install SSH Keys From the Linux Shell

Chiffrement symétrique

Le chiffrement symétrique est utilisé par SSH pour chiffrer les échanges entre client et serveur une fois l’échange de clé initial et l’authentification terminés. Il existe un nombre d’algorithmes à notre disposition

1 3des-cbc

2 aes128-cbc

3 aes192-cbc

4 aes256-cbc

5 aes-128-ctr

6 aes-192-ctr

7 aes-256-ctr

8 aes128-gcm@openssh.com

9 aes256-gcm@openssh.com

10 arcfour

11 arcfour128

12 arcfour256

13 blowfish-cbc

14 cast128-cbc

15 chacha20-poly1305@openssh.com

  • Sûreté de l’algorithme : ici 1 et 10 à 12 sont éliminés. DES et RC4 sont tous les deux cassés, il faut les désactiver dans tous les cas
  • Taille de clé : minimum 128 bits
  • Taille de bloc : minimum 128 bits. 13 et 14 sont éliminés car leur taille de bloc ne dépasse pas 64 bits
  • Le mode de chiffrement (recommandation)
    • préférer les modes AE (Authenticated Encryption)
    • N’utiliser CTR que pour des raisons de compatibilité. CTR avec Encrypt-then-MAC doit normalement être sûr (nous y reviendrons un peu plus bas).
  • chacha20-poly1305@openssh doit être privilégié à AES-GCM parce que le protocole SSH ne chiffre pas la taille du message lorsqu’il est utilisé avec GCM (ou EtM). Ceci pouvant être source d’attaque, notamment via l’analyse de trafic.

SERVEUR : modifier le fichier /etc/ssh/sshd_config

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

CLIENT : modifier le fichier /etc/ssh/ssh_config

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

Codes d’authentification de message

Le chiffrement fournit la confidentialité, un code d’authentification de message (Message authentication code, MAC) va nous fournir l’intégrité. C’est-à-dire l’assurance que le message qui a été envoyé entre deux pairs n’a pas été modifié en chemin. Et nous avons besoin des deux. **Si nous avons choisi l’AE ci-dessus, inutile d’utiliser un MAC supplémentaire car l’intégrité est déjà garantie. **

  • Pour le cas de CTR, nous devons en plus choisir un algorithme pour calculer et attacher le MAC à chaque message.

    • Encrypt-then-MAC : le message est chiffré, puis le MAC est calculé à partir de celui-ci (une fois chiffré donc)
    • MAC-then-Encrypt : le MAC est calculé à partir du message en clair, puis le tout est chiffré
    • Encrypt-and-MAC : le message est chiffré, puis le MAC calculé à partir du message en clair est attaché

ATTENTION ! Utiliser Encrypt-then-MAC et rien d’autre.

L’utilisation de MAC-then-Encrypt a conduit à suffisamment d’attaques sur TLS alors que Encrypt-then-MAC n’en a pas présenté autant sur SSH. La raison à cela est que si jamais vous recevez le message d’un attaquant, plus vous allez le manipuler et plus vous aller lui laisser de chances d’obtenir des informations. Dans le cas de Encrypt-then-MAC, le MAC est vérifé et s’il est incorrect, rejeté. Une étape, aucun moyen d’obtenir des informations. Alors que dans le cas de MAC-then-Encrypt, comme le MAC est calculé à partir du message en clair il va falloir déchiffrer le message afin de vérifier le MAC. Un échec de déchiffrement (dû à un mauvais padding CBC par exemple) pourrait prendre moins de temps qu’il n’en faut pour la génération de l’échec de vérification du MAC, et donner du temps à l’attaquant pour accéder à des informations. Le problème est le même avec Encrypt-and-MAC .

Les choix possibles :

1 hmac-md5

2 hmac-md5-96

3 hmac-ripemd160

4 hmac-sha1

5 hmac-sha1-96

6 hmac-sha2-256

7 hmac-sha2-512

8 umac-64

9 umac-128@openssh.com

10 hmac-md5-etm@openssh com

11 hmac-md5-96-etm@openssh com

12 hmac-ripemd160-etm@openssh.com

13 hmac-sha1-etm@openssh com

14 hmac-sha1-96-etm@openssh com

15 hmac-sha2-256-etm@openssh.com

16 hmac-sha2-512-etm@openssh.com

17 umac-64-etm@openssh com

18 umac-128-etm@openssh.com

  • Sûreté et solidité de l’algorithme : pas de MD5 ni de SHA1
  • La taille du tag : au moins 128 bits, ce qui élimine umac-64-etm
  • La taille de clé : minimum 128 bits

Extrait pour configuration serveur /etc/ssh/sshd_config :

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

Et pour le client /etc/ssh/ssh_config :

Host *
    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

Précautions

La fonctionnalité UseRoaming présente une vulnérabilité , il faut la désactiver (client) dans /etc/ssh/ssh_config :

Host *
   UseRoaming no

il est important de garder les clés à l’abri des regards indiscrets.

Erreurs et debug

Conclusion

C’est certainement une bonne idée de tester tous les changements apportés. ssh -v apporte un certain nombre de détails, notamment les algorithmes utilisés, pratique pour déboguer rapidement. Soyez très prudent lorsque vous changez la configuration SSH d’une machine distante. Faites en sorte de toujours garder une session active, sans jamais redémarrer sshd avant d’être sûr de soit. Vous pouvez par ailleurs demander à OpenSSH de recharger la configuration sans redémarrer en utilisant un SIGHUP. Pour être à l’abri de tout risque, vous pouvez aussi démarrer temporairement un serveur SSH sur un nouveau port le temps de faire vos tests

Redirection locale ‘-L’ et distante ‘-R’ (Port Forwarding) , tunneling

La différence vient du sens de la connexion. Dans le relayage local, le client tcp et le client ssh sont sur la même machine. Dans le relayage distant ou “remote”, le client ssh est sur la même machine que le serveur tcp.

Comprendre la redirection de port (Port Forwarding

Tunneling SSH

le Tunneling SSH va consister en l’établissement d’un tunnel construit avec le protocole SSH entre un client et un serveur

Tunnel SSH inversé


Qu’est-ce que le tunnel SSH inversé (Reverse SSH Tunneling)? (et comment l’utiliser)
Besoin de SSH sur un ordinateur Linux distant inaccessible?
Demandez-lui de vous appeler, puis creusez cette connexion pour obtenir votre propre session SSH distante.

Traduction du post “What Is Reverse SSH Tunneling? (and How to Use It)”
Dave McKay July 18, 2019, 9:00am EDT

Quand utiliser le tunneling SSH inverse

Parfois, les ordinateurs distants peuvent être difficiles à atteindre. Le site sur lequel ils se trouvent peut avoir des règles de pare-feu strictes, ou peut-être l’administrateur local a-t-il configuré des règles complexes de traduction d’adresses réseau . Comment pouvez-vous atteindre un tel ordinateur si vous devez vous y connecter?

  • Établissons des étiquettes
    • Votre ordinateur est l’ordinateur local car il est proche de vous.
    • L’ordinateur auquel vous allez vous connecter est l’ordinateur distant, car il se trouve dans un emplacement différent de celui où vous vous trouvez.

Pour différencier les ordinateurs locaux des ordinateurs distants utilisés dans cet article, l’ordinateur distant s’appelle «howtogeek» et exécute Ubuntu Linux (avec des fenêtres de terminal violettes). L’ordinateur local s’appelle «Sulaco» et exécute Manjaro Linux (avec des fenêtres de terminal jaunes).

Normalement, vous établissez une connexion SSH à partir de l’ordinateur local et vous connectez à l’ordinateur distant. Ce n’est pas une option dans le scénario de réseau que nous décrivons. Le problème spécifique du réseau importe peu: cela est utile lorsque vous ne pouvez pas utiliser SSH directement sur l’ordinateur distant.

Mais si la configuration réseau de votre côté est simple, l’ordinateur distant peut se connecter à vous. Toutefois, cela ne suffit pas à vos besoins, car cela ne vous fournit pas une session de ligne de commande opérationnelle sur l’ordinateur distant. Mais c’est un début. Vous avez une connexion établie entre les deux ordinateurs.

La réponse réside dans le tunnel SSH inversé (Reverse SSH Tunneling).

Qu’est-ce que le tunnel SSH inversé?

Le tunneling SSH inversé vous permet d’utiliser la connexion établie pour établir une nouvelle connexion entre votre ordinateur local et l’ordinateur distant.

Parce que la connexion d’origine vous a été fournie par l’ordinateur distant, l’utiliser pour aller dans le sens opposé l’utilise «en sens inverse». Et parce que SSH est sécurisé, vous établissez une connexion sécurisée au sein d’une connexion sécurisée existante. Cela signifie que votre connexion à l’ordinateur distant agit comme un tunnel privé dans la connexion d’origine.

Et nous arrivons au nom de «tunnel SSH inversé (reverse SSH tunneling)».

Comment ça marche?

Le tunneling SSH inversé repose sur l’ordinateur distant qui utilise la connexion établie pour écouter les nouvelles demandes de connexion émanant de l’ordinateur local.

L’ordinateur distant écoute sur un port réseau de l’ordinateur local. S’il détecte une requête SSH sur ce port, il relaie cette requête à lui-même, via la connexion établie. Ceci fournit une nouvelle connexion de l’ordinateur local à l’ordinateur distant.

Utilisation du SSH Reverse Tunneling

SSH sera déjà installé sur votre ordinateur local Linux, mais vous devrez peut-être démarrer le démon SSH (sshd) si l’ordinateur local n’a jamais utilisé les connexions SSH.

sudo systemctl start sshd 

Pour que le démon SSH démarre à chaque redémarrage de votre ordinateur, utilisez cette commande:

sudo systemctl enable sshd

Sur l’ordinateur distant, nous utilisons la commande suivante.

ssh -R 43022:localhost:22 dave@sulaco.local
  • L’option -R (reverse) indique à ssh que de nouvelles sessions SSH doivent être créées sur l’ordinateur distant.
  • 43022:localhost:22 indique à ssh que les demandes de connexion au port 43022 de l’ordinateur local doivent être transmises au port 22 de l’ordinateur distant. Le port 43022 a été choisi car il est répertorié comme étant non alloué . Ce n’est pas un numéro spécial.
  • dave@sulaco.local est le compte d’utilisateur auquel l’ordinateur distant va se connecter sur l’ordinateur local.

Vous pouvez être averti de ne jamais vous être connecté à l’ordinateur local auparavant. Vous pouvez également voir un avertissement lorsque les détails de la connexion sont ajoutés à la liste des hôtes SSH reconnus. Ce que vous voyez, le cas échéant, dépend du fait que des connexions aient déjà été établies entre l’ordinateur distant et l’ordinateur local.

Vous serez invité à entrer le mot de passe du compte que vous utilisez pour vous connecter à l’ordinateur local.

Détails de la connexion SSH dans une fenêtre de terminal

Notez que lorsque la connexion est établie, l’invite de commande passe de dave@howtogeek à dave@sulaco

Nous sommes maintenant connectés à l’ordinateur local à partir de l’ordinateur distant. Cela signifie que nous pouvons lui donner des commandes. Utilisons la commande who pour voir les connexions sur l’ordinateur local.

who

la commande who dans une fenêtre de terminal

Nous pouvons voir que la personne avec le compte d’utilisateur appelé Dave a ouvert une session sur l’ordinateur local et que l’ordinateur distant s’est connecté (avec les mêmes informations d’identification d’utilisateur) à partir de l’adresse IP 192.168.4.25.

CONNEXES: How to Determine the Current User Account in Linux

Connexion à l’ordinateur distant

Comme la connexion à partir de l’ordinateur distant est réussie et qu’il écoute les connexions, vous pouvez essayer de vous connecter à l’ordinateur distant à partir de l’ordinateur local.

L’ordinateur distant écoute sur le port 43022 de l’ordinateur local. Donc, quelque peu contre-intuitif, pour établir une connexion avec l’ordinateur distant, nous demandons à ssh d’établir une connexion avec l’ordinateur local, sur le port 43022. Cette demande de connexion sera transmise à l’ordinateur distant.

ssh localhost -p 43022 

Nous sommes invités à entrer le mot de passe du compte utilisateur, puis à l’ordinateur local à partir de l’ordinateur distant.

connexion inverse du tunnel SSH à l'ordinateur distant

Notez que l’invite de commande est passée de dave@sulaco à dave@howtogeek. Nous avons atteint notre objectif d’établir une connexion SSH avec un ordinateur distant difficile à atteindre.

SSHFS pour monter des dossiers distants dans le système de fichier (ssh + fuse)

Sshfs est un outil permettant d’utiliser le protocole ssh comme un système de fichiers

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 :

Liens

Configuration SSHFS de base client serveur

Note : Les paquets “openssh-client” et “fuse-utils” sont requis, mais il sont déjà installés par défaut

client

Il faut disposer d’un serveur ssh focntionnel

serveur

Installer sshfs

sudo apt update && sudo apt install sshfs # debian
sudo pacman -S sshfs  # archlinux/manjaro

Test rapide

Sur le système client, créer un répertoire dans lequel va être monté le système de fichiers :

mkdir /home/utilisateur/Test

Monter un répertoire distant (ici ~/Public):

sshfs utilisateur@ip_distante:/home/utilisateur/Public /home/utilisateur/Test

Le mot de passe de l’utilisateur est alors demandé.

Ouvrir l gestionnaire de fichiers pour accèder à vos fichiers distants.

Enfin, penser à démonter :

fusermount -u /home/utilisateur/Test

SSHFS avec clés et port différent

sshfs -oIdentityFile=<clé privée> utilisateur@domaine.tld:<dossier distant> <dossier local> -C -p <port si différent de 22>

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