Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

SSHFS : ok en terminal, comment l'automatiser ?

Coeur Noir

Hello,

vous allez voir à quel point je suis nul en ssh et compagnie.

Le contexte : 2 ordis en 20.04, Budgie d'un côté, Xubuntu de l'autre ( beurk mais pas trop le choix, vieux pc ) sur un réseau local.
Sur les 2 ordi disons que l'utilisateur A a 1000 pour uid/gid, l'utilisateur B 1001, C 1002, etc.

L'objectif : dans un dossier de l'utilisateur B sur l'ordi en Xub, monter les datas perso de l'utilisateur B qui sont dans l'ordi Budgie.

À priori j'ai installé tout ce qu'il faut concernant ssh, sshfs puisque si je passe en terminal :

sshfs utilisateur_B@IP:/media/DATA/utilisateur_B Dossier

j'ai une demande de mot de passe et ensuite c'est OK j'ai bien le contenu souhaité dans /home/utilisateur_B/Dossier

Maintenant ce que je souhaiterais c'est éviter à l'utilisateur B d'ouvrir un terminal, passer cette commande et renseigner son mot de passe pour accéder à ses propres ressources sur l'autre ordi.

En suivant https://doc.ubuntu-fr.org/sshfs#utilisation_viaetcfstab ça échoue avec un message du type /usr/bin/sh1:chemin/ressource n'existe pas.
En même temps passer par fstab ( donc utilisateur root ) pour monter une ressource en espace utilisateur ( B ) ne me paraît pas logique.

Donc la ( ou les ) question⋅s :
⋅ quoi mettre
⋅ et où
pour que ce montage soit opérationnel dans la session de B sur l'ordi Xub, sans demande de mot de passe ( j'aimerais vraiment que cela soit transparent, indolore ) ?
Si ça ne se met en route qu'au moment où on clique sur le dossier de montage dans Thunar, ça me va bien, tant que pas besoin de terminal / mot de passe.
Et idéalement, si ça se démonte tout seul en quittant la session, c'est cerise sur le gâteau.

Notes : je peux bien me connecter dans les deux sens via ssh à chaque ordi via

ssh utilisateur_B@IP_de_l'un_ou_l'autre_pc

→ obligé dans tous les cas de renseigner l'IP, avec les noms des ordis ça ne passe pas ( modifier /etc/hosts en accord ? en ajoutant IP=nom_ordi ? ).
→ comment « coupe-t-on » une connexion ssh une fois qu'on n'en a plus besoin ?

Je ne pense pas avoir généré de clés publiques/privées nulle part car je ne comprends pas comment ça marche. Pour établir la connexion ssh j'ai recopié les fingerprint sha256 proposés.
Je n'ai rien modifié dans /etc/ssh/sshd_config et j'ai sur chaque ordi dans /home/utilisateur_B/.ssh un fichier known_hosts

Toute lumière bienvenue ;-) Les autres solutions de partage me paraissent soient disproportionnées ( NFS entre 2 ordi ? Syncthing pour du local ? ) soient inadaptées ( samba entre deux Linux, sérieux ? ).

metalux

Hello Coeur Noir,

As-tu absolument besoin d'un montage sshfs (que je ne connaissais pas) ou un simple accès aux données par Sftp serait-il suffisant?
Pour quitter une session ssh, un simple exit fera l'affaire.
Pour la connexion par clefs, la documentation est bien faîte et n'est pas difficile à suivre. Je l'ai fais il y a un peu plus de 2 ans, je n'ai pas remarqué de difficultés qui pourrait être bloquante même pour un débutant. Qu'est-ce qui t'a posé problème?
Sinon un script ajouté aux applications au démarrage ne serait-il pas suffisant si tu utilises des clefs sans mot de passe?

Coeur Noir

Hello Metalux !

Bah j'ai vraiment pas d'avis sur la question du sshfs ou sftp… tant que ça couvre l'objectif ( simple ) : avoir chez l'user B de l'ordi Xub un accès immédiat à ses données qui sont sur l'ordi Budgie, dans une session user B.
Sans besoin de passer par un terminal ou de renseigner un mot de passe. Genre, juste on clique sur le dossier et c'est tout.

J'avais exclu samba parce que c'est Ubuntu des 2 côtés et que j'ai besoin de gérer les droits ( multi-utilisateurs sur les 2 pc en question ) et qu'un montage cifs ne permet pas l'option permissions comme avec du ntfs « interne ».
J'avais exclu nfs parce que ça m'a l'air autant usine à gaz à paramétrer que samba…

un simple exit fera l'affaire → euh, non apparemment pas, ça me laisse le terminal dans la session de l'ordi distant.

Qu'est-ce qui t'a posé problème ?
→ je génère ces clés sur l'ordi serveur ( Budgie dans mon cas ) ?
→ je récupère comment ces clés ? Enfin la publique surtout.
→ la publique, j'en fais quoi sur l'ordi client ( le xub ) ?
→ il est question d'une passphrase dans la doc' : où, quand, comment, pourquoi ?
→ faut-il modifier /etc/ssh/sshd_config et à quel moment ?

un script ajouté aux applications au démarrage → c'est ce que j'ai cru comprendre.

C'est quand même assez dingue qu'il n'y ait pas un outil graphique tout bête ( ou un pas à pas en commande, qui poserait les questions utiles ) pour partager des dossiers entre 2 ordis sous Ubuntu, dans un même réseau local.

metalux

Coeur Noir a écritun simple exit fera l'affaire → euh, non apparemment pas, ça me laisse le terminal dans la session de l'ordi distant.

Là je ne comprends pas, la connexion ssh est initialisée à partir du PC client. Le terminal est donc ouvert sur celui-ci et non sur le PC serveur qui est l'ordinateur distant.

Les étapes à suivre sont les suivantes:

1-Installer apt://openssh-server sur le PC distant
2-Lancer le serveur avec Systemd

sudo systemctl start ssh

3-Je crois que les paquets gvfs-fuse et gvfs-backends qui sont nécessaires pour monter le dossier distant dans Thunar sont déjà installés par défaut. Dans le doute vérifie qu'ils le sont bien.
4-Se connecter avec la commande suivante:

ssh://utilisateurB@ip_du_serveur/home/utilisateur_B/dossier_distant

Selon l'explorateur de fichiers, il faudra remplacer ssh par sftp. Si tu as changé le port par défaut, il faudra également le préciser. Avec Caja par exemple, j'utilise ceci:

sftp://utilisateurB@ip:port/home/user/dossier_distant

Une fois monté le système une première fois, je me suis crée un signet pour pouvoir y accéder d'un clic. Ce n'est pas un montage automatique car je n'en ai pas besoin mais ça rempli le job. Pour les permissions, je ne sais pas si sshfs est obligatoire, fais tes tests déjà et j'essaierai de mon côté si ça ne fonctionne pas pour toi.
Tu peux en rester là si c'est un accès uniquement local. La connexion sftp te demandera si tu souhaites retenir le mot de passe pour la session ou indéfiniment si je me rappelle bien, choisi indéfiniment pour que celui-ci ne soit plus demandé.

Pour le système d'identification par clefs si tu souhaites te connecter de cette façon:

Coeur Noir a écrit→ je génère ces clés sur l'ordi serveur ( Budgie dans mon cas ) ?

Non, sur le client

Coeur Noir a écrit→ je récupère comment ces clés ? Enfin la publique surtout.

Les clefs sont sauvegardées par défaut dans ~/.ssh, il s'agit de id_rsa.pub pour la clé publique et id_rsa pour la clé privée. il faut ensuite passer la commande ssh-add pour reconnaître ces clefs

Il faut l'envoyer sur le serveur avec ssh-copy-id

Coeur Noir a écrit→ il est question d'une passphrase dans la doc' : où, quand, comment, pourquoi ?

Celle-ci n'est pas obligatoire, elle sert à protéger tes clefs en cas de vol de celles-ci. C'est une double protection. Si tu as une connexion par clefs et que tu désactives l'authentification par mot de passe, ta connexion ssh est sécurisée car personne ne peux se connecter sans ces clefs. Les attaques par brute-force n'ont aucune incidence si tu désactives l'authentification par mot de passe, seul la connexion par clefs étant autorisée. Si malgré tout tu venais à te faire voler ces clefs, chose possible uniquement si il y a un accès à ton PC client, la passphrase est une seconde protection en ajoutant un mot de passe à la clef.

Coeur Noir a écrit→ faut-il modifier /etc/ssh/sshd_config et à quel moment ?

Non pour un usage local avec une connexion par mot de passe.
Oui pour certains cas:
1-Si changement du port
2-Si connexion par clefs, il est alors utile de désactiver la connexion par mot de passe.
3-Pour toutes modifications souhaitées comme interdiction de connexion Root par exemple.

Je n'ai fais que reprendre la documentation. Je crois que ton souci vient du fait que tu t'es mélangé les pinceaux entre le client et le serveur.

Coeur Noir a écritC'est quand même assez dingue qu'il n'y ait pas un outil graphique tout bête ( ou un pas à pas en commande, qui poserait les questions utiles ) pour partager des dossiers entre 2 ordis sous Ubuntu, dans un même réseau local.

Tiens, ça c'est une idée si ça n'existe pas. Un script pour faciliter la tâche et modifier le fichier de config. Je n'ai pas le temps de le faire, et j'ai déjà bien d'autres projets en tête que je n'ai toujours pas mis en place, mais je garde cette idée sur le coude. Qui sait un jour peut-être....

Coeur Noir

Mmm…

Création de la paire de clés → ok
Envoi de la clé publique du client vers le serveur → ok
Modif' sur le serveur de sshd_config → https://doc.ubuntu-fr.org/ssh#authentification_par_mot_de_passe_etou_par_cle ( ChallengeResponseAuthentication et PasswordAuthentication à no )→ Permission denied (publickey).

Je vais donc réactiver la demande de mot de passe… Ok mais ça n'est pas ce que je veux.

____________________

Actuellement avec côté serveur :
⋅ PasswordAuthentication no
⋅ ChallengeResponseAuthentication no
⋅ UsePAM no

j'obtiens côté client :
Permission denied (publickey).

Zakhar

Coeur Noir a écritJ'avais exclu samba parce que c'est Ubuntu des 2 côtés et que j'ai besoin de gérer les droits ( multi-utilisateurs sur les 2 pc en question ) et qu'un montage cifs ne permet pas l'option permissions comme avec du ntfs « interne ».

C'est quand même assez dingue qu'il n'y ait pas un outil graphique tout bête ( ou un pas à pas en commande, qui poserait les questions utiles ) pour partager des dossiers entre 2 ordis sous Ubuntu, dans un même réseau local.

Il y a... mais tu l'as exclu... et tu as bien raison !

Ubuntu étant une distrib "grand public", tu peux utiliser en mode "clicodrome" un "partage WIndow$"... même si aucun des PC n'a cet O.S. privateur.

Sans doute le besoin des masses... et tu as besoin d'un truc plus "geek" et pourtant de base comme gérer les droits Posix que Samba ne fait pas !..

Sinon, une fois que tu auras résolu ton sujet "mot de passe" par connexion via bi-clé, je te conseille de simplement mettre le montage dans le /etc/fstab et laisser l'utilisateur "cliquer pour monter" en précisant user,noauto dans les options de montage.
En effet, sshfs est du "fuse", donc monté avec les droits utilisateur, et ça a sa place dans la session.

Cela permet aussi de gérer le cas où la machine cible du montage n'est pas allumée et éviter des plantages à cause de ça. Lorsque tu sais que la machine cible est allumée, un clic sur le répertoire de montage déclenchera ce que tu as spécifié dans /etc/fstab

Zakhar

Coeur Noir a écrit Actuellement avec côté serveur :
⋅ PasswordAuthentication no
⋅ ChallengeResponseAuthentication no
⋅ UsePAM no

j'obtiens côté client :
Permission denied (publickey).

Tu as mis ta clé dans le répertoire .ssh du client ?

$ ll ~/.ssh
total 32
drwx------  2 zakhar zakhar 4096 déc.  19 14:14 ./
drwxr-xr-x 29 zakhar zakhar 4096 janv. 13 18:41 ../
-rw-------  1 zakhar zakhar  411 mai   26  2020 id_ed25519
-rw-r--r--  1 zakhar zakhar   98 mai   26  2020 id_ed25519.pub
-rw-------  1 zakhar zakhar 2602 nov.   3 16:45 id_rsa
-rw-r--r--  1 zakhar zakhar  570 nov.   3 16:45 id_rsa.pub
-rw-------  1 zakhar zakhar  888 déc.  19 12:38 known_hosts
-rw-------  1 zakhar zakhar  444 sept. 27 15:30 known_hosts.old

id_rsa/rsa_pub pour l'ancienne façon (respectivement privé/public)
et id_ed25519 pour la nouvelle façon de faire (sans doute pas compatible avec tes anciennes versions ?)

Coeur Noir

Hello Zakhar, les 2 ordis sont sous 20.04. Sur mon réseau local, à la maison. Donc dans l'absolu y'aurait zéro chiffrement ou clé que je m'en ficherais.

Cela pour dire : il est où le truc simple pour partager des datas entre 2 ordis Linux ? Nulle part apparemment. À la rigueur Syncthing est presque plus simple dans ce cas…

Et non Samba chez moi j'ai pas envie, j'en mange assez comme ça au boulot… même si je parviens très bien à faire quelque chose de « vivable » avec lui entre ces 2 ordis ( aberration ! ).

Revenons à nos moutons : sur l'ordi client finalement ça n'est plus xubuntu ( thunar ) mais Mate ( caja ). Dans Caja je peux créer un signet pour sftp://machin@IP/media/DATA/un_dossier et lui dire de retenir le mot de passe indéfiniment donc bon an mal an ça fait l'affaire.

Ma curiosité : ssh ou sftp, sans mot de passe et seulement parce que les clés ont été vues/échangées, possible ou pas ?
Que faut-il modifier dans sshd_config ( côté serveur ) pour y parvenir ?

django@ASGARD:~$ grep -v ^# /etc/ssh/sshd_config




Include /etc/ssh/sshd_config.d/*.conf







PubkeyAuthentication yes

AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2




PasswordAuthentication yes

ChallengeResponseAuthentication no



UsePAM no

X11Forwarding yes
PrintMotd no


AcceptEnv LANG LC_*

Subsystem	sftp	/usr/lib/openssh/sftp-server

django@ASGARD:~$

↑ tel quel je me connecte avec demande de mot passe.

Dès lors que je mets no à PasswordAuthentication permission denied.
Sur le client ( pc Mate ) dans ~/.ssh il y a bien id_rsa et id_rsa.pub ( et known_hosts ).
Sur le serveur ( donc le pc Budgie auquel je me connecte depuis Mate ) dans ~/.ssh il y a authorised_keys et known_hosts

id_ed25519 pour la nouvelle façon de faire → euh, j'ai déjà du mal avec la doc mal alambiquée https://doc.ubuntu-fr.org/ssh si maintenant en plus tu suggères qu'elle n'est pas à jour… :lol:

Zakhar

Coeur Noir a écritid_ed25519 pour la nouvelle façon de faire → euh, j'ai déjà du mal avec la doc mal alambiquée https://doc.ubuntu-fr.org/ssh si maintenant en plus tu suggères qu'elle n'est pas à jour… :lol:

Bah hélas oui !

Quand tu fais ton "gen-key" ssh te dit gentiment que maintenant il suggère les "courbes elliptiques" et si tu acceptes il te crée les 2 nouveaux fichiers à la norme ed22519.

Les anciens (RSA) sont toujours supportés cependant.

Les choses évoluent constamment en sécurité, il est difficile de maintenir à jour et pour le "how to" la connexion sans mot de passe en SSH, va plutôt sur ton moteur de recherche favori (le mien Startpage). Tu as des tutoriaux bien plus à jour... en général en English bien sûr !

Pour tes accès local, effectivement si tout est en "filaire", le chiffrement est un peu superflu ou limite paranoïa... SSH sans chiffrement c'est Telnet... je n'ai pas exploré la chose !

Avec FTP c'est effectivement plus facile de faire avec ou sans mot de passe/chiffrement.

Tu as regardé curlftpfs ?

Je l'utilisais à un moment donné, mais il m'a semblé soudainement "buggé"... cependant je n'ai pas vérifié récemment.

MicP

Bonjour

Je viens de réussir le test de montage automatique par sshfs d'un répertoire d'une machine serveur ssh (budgie)
à l'ouverture de la session du compte utilisateur_b sur la machine cliente ssh Xubuntu

La machine serveur ssh est ubuntu 20.04 budgie
et la machine cliente ssh est Xubuntu 20.04

J'avais créé un descriptif complet de la procédure dans ce message,
mais le forum a finit par me déconnecter. (Grrrrr!)
Je reviendrai poster un descriptif après avoir pris mon repas.

pseudofab

MicP a écritmais le forum a finit par me déconnecter. (Grrrrr!)
Je reviendrai poster un descriptif après avoir pris mon repas.

Bonjour MicP.
En cas de déconnexion, pour retrouver le message que j'étais en train d'écrire, je fais:
1/ je rentre à nouveau mon mot de passe du site
2/ je recharge la page concernée avec la flèche gauche de mon moteur de recherche (en haut à gauche toute sur firefox)

xubu1957

Bonjour,

MicP a écritmais le forum a finit par me déconnecter. (Grrrrr!)

> Astuce/Tutoriel : « message perdu, déconnecté du forum »

MicP

Bonjour

Pour ces tests,

la machine serveur ssh est sur un système ubuntu 20.04 budgie dont l'adresse IP est 192.168.122.84
la machine client ssh est sur un système Xubuntu 20.04 dont l'adresse IP est 192.168.122.70

Tout d'abord, j'ai fait une mise à jour des systèmes installés
en lançant, sur chacune des machines, la ligne de commandes suivante :

sudo apt update && sudo apt upgrade

=======
Sur la machine client ssh (xubu)

j'ai installé le paquetage sshfs
en lançant la ligne de commande suivante :

michel@xubu:~$ sudo apt install sshfs

j'ai créé le compte utilisateur_b
en lançant la ligne de commande suivante :

michel@xubu:~$ sudo adduser utilisateur_b

J'ai vérifié que l'ID de ce compte utilisateur est bien 1001

michel@xubu:~$ sudo id utilisateur_b
uid=1001(utilisateur_b) gid=1001(utilisateur_b) groupes=1001(utilisateur_b)
michel@xubu:~$

je me suis connecté sous le compte utilisateur_b
en lançant la ligne de commande suivante :

michel@xubu:~$ su -l utilisateur_b
Mot de passe : 
utilisateur_b@xubu:~$

puis, en utilisant le compte utilisateur_b
j'ai créé, le répertoire qui va me servir plus tard de point de montage par sshfs
en lançant la ligne de commande suivante :

utilisateur_b@xubu:~$ mkdir ~/DATA_G

=======
Sur la machine serveur ssh (budgie)

j'ai installé openssh-server
en lançant la ligne de commandes suivante :

michel@budgie:~$ sudo apt install openssh-server

j'ai créé le compte utilisateur_b
en lançant la ligne de commande suivante :

michel@budgie:~$ sudo adduser utilisateur_b

J'ai vérifié que l'ID de ce compte utilisateur est bien 1001
je me suis connecté sous le compte utilisateur_b
en lançant la ligne de commande suivante :

michel@budgie:~$ sudo id utilisateur_b
uid=1001(utilisateur_b) gid=1001(utilisateur_b) groupes=1001(utilisateur_b)
michel@budgie:~$

je me suis connecté sous le compte utilisateur_b
en lançant la ligne de commande suivante :

michel@budgie:~$ su -l utilisateur_b
Mot de passe : 
utilisateur_b@budgie:~$

puis j'ai créé un répertoire
en lançant la ligne de commande suivante :

utilisateur_b@budgie:~$ mkdir ~/mesDatasB

et j'ai créé un fichier dans ce répertoire
en lançant la ligne de commande suivante :

utilisateur_b@budgie:~$ > ~/mesDatasB/fichServeurSSH.txt

Je vérifie que ce fichier a bien été créé :
en lançant la ligne de commande suivante :

utilisateur_b@budgie:~$ ls -l mesDatasB/
total 0
-rw-rw-r-- 1 utilisateur_b utilisateur_b 0 janv. 14 14:12 fichServeurSSH.txt
utilisateur_b@budgie:~$

=======
Je suis revenu sur la machine client ssh (xubu)
et, en utilisant le compte utilisateur_b
j'ai créé une clef ssh en lançant la ligne de commande suivante
(mais sans donner de passphrase => je tape simplement sur la touche Entrée) :

utilisateur_b@xubu:~$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/utilisateur_b/.ssh/id_rsa): 
Created directory '/home/utilisateur_b/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/utilisateur_b/.ssh/id_rsa
Your public key has been saved in /home/utilisateur_b/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:d8lRDEIDeEUsruLcXyeFIMPOyokly+3N60jjOASzxes utilisateur_b@xubu
The key's randomart image is:
+---[RSA 3072]----+
|       ..** .o.  |
|     .. o .o ..  |
| .    +o..  .    |
|o o  o o.. o o   |
| =... o.S o =    |
|..oB.o.  . o     |
| o+oBo    o .    |
|  E=o=.  . o     |
|  ..+.=o.        |
+----[SHA256]-----+
utilisateur_b@xubu:~$

Puis en utilisant le compte utilisateur_b de la machine client ssh (xubu)
j'ai utilisé la commande ssh-copy-id pour copier la clef générée
vers le compte utilisateur_b de la machine serveur ssh (budgie)
en lançant la ligne de commande suivante :

utilisateur_b@xubu:~$ ssh-copy-id utilisateur_b@192.168.122.84
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/utilisateur_b/.ssh/id_rsa.pub"
The authenticity of host '192.168.122.84 (192.168.122.84)' can't be established.
ECDSA key fingerprint is SHA256:Cg+gOB9aR8OnC8J25wBsN/ecPU22078pYfVxqWAtRtQ.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
utilisateur_b@192.168.122.84's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'utilisateur_b@192.168.122.84'"
and check to make sure that only the key(s) you wanted were added.

utilisateur_b@xubu:~$

Je peux maintenant tester la connexion ssh qui se fera sans mot de passe
en entrant la ligne de commande proposée dans le retour de commande précédent :

utilisateur_b@xubu:~$ ssh utilisateur_b@192.168.122.84
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-60-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 mise à jour peut être installée immédiatement.
0 de ces mises à jour est une mise à jour de sécurité.

*** System restart required ***
Last login: Thu Jan 14 14:11:49 2021 from 192.168.122.1
utilisateur_b@budgie:~$

=======
Je suis revenu sur la machine serveur ssh (bugdie)
et, avec les privilèges du compte utilisateur root
j'ai ajouté dans le fichier /etc/ssh/sshd_config
la directive suivante :

PasswordAuthentication no

Puis, afin qu'il puisse prendre en compte la modification que je viens de faire,
j'ai relancé le serveur ssh en lançant la ligne de commande suivante :

michel@budgie:~$ sudo systemctl restart sshd.service
[sudo] Mot de passe de michel : 
michel@budgie:~$

=======
Je suis revenu sur la machine client ssh (xubu)
et, en utilisant le compte utilisateur_b j'ai testé le montage sshfs
en lançant la ligne de commande suivante :

utilisateur_b@xubu:~$ sshfs utilisateur_b@192.168.122.84:/home/utilisateur_b/mesDatasB/ ~/DATAS_B
utilisateur_b@xubu:~$

Puis j'ai vérifié que je pouvais lister le contenu de ce point de montage
en lançant la ligne de commande suivante :

utilisateur_b@xubu:~$ ls -l ~/DATAS_B
total 0
-rw-rw-r-- 1 utilisateur_b utilisateur_b 0 janv. 14 14:12 fichServeurSSH.txt
utilisateur_b@xubu:~$

Pour que la commande de montage par sshfs soit automatiquement lancée dès que le compte utilisateur_b ouvre sa session,
j'ai cliqué sur le menu Paramètres -> Session et démarrage -> Onglet : Démarrage automatique d'applications
j'ai cliqué sur + Ajouter
et dans le champ de saisie Commande
j'ai collé la ligne de commande sshfs (en spécifiant les chemins absolus) :

/usr/bin/sshfs  utilisateur_b@192.168.122.84:/home/utilisateur_b/mesDatasB/  /home/utilisateur_b/DATAS_B

et j'ai remplis le champ Nom avec le nom de mon choix : Montage sshfs
et dans la liste déroulante du champ Déclencher j'ai laissé le choix par défaut : on login

=======
Voilà.

Coeur Noir

@MicP, grand merci !

Bah mince… C'est exactement ce que j'ai fait ( ou cru faire ).

Pourrais tu donner sur ta machine serveur le retour de

grep -v ^# /etc/ssh/sshd_config

voire

cat /etc/ssh/sshd_config

@Zakhar si tout est en "filaire", le chiffrement est un peu superflu ou limite paranoïa... C'est pour ça que j'écrivais dans l'absolu : un usage du pc client ( vieux portable qui pèse dans les 4,5 kg ) en wifi n'est pas exclu, d'où ma curiosité.

MicP

C'est le même que celui d'origine (fraîche installation)
dans lequel je n'ai ajouté que la directive : PasswordAuthentication no

michel@budgie:~$ cat /etc/ssh/sshd_config
#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server
michel@budgie:~$

michel@budgie:~$ grep -Ev '^$|^#' /etc/ssh/sshd_config        # Ne pas lister les lignes vides ni celles qui sont commentées
Include /etc/ssh/sshd_config.d/*.conf
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem	sftp	/usr/lib/openssh/sftp-server
michel@budgie:~$

Coeur Noir

Bon j'ai forcément loupé une étape quelque part.

J'ai dorénavant le même sshd_config côté serveur ( l'ordi à joindre, donc ) que ce que tu montres MicP.

…et dès lors que je passe PasswordAuthentication à no j'ai un permission denied ( pubkey ) à la moindre tentative de ssh ou sshfs ou sftp.

Je vide les dossiers ~/.shh et je repars de zéro ?

___________________

Pas mieux en vidant les ~/.ssh pour les utilisateurs sur le serveur.

Ça m'a permis de voir que ssh-copy-id envoie bien les id_rsa.pub du client vers serveur.

MicP

Avec la directive PasswordAuthentication no
plus aucune connexion au serveur ssh ne sera possible avec mot de passe
seules les connexions avec authentification par clef ssh seront possibles.
C'est pour ça que j'ajoute cette directive seulement quand la clef a été copiée,
et pour que cette modification soit prise en compte,
j'ai simplement redémarré le serveur ssh

Mais si cette directive est à yes (PasswordAuthentication yes)
et qu'une clef ssh clef a été mise en place,
les connexions ssh nécessitant une authentification par mot de passe
fonctionneront tout aussi bien que les connexions avec authentification par clef.

Coeur Noir

OK. Après l'envoi de la id_rsa.pub, je passe la directive PasswordAuthentication à no sur le serveur, redémarre le sshd.service et dès lors c'est permission denied (pubkey) quand je tente

ssh utilisateur@ip

django@PRESARiO:~$ ssh django@192.168.1.99
The authenticity of host '192.168.1.99 (192.168.1.99)' can't be established.
ECDSA key fingerprint is SHA256:Y(blablabla)Q.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.99' (ECDSA) to the list of known hosts.
django@192.168.1.99: Permission denied (publickey).
django@PRESARiO:~$

Coeur Noir

La grosse blague : j'y arrive dans l'autre sens, depuis l'ordi Budgie vers le Mate, après échange de clés, sans rien modifier à sshd_config sur le Mate, qui est :

django@PRESARiO:~$ cat /etc/ssh/sshd_config
#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server
django@PRESARiO:~$

Je me suis donc empressé de remettre le sshd_config dans le même état sur le Budgie, et niet, il y a toujours demande de mot de passe quand je veux me connecter du Mate ( PRESARiO ) vers Budgie ( ASGARD ).

django@PRESARiO:~$ ssh django@ASGARD
django@asgard's password: 
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-60-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 mise à jour peut être installée immédiatement.
0 de ces mises à jour est une mise à jour de sécurité.

*** System restart required ***
Last login: Thu Jan 14 21:06:05 2021 from 192.168.1.98
django@ASGARD:~$ cat /etc/ssh/sshd_config
#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
# AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server
django@ASGARD:~$

metalux

Coeur Noir a écritBah mince… C'est exactement ce que j'ai fait ( ou cru faire ).

C'est aussi ce que j'avais cru. Bah casse-tête ce SSH, hein 😛
Plus sérieusement, tu as bien les bons droits? Je crois que SSH est assez capricieux avec ça.
Voici ce que j'ai côté serveur(connexion root dans mon cas):

ls -la .ssh
total 16
drwx------  2 root root 4096 avril  9  2020 .
drwx------ 10 root root 4096 janv. 14 21:15 ..
-rw-------  1 root root  753 févr.  1  2019 authorized_keys
-rw-r--r--  1 root root  222 avril  9  2020 known_hosts

côté client:

ls -la .ssh
total 24
drwxrwxr-x  2 metalux metalux 4096 oct.  14 21:59 .
drwxr-xr-x 82 metalux metalux 4096 janv. 14 21:14 ..
-rw-------  1 metalux metalux 3326 févr.  1  2019 id_rsa
-rw-r--r--  1 metalux metalux  753 févr.  1  2019 id_rsa.pub
-rw-------  1 metalux metalux 2220 oct.  14 14:18 known_hosts
-rw-r--r--  1 metalux metalux 1776 sept. 13 23:11 known_hosts.old

Page suivante »