cerhu > linux.debian.user.french

G2PC (08/07/2019, 19h30)
SSHFS : Une alerte est manquante sur l'état des droits de clé privée

Avis aux développeurs de paquets, pour corriger le bogue suivant, ouvert
sur le Github officiel du paquet SSHFS.

Je suis probablement mauvais, mais je crée mes clés privées sur le
serveur, après une première connexion avec un simple mot de passe.
Une fois cela fait, je copie le contenu de mes clés sur la machine locale.
Pour cela, je suis en mode graphique et je crée deux fichiers sur ma
machine: id_rsa_private et id_rsa.pub qui ont, par défaut, les droits 664.

Je remarque le message d'alerte suivant, avec SSH, lorsque je souhaite
me connecter avec mon utilisateur local simple, à l'aide de la clé privée:

ssh USER@SERVEUR -i /home/USERLOCAL/.ssh/SERVEUR/id_rsa_private

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
WARNING: UNPROTECTED PRIVATE KEY FILE!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0664 for '/home/USERLOCAL/.ssh/SERVEUR/id_rsa_private' are
too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

On note ici la traduction de l'anglais vers le français : This private
key will be ignored. -> La clé privée est ignorée !

Avec ça, je comprends mieux!
J'ai identifié ce qui ressemble à un bogue, ou plutôt à un manque de
précision, sur SSHFS, mais, cela me semble important.

sshfs -o allow_other, IdentityFile = / home / USERLOCAL / .ssh / SERVEUR
/ id_rsa_private USERSERVEUR @ SERVEUR: / home / USERSERVEUR / FOLDER /
home / USERLOCAL / FOLDER

Si l'utilisateur qui se connecte est l'utilisateur root de la machine
locale, la phrase secrète est requise lors du montage de dossiers partagés.

Si l'utilisateur qui se connecte est un simple utilisateur de la machine
locale, le mot de passe de l'utilisateur sur le SERVEUR est demandé lors
du montage des dossiers partagés.
Attention ! Ce n'est pas le comportement normal! Si la clé privée qui
est copiée localement a les droits, 600, c'est la phrase secrète qui
sera demandée. C'est ce que nous voulons !

Donc, ici, SSHFS ne nous informe pas de la présence de la clé, qui
possède de mauvais droits, tout comme le fait SSH, lors d?une connexion
en tant que simple utilisateur local.
Pourtant, le comportement semble identique ! SSHFS va ignorer la clé
privée ! OUTCH :/

Je pense vraiment que SSHFS devrait être capable de mettre en garde sur
le problème des droits appliqués à la clé privée, de la même manière que
le fait déjà SSH.

[..]
Daniel Caillibaud (09/07/2019, 10h20)
Le 08/07/19 =C3=A0 19h22, G2PC <g2pc> a =C3=A9crit :
> SSHFS : Une alerte est manquante sur l'=C3=A9tat des droits de cl=C3=A9 p= riv=C3=A9e
>=20
> Avis aux d=C3=A9veloppeurs de paquets, pour corriger le bogue suivant, ou= vert
> sur le Github officiel du paquet SSHFS.
>=20
> Je suis probablement mauvais, mais je cr=C3=A9e mes cl=C3=A9s priv=C3=A9e= s sur le
> serveur, apr=C3=A8s une premi=C3=A8re connexion avec un simple mot de pas= se.
> Une fois cela fait, je copie le contenu de mes cl=C3=A9s sur la machine l= ocale.


Pourquoi ne pas les g=C3=A9n=C3=A9rer directement sur la machine locale ?
C'est bcp plus simple, et les fichiers auront directement les bons droits.

En console, sous le user qui veut g=C3=A9n=C3=A9rer une paire de cl=C3=A9s =
c'est la
commande `ssh-keygen`

> Pour cela, je suis en mode graphique et je cr=C3=A9e deux fichiers sur ma
> machine: id_rsa_private et id_rsa.pub qui ont, par d=C3=A9faut, les droit= s 664.


C'est de l=C3=A0 que vient le pb, la cl=C3=A9 priv=C3=A9e doit =C3=AAtre en=
600 (la publique
peut rester en 644)

[..]
> Avec =C3=A7a, je comprends mieux!
> J'ai identifi=C3=A9 ce qui ressemble =C3=A0 un bogue, ou plut=C3=B4t =C3= =A0 un manque de
> pr=C3=A9cision, sur SSHFS, mais, cela me semble important.


C'est pas un bug mais une fonctionnalit=C3=A9, une cl=C3=A9 priv=C3=A9e que=
tout le monde
peut lire n'est pas priv=C3=A9e et ne sert =C3=A0 rien, elle est donc logiq=
uement
ignor=C3=A9e par ssh.

> sshfs -o allow_other,
> IdentityFile=3D/home/$USERLOCAL/.ssh/$SERVEUR/id_rsa_private
> $USERSERVEUR@$SERVEUR:/home/$USERSERVEUR/$FOLDER /home/$USERLOCAL/$FOLDER


> Si l'utilisateur qui se connecte est l'utilisateur root de la machine
> locale, la phrase secr=C3=A8te est requise lors du montage de dossiers
> partag=C3=A9s.


Tu es s=C3=BBr que c'est la phrase secr=C3=A8te de la cl=C3=A9 priv=C3=A9e =
qui est demand=C3=A9e, et
qu'elle est ensuite utilis=C3=A9e ? =C3=87a m'=C3=A9tonne, =C3=A7a voudrait=
dire que ssh
tol=C3=A8rerait une cl=C3=A9 priv=C3=A9e en 644 si c'est root qui l'utilise=
, =C3=A7a ce serait
un bug (de ssh), j'en doute un peu, je pense qu'il demande aussi le pass
de $USERSERVEUR@$SERVEUR si c'est root qui lance la commande (et que la
cl=C3=A9 priv=C3=A9e est en 644, et que $SERVEUR accepte les connexions par=
mot de
passe, ce qui est par ailleurs une mauvaise id=C3=A9e).

> Si l'utilisateur qui se connecte est un simple utilisateur de la machine
> locale, le mot de passe de l'utilisateur sur le SERVEUR est demand=C3=A9 = lors
> du montage des dossiers partag=C3=A9s.


=C3=87a peut se comprendre, la cl=C3=A9 priv=C3=A9e est ignor=C3=A9e donc s=
shfs fait comme si
tu n'en avais pas pr=C3=A9cis=C3=A9.

[..]
> le fait d=C3=A9j=C3=A0 SSH.
>=20
> [..]


Je comprends ton point de vue, =C3=A0 partir du moment o=C3=B9 tu lui pr=C3=
=A9cises une cl=C3=A9
=C3=A0 utiliser il devrait le faire ou s'arr=C3=AAter avec le bon message d=
'erreur,
mais c'est visiblement pas l'option choisie par les d=C3=A9veloppeurs de ss=
hfs
(je sais pas si c'est un choix d=C3=A9lib=C3=A9r=C3=A9 ou un oubli, tu as b=
ien fait de
poser la question).

--=20
Daniel

Au reste, si l'=C3=A9ducation de la jeunesse est n=C3=A9glig=C3=A9e, ne nou=
s en=20
prenons qu'=C3=A0 nous-m=C3=AAmes et au peu de consid=C3=A9ration que nous=
=20
t=C3=A9moignons =C3=A0 ceux qui s'en chargent.
d'Alembert
G2PC (12/07/2019, 13h00)
>> sshfs -o allow_other,
[..]
> mais c'est visiblement pas l'option choisie par les développeurs de sshfs
> (je sais pas si c'est un choix délibéré ou un oubli, tu as bien fait de
> poser la question).


Merci de ta réponse ! Tu me met un doute de plus, et, à juste raison !
Je partais du principe que ce problème de message d'erreur qui indique
que les droits ne sont pas corrects pour la clé privée lors de la
connexion SSH, ne concernait que le simple utilisateur.
J'avais donc identifié cette absence de message d'erreur, pour un simple
utilisateur voulant établir une connexion SSHFS ce qui entraîneune
demande de mot de passe car la clé n'est pas considérée, au lieu de
demander la passphrase.

Tu me dis, " Ça m'étonne, ça voudrait dire que ssh tolèrerait une clé
privée en 644 si c'est root qui l'utilise, ça ce serait un bug (de ssh)  "

Effectivement ! Pour SSH, et, SSHFS, l'utilisateur root devrait la aussi
transmettre une alerte, une information, pour rappeler que la clé privée
ne possède pas les bons droits.
Je pense que c'est bien un bogue de SSH et SSHFS, car, comme je te le
dis, j'arrive bien à me connecter en root, sans message d'erreur, avec
une clé privée en 664.

Donc, j'ai bien identifié l'absence d'un message d'information sur
SSHFS, et, nous avons identifié l'absence de message d'information lors
de l'utilisation de root, pour une connexion SSH ou SSHFS lorsque la clé
privée a les droits 664.

J'ai remonté la question ici sur Debian, car, il me semblait bien que ça
pouvait intéresser quelques correcteurs.
Ce problème a été identifié sur une Mint Tessa 19.2 mais, je suppose que
pour SSHFS, ça ne change rien. Jai ouvert la question sur le projet
Github de SSHFS, mais, ce n'est pas dit que quelqu'un s'en charge.

Si quelqu'un peut remonter cette information, pour vérifier ce problème
pour SSH ?

[..]
Eric Degenetais (12/07/2019, 14h00)
Le ven. 12 juil. 2019 13:04, G2PC <g2pc> a écrit :

> Noter que le serveur ici acceptait en effet la connexion par mot de
> passe, ce qui est une mauvaise idée, mais, j'en était au début de sa
> configuration. Entre temps, j'ai interdit la connexion par mot de passe.
> J'étais donc justement entrain de reprendre mes différents tutoriels
> pour les éprouver lors d'une installation standard.
> J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison.
> Cette installation m'a permis d'être confronté à cette problématique de
> droits, pour mes propres clés, et, de ce bogue ( manque d'informations )
> pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits..

Bonjour,
il faut tenir compte ici du fait que celui qui se connecte n'est pas
forcément un utilisateur légitime à qui on a envie de fournir des
informations sur la configuration du serveur cible.
Le message concernant la clef est plus à sa place dans les logs du serveur.

Cordialement

Éric Dégenètais
Eric Degenetais (12/07/2019, 14h40)
Désolé, pour le bruit, j'ai eu un coup de mou ...
bien entendu nous sommes là côté client => effectivement il n'est pas
normal de ne pas donner la raison exacte du refus de la clef et de la
bascule sur mot de passe (ou du refus d'authentification).

Cordialement

Éric Dégenètais

______________
Éric Dégenètais
Henix

[..]
[..]

Le ven. 12 juil. 2019 à 13:54, Eric Degenetais <edegenetais> a écrit :
[..]
Discussions similaires
sshfs et droits remplis de ?????

Contenu de mails, correspondance privée, droits d'auteur

Alerte manquante... Dommage

Atteinte à la vie privée, mes droits?


Fuseau horaire GMT +2. Il est actuellement 06h25. | Privacy Policy