#1 Le 09/01/2021, à 22:43
- Coeur Noir
SSHFS : ok en terminal, comment l'automatiser ?
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 Dossierj'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 ? ).
Dernière modification par Coeur Noir (Le 09/01/2021, à 22:45)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#2 Le 10/01/2021, à 00:38
- metalux
Re : SSHFS : ok en terminal, comment l'automatiser ?
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?
Dernière modification par metalux (Le 10/01/2021, à 01:10)
Hors ligne
#3 Le 10/01/2021, à 02:35
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
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.
Dernière modification par Coeur Noir (Le 10/01/2021, à 02:38)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#4 Le 10/01/2021, à 12:25
- metalux
Re : SSHFS : ok en terminal, comment l'automatiser ?
un 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 ssh3-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_distantSelon 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_distantUne 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:
→ je génère ces clés sur l'ordi serveur ( Budgie dans mon cas ) ?
Non, sur le client
→ 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
→ 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.
→ 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.
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.
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....
Hors ligne
#5 Le 13/01/2021, à 17:36
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
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#authentif … ou_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).
Dernière modification par Coeur Noir (Le 13/01/2021, à 17:57)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#6 Le 13/01/2021, à 19:36
- Zakhar
Re : SSHFS : ok en terminal, comment l'automatiser ?
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 ».
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
Dernière modification par Zakhar (Le 13/01/2021, à 19:39)
"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)
Hors ligne
#7 Le 13/01/2021, à 19:43
- Zakhar
Re : SSHFS : ok en terminal, comment l'automatiser ?
Actuellement avec côté serveur :
⋅ PasswordAuthentication no
⋅ ChallengeResponseAuthentication no
⋅ UsePAM noj'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.oldid_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 ?)
Dernière modification par Zakhar (Le 13/01/2021, à 19:44)
"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)
Hors ligne
#8 Le 13/01/2021, à 22:47
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
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… 
Dernière modification par Coeur Noir (Le 13/01/2021, à 22:48)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#9 Le 14/01/2021, à 09:49
- Zakhar
Re : SSHFS : ok en terminal, comment l'automatiser ?
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…
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.
Dernière modification par Zakhar (Le 14/01/2021, à 09:52)
"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)
Hors ligne
#10 Le 14/01/2021, à 12:33
- MicP
Re : SSHFS : ok en terminal, comment l'automatiser ?
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.
Hors ligne
#11 Le 14/01/2021, à 13:53
- Compte supprimé
Re : SSHFS : ok en terminal, comment l'automatiser ?
mais 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)
#12 Le 14/01/2021, à 14:03
- xubu1957
Re : SSHFS : ok en terminal, comment l'automatiser ?
Bonjour,
mais le forum a finit par me déconnecter. (Grrrrr!)
Conseils pour les nouveaux demandeurs et pas qu'eux
Important : Pensez à passer vos sujets en [Réso|u] lorsque ceux-ci le sont, au début du titre en cliquant sur Modifier sous le premier message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci. Membre de Linux-Azur
En ligne
#13 Le 14/01/2021, à 15:20
- MicP
Re : SSHFS : ok en terminal, comment l'automatiser ?
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 sshfsj'ai créé le compte utilisateur_b
en lançant la ligne de commande suivante :
michel@xubu:~$ sudo adduser utilisateur_bJ'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-serverj'ai créé le compte utilisateur_b
en lançant la ligne de commande suivante :
michel@budgie:~$ sudo adduser utilisateur_bJ'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 ~/mesDatasBet j'ai créé un fichier dans ce répertoire
en lançant la ligne de commande suivante :
utilisateur_b@budgie:~$ > ~/mesDatasB/fichServeurSSH.txtJe 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 noPuis, 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_Bet 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à.
Dernière modification par MicP (Le 14/01/2021, à 22:35)
Hors ligne
#14 Le 14/01/2021, à 15:49
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
@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_configvoire
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é.
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#15 Le 14/01/2021, à 17:34
- MicP
Re : SSHFS : ok en terminal, comment l'automatiser ?
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:~$ Dernière modification par MicP (Le 14/01/2021, à 17:59)
Hors ligne
#16 Le 14/01/2021, à 19:48
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
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.
Dernière modification par Coeur Noir (Le 14/01/2021, à 20:34)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#17 Le 14/01/2021, à 20:09
- MicP
Re : SSHFS : ok en terminal, comment l'automatiser ?
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.
Hors ligne
#18 Le 14/01/2021, à 20:39
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
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@ipdjango@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:~$ Dernière modification par Coeur Noir (Le 14/01/2021, à 20:44)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#19 Le 14/01/2021, à 21:15
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
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:~$Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#20 Le 14/01/2021, à 21:16
- metalux
Re : SSHFS : ok en terminal, comment l'automatiser ?
Bah 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_hostscô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.oldDernière modification par metalux (Le 14/01/2021, à 21:21)
Hors ligne
#21 Le 14/01/2021, à 21:31
- MicP
Re : SSHFS : ok en terminal, comment l'automatiser ?
Pour l'instant, ne t'embête pas avec la directive PasswordAuthentication no
c'est seulement quand tu auras une authentification par mot de passe opérationnelle,
puis ensuite envoyé la clef ssh avec ssh-copy-id
que le message de retour ressemblant à l'extrait ci-dessous
t'indiquera que tu peux te connecter par clef :
…
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.
…Tu devrais alors pouvoir te connecter sans qu'aucun mot de passe ne te soit demandé,
et si c'est bien le cas, alors tu pourras décider de t'offrir le luxe
de bloquer toutes les authentifications par mot de passe en ajoutant la directive.
=======
As-tu fait, au préalable, la mise à jour des systèmes concernés : client et serveur ?
Dernière modification par MicP (Le 15/01/2021, à 13:18)
Hors ligne
#22 Le 14/01/2021, à 22:33
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
@metalux ASGARD est le serveur, PRESARiO le client, à la base. Mais j'ai depuis testé dans les deux sens.
django@ASGARD:~$ ls -la .ssh
total 24
drwx------ 2 django django 4096 janv. 14 20:52 .
drwxrwxr-x 31 django django 4096 janv. 14 21:29 ..
-rw------- 1 django django 2250 janv. 14 20:00 authorized_keys
-rw------- 1 django django 2602 janv. 14 20:52 id_rsa
-rw-r--r-- 1 django django 567 janv. 14 20:52 id_rsa.pub
-rw-r--r-- 1 django django 444 janv. 14 21:08 known_hosts
django@ASGARD:~$ ssh django@PRESARiO
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
10 mises à jour peuvent être installées immédiatement.
1 de ces mises à jour est une mise à jour de sécurité.
Pour afficher ces mises à jour supplémentaires, exécuter : apt list --upgradable
Last login: Thu Jan 14 21:08:29 2021 from 192.168.1.99
django@PRESARiO:~$ ls -la .ssh
total 24
drwx------ 2 django django 4096 janv. 14 20:54 .
drwxr-xr-x 19 django django 4096 janv. 14 19:32 ..
-rw------- 1 django django 567 janv. 14 20:53 authorized_keys
-rw------- 1 django django 3389 janv. 13 17:02 id_rsa
-rw-r--r-- 1 django django 750 janv. 13 17:02 id_rsa.pub
-rw-r--r-- 1 django django 444 janv. 14 21:05 known_hosts
django@PRESARiO:~$ @MicP j'allais dire oui tout est à jour mais non apparemment… zou…
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#23 Le 16/01/2021, à 10:10
- metalux
Re : SSHFS : ok en terminal, comment l'automatiser ?
Sans certitude
drwx------ 2 django django 4096 janv. 14 20:54 .Ça pourrait être une explication au vu de cette réponse, bien que ce n'est pas un refus mais une demande de mot de passe dans son cas:
https://forum.ubuntu-fr.org/viewtopic.p … 8#p3910798
ou bien suivre ceci:
https://blog.luxifer.fr/2013/12/31/perm … -ssh-linux
Dernière modification par metalux (Le 16/01/2021, à 10:24)
Hors ligne
#24 Le 16/01/2021, à 18:05
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
Merci pour ces liens.
La curiosité ici c'est que ça marche dans un sens ( ASGARD vers PRESARiO ) et pas dans l'autre ( PRESARiO vers ASGARD ).
Alors que visiblement les droits et permissions sont identiques sur les 2 machines concernant les dossiers .ssh et leur contenu.
Cela dit les explications font sens ( si à un moment il y a un user ssh qui dot accéder, alors il faut bien que ce dossier soit en lecture pour autres, et les fichiers clé publique + clés autorisées. )
Quand je dis ça marche = se connecte en ssh sans demander le mot de passe.
Je teste, et tiens au jus.
edit : attends attends, je vois que sur ASGARD, j'ai ajouté - manuellement - mes divers utilisateurs au groupe ssh ( gid 119 ). Je ne l'ai peut-être pas fait sur PRESARiO. Est-ce nécessaire ?
Dernière modification par Coeur Noir (Le 16/01/2021, à 18:16)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#25 Le 16/01/2021, à 18:30
- Coeur Noir
Re : SSHFS : ok en terminal, comment l'automatiser ?
Effectivement, mes users sur le PRESARiO ne faisaient pas partie du groupe ssh.
Hélas, malgré modification des droits et ajout au groupe, pas mieux : depuis PRESARiO vers ASGARD il y a toujours demande de mot de passe, et pas dans l'autre sens.
Le fait que ça passe dans un sens et pas dans l'autre suggère-t-il une forme de filtrage ( pare-feu ) ?
…nope aucun pare-feu actif…
Dernière modification par Coeur Noir (Le 16/01/2021, à 19:02)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne