Forum

Bonjour à tous,

Sur un nouveau PC, je viens de faire une installation toute neuve de Mageia 8, à jour.

Immédiatement après, j'installe Git depuis les dépôts, et tente en console un "git clone" d'un projet sur lequel je travaille (hébergé chez bitbucket), avec cette commande classique :

git clone https://bitbucket.org/nom-d-utilisateur/nom-du-projet.git/

Normalement, git me demande alors le nom d'utilisateur, puis le mot de passe, et le clonage se fait.

Au lieu de cela :

- une fenêtre s'ouvre, qui me demande de saisir la passe-phrase d'une clé SSH (mais je n'en ai jamais défini aucune !) ;

- et ce message d'erreur s'affiche :

ErrorHandler::Throw - warning: QFSFileEngine::open: No file name specified file: line: 0 function:

Ou sa variante, si je tente la même commande en Root :

ErrorHandler::Throw - warning: QStandardPaths: runtime directory '/run/user/1000' is not owned by UID 0, but a directory permissions 0700 owned by UID 1000 GID 1000 file: line: 0 function:

Pourtant, sur le même PC ou j'ai un Kubuntu de test en Dual Boot, la même commande, vers le même dépôt git, fonctionne très bien (elle me demande l'utilisateur et le mdp, et tout roule).

Impossible de cloné mon dépôt sur Mageia, et aucune idée de ce qui bloque.

Mes recherches en ligne n'ont hélas rien donné, sauf ce message voisin (mais resté sans réponse) : https://forums.mageia.org/en/viewtopic.php?f=15&t=13873

Je suis preneur de toute solution.

Je rappelle que mon installation de Mageia est toute neuve (aucune personnalisation encore), sur un PC récent.

Merci.

Édité par Cled Le 07/11/2022 à 18h24

Bonjour Cled,

Je viens de check de mon côté et git fonctionne.




Pendant l'install que j'ai faites en ligne de commande, il m'a proposé plusieurs choix de dépendances avec apache, peut être que cela vient de là?
J'ai fait le premier choix à chaque fois, en selectionnant apache.

Tente un git clone https://github.com/flightlessmango/MangoHud pour vérifier si le problème est lié à ton git ou à bitbucket.

Bon courage,
Ciao

Édité par vinceff Le 07/11/2022 à 09h39

Merci Vinceff.

Effectivement, le "git clone https://github.com/flightlessmango/MangoHud" , qui ne demande visiblement aucune authentification, fonctionne chez moi aussi.

Mais sur d'autres Linux, le dépôt de mon projet est accessible par nom d'utilisateur et mdp, sans me demander de clé SSH (qui n'existe pas dans ce cas). Bizarre.

Bonjour,
Je crois qu'en réalité, tu devrais pouvoir fournir le nom, puis le mot de passe dans les deux boîtes de dialogue qui s'affiche successivement. J'ai ce comportement avec qgit et les dépôts clonés sans SSH, mais pour les soumissions. Github l'interdit maintenant.
L'installation est neuve, mais le /home était-il vierge ? Il se pourrait que tu aies récupéré une ancienne configuration de git dans ce cas.

Bingo ! Merci Papoteur.

Effectivement, la première fenêtre d'invite attend en fait le nom d'utilisateur, et la seconde le mdp. En les lui donnant dans cet ordre, le clonage fonctionne enfin.

Mais pourquoi diable ces deux fenêtres d'invite indiquent-elles : "Enter your SSH pass phrase here", alors qu'il n'y a pas de SSH en place ici ?

Et pourquoi ces infos ne sont pas demandées directement en console, mais dans une fenêtre distincte ?

Sachant que l'installation était vraiment toute neuve, "/home" compris.

En tous cas, ça me permet d'avancer. Encore merci !

Édité par Cled Le 07/11/2022 à 11h17

C'est la bonne question !

Cher Vinceff; ton bashrc ou bashprofile est pété.
Bonne soirée

Quelques précisions pour ceux à qui cela pourrait servir un jour :

L'invite de commande graphique qui remplace celle de la console (et demande à tort la "phrase de passe SSH") correspond à "openssh-askpass".

J'ai essayé par curiosité de désinstaller ce paquetage (plus précisément : "openssh-askpass-common" et "openssh-askpass-qt5").

Au "git clone" suivant, la console commence (assez logiquement) par m'afficher ce message d'erreur :



Mais dans la foulée, il me demande en console, de manière enfin classique :



Et le clonage peut se faire normalement.

La question devenant finalement : pourquoi "ssh-askpass" est appelée ici par défaut sur Mageia (alors que pas sur d'autres distribs), et surtout où modifier cette règle ?

Édité par Cled Le 07/11/2022 à 20h22

Coucou Jybz!
j'ai beau lire et relire, je ne comprends ce qui indique un problème de bashrc ou bash_profile (à mon grand dépit!!!).
Tu as du temps pour expliquer?

Le prompt. C'est celui qui apparait s'il n'y a pas de bashrc et de bashprofile de disponible.

Bonjour,



Chez moi j' obtiens ça.



Sinon je vois ceci sur cette page : https://git-scm.com/docs/gitcredentials



Ca vient peut être de ça ?

Ici je suppose que lorsque un paquet relatif à SSH ou un gestionnaire de credentials ( tel que seahorse qui en est un sauf erreur), la variable SSH_ASKPASS est définie dans le squelette de profil et du coup comme la variable SSH_ASKPASS est définie et qu' elle vient avant la demande de mot de passe en console, la demande est faite.

edit: je remarque ceci



edit 2: Après une petite recherche, il semble que l' installation de openssh-common ajoute dans le profile global ceci



Toutefois j' ai du mal à comprendre comment le /etc/alternatives/ssh-askpass est défini ( vu qu' il ne semble appartenir à aucun paquet ( pour éviter des confilts entre paquets ?))...

Édité par nic80 Le 08/11/2022 à 22h34

Merci Yuusha! Je n'avais jamais vu ce prompt-là! je saurai ce qu'il signifie si ça arrive.

Édité par Girotte Le 09/11/2022 à 00h55

Encore une très bonne enquête de Watson nic80 !
Chez moi
Il faudrait donc définir GIT_ASKPASS. Oui, mais avec quoi ?
Une autre solution ici :
https://stackoverflow.com/questions/5343068/is-there-a-way-to-cache-https-credentials-for-pushing-commits/5343146#5343146

Et pourtant, je n'ai rien fait de spécial pour qu'il soit pété
Une petite astuce pour restaurer le bousin?
Merci de l'info en tout cas.

Il y a peut être un .bashrc de rechange dans /etc/skel