Comment enregistrer le nom d'utilisateur et le mot de passe avec Mercurial?


269

J'ai utilisé Mercurial dans un projet personnel et j'ai tapé mon nom d'utilisateur et mon mot de passe chaque fois que je veux envoyer quelque chose au serveur.

J'ai essayé d'ajouter ce qui suit au .hgrcfichier dans mon répertoire personnel, mais il semble être complètement ignoré.

[ui]
username = MY_USER_NAME
password = MY_PASSWORD

Comment faire cela de la bonne façon?

Réponses:


328

Vous pouvez créer une section d'authentification dans votre fichier .hgrcou Mercurial.ini, comme ceci:

[auth]
bb.prefix = https://bitbucket.org/repo/path
bb.username = foo
bb.password = foo_passwd

La partie 'bb' est un identifiant arbitraire et est utilisée pour faire correspondre le préfixe avec le nom d'utilisateur et le mot de passe - pratique pour gérer différents combos nom d'utilisateur / mot de passe avec différents sites (préfixe)

Vous pouvez également spécifier uniquement le nom d'utilisateur, il vous suffira alors de taper votre mot de passe lorsque vous appuyez sur.

Je recommanderais également de jeter un œil à l' extension de porte - clés . Parce qu'il stocke le mot de passe dans le trousseau de clés de votre système au lieu d'un fichier texte brut, il est plus sécurisé. Il est fourni avec TortoiseHg sur Windows, et il est actuellement question de le distribuer en tant qu'extension fournie sur toutes les plates-formes.


3
Pourquoi cela ne fonctionne-t-il pas lorsque le serveur est: ssh: // HGSERVER? le format "ssh: // username: password @ HGSERVER" ne fonctionne pas non plus.
Oren

1
@Oren - regardez le commentaire ci-dessous - si vous utilisez SSH, pourquoi ne pas utiliser la connexion par clé?
David Eads

@santafebound Comme le dit le texte, son "arbitraire" et est utilisé uniquement pour associer le nom d'utilisateur et le mot de passe avec le préfixe afin de fournir toute balise qui vous convient.
Chris McCauley

Je ne recommanderais vraiment pas de stocker les mots de passe en texte brut (c'est ce que fait cette réponse, même si elle mentionne également brièvement une meilleure alternative).
Jasper

170

Il y a trois façons de procéder: utilisez le fichier .hgrc, utilisez ssh ou utilisez l'extension de porte-clés


1. La méthode INSECURE - mettez à jour votre fichier ~ / .hgrc

Le format qui fonctionne pour moi (dans mon fichier ~ / .hgrc) est le suivant

[ui]
username=Chris McCauley <chris.mccauley@mydomain.com>

[auth]
repo.prefix = https://server/repo_path
repo.username = username
repo.password = password


Vous pouvez configurer autant de dépôts que vous le souhaitez en ajoutant plus de triplets de préfixe, nom d'utilisateur, mot de passe en ajoutant une balise unique.

Cela ne fonctionne que dans Mercurial 1.3 et évidemment votre nom d'utilisateur et votre mot de passe sont en texte brut - pas bon.


2. La manière sécurisée - Utilisez SSH pour ÉVITER en utilisant des mots de passe

Mercurial prend entièrement en charge SSH afin que nous puissions tirer parti de la capacité de SSH à se connecter à un serveur sans mot de passe - vous effectuez une configuration unique pour fournir un certificat auto-généré. C'est de loin le moyen le plus sûr de faire ce que vous voulez.


Vous pouvez trouver plus d'informations sur la configuration de la connexion sans mot de passe ici


3. L'extension de porte-clés

Si vous voulez une option sécurisée, mais que vous ne connaissez pas SSH, pourquoi ne pas l'essayer?

De la documentation ...

L'extension demande le mot de passe HTTP sur le premier pull / push vers / depuis le référentiel distant donné (comme cela est fait par défaut), mais enregistre le mot de passe (saisi par la combinaison du nom d'utilisateur et de l'URL du référentiel distant) dans la base de données de mots de passe. Lors de la prochaine exécution, il vérifie le nom d'utilisateur dans .hg / hgrc, puis le mot de passe approprié dans la base de données de mots de passe et utilise ces informations d'identification si elles sont trouvées.

Il y a des informations plus détaillées ici


3
Satoru, Chris ne parle pas de mercurial, mais de ssh: ssh peut être configuré pour que vous n'ayez pas à vous identifier en utilisant un mot de passe (comme décrit par exemple ici: debian-administration.org/articles/152 ).
Tomislav Nakic-Alfirevic

4
La méthode 2 est vraiment le seul moyen de gérer les choses en toute sécurité et de conserver les autorisations de niveau utilisateur sur le système distant.
Peter Rowell

2
La réponse de user570626 à l'aide de l'intégration de porte-clés est bien meilleure que l'une ou l'autre. @Peter Rowell: la configuration de ssh est vraiment pénible si vous avez quelques utilisateurs et référentiels; vous avez besoin d'utilisateurs Unix locaux et devez vous occuper de restreindre les commandes pouvant être exécutées avec .ssh / authorized_keys et un wrapper shell. Pas exactement une solution propre.
Draemon

5
@Peter Rowell: 1. quelle différence cela fait-il? J'ai dit que sa solution était meilleure au plus tôt. 2. Cela n'a rien à voir avec l'environnement d'hébergement, c'est purement côté client (contrairement à votre solution SSH qui nécessite des changements côté serveur pour la supporter). 3. En glissant sur la pêche à la traîne et la vantardise, je dis toujours que ce n'est pas une solution propre. Vous avez besoin d'un utilisateur local et vous devez leur donner un accès shell puis restreindre cela. L'accès à Shell n'est pas toujours une option sensée. Je suis surpris que quelqu'un de votre expérience n'ait pas rencontré d'administrateur système qui ne voulait pas donner accès à votre shell de service.
Draemon

2
@Draemon: Je suppose que nous avons des expériences différentes. Personnellement, je ne travaillerai pas sur un système où je n'ai pas d'invite shell. Cela me rend complètement dépendant de l'autre système pour avoir déjà installé ce dont j'ai besoin. Mon expérience générale est que si je ne peux pas obtenir d'invite, je ne peux presque certainement pas obtenir d'autres services que je considère comme fondamentaux pour mon flux de travail. Différents traits (clés) pour différentes personnes.
Peter Rowell

65

Personne n'a mentionné l'extension de porte-clés. Il enregistrera le nom d'utilisateur et le mot de passe dans le trousseau de clés du système, ce qui est beaucoup plus sûr que de stocker vos mots de passe dans un fichier statique comme mentionné ci-dessus. Effectuez les étapes ci-dessous et vous devriez être prêt à partir. Je l'ai installé sur Ubuntu en environ 2 minutes.

>> sudo apt-get install python-pip
>> sudo pip install keyring
>> sudo pip install mercurial_keyring

**Edit your .hgrc file to include the extension**
[extensions]
mercurial_keyring = 

https://www.mercurial-scm.org/wiki/KeyringExtension


1
Ceci est ma solution préférée. ... et juste pour appuyer ce que @hadrien a dit, après les trois actions décrites, cela fonctionne comme un charme sur Mac OS X.
ngeek

J'appuie également @ngeek pour m'avoir détaché!
Hadrien

Sous Windows au moins, TortoiseHg prend en charge l'extension de trousseau de clés: Paramètres globaux -> Extensions -> mercurial_keyring
user272735

Malheureusement, l'extension de porte-clés présente actuellement un bogue sous Windows où elle ne peut enregistrer qu'un seul mot de passe à la fois. Voir cette question .
Laurens Holst

Cela semble être la meilleure solution, mais lorsque j'essaie de l'utiliser sur OSX, python segfaults lorsque vous essayez d'obtenir le mot de passe du trousseau.
Isaac

30

Un hack simple consiste à ajouter un nom d'utilisateur et un mot de passe à l'url push dans le .hg/hgrcfichier de votre projet :

[paths]
default = http://username:password@mydomain.com/myproject

(Notez que de cette façon, vous stockez le mot de passe en texte brut)

Si vous travaillez sur plusieurs projets sous le même domaine, vous souhaiterez peut-être ajouter une règle de réécriture dans votre ~/.hgrcfichier, pour éviter de répéter cela pour tous les projets:

[rewrite]
http.//mydomain.com = http://username:password@mydomain.com

Encore une fois, puisque le mot de passe est stocké en texte brut, je ne stocke généralement que mon nom d'utilisateur.

Si vous travaillez sous Gnome, j'explique comment intégrer Mercurial et le trousseau de clés Gnome ici:

http://aloiroberto.wordpress.com/2009/09/16/mercurial-gnome-keyring-integration/


J'ai téléchargé l'extension, cependant, lorsque j'ai essayé de faire un push, l'invite de mot de passe refuse de me laisser passer :( Peut-être que je l'ai mal fait. Je n'ai jamais utilisé de porte-clés Gnome auparavant. Merci tout de même.
satoru

Vous voudrez peut-être utiliser les options --debug et --verbose pour hg push pour voir ce qui ne va pas ...
Roberto Aloi

parfait pour le cas présent ... si vous utilisez ssh, vous n'avez pas besoin de
saisir

En supposant que vous ayez le luxe d'un appareil dont vous pouvez retirer la clé publique, bien sûr.
David Given

23

PERSONNE n'a expliqué ou clarifié les termes ci-dessus à un utilisateur novice. Ils sont confus par les termes

.hg / hgrc - ce fichier est utilisé pour le référentiel, à l'emplacement local / espace de travail / dans le dossier .hg du référentiel réel.

~ / .hgrc - ce fichier est différent de celui ci-dessous. ce fichier réside dans le répertoire ~ ou home.

myremote.xxxx = ..... bb.xxxx = ......

C'est l'une des lignes de la section / directive [auth], lors de l'utilisation de l'extension de porte-clés mercurial. Assurez-vous que le nom du serveur que vous y mettez correspond à ce que vous utilisez en faisant "hg clone" sinon le trousseau de clés dira, utilisateur non trouvé. bb ou myremote dans la ligne ci-dessous, sont des "noms d'alias" que vous DEVEZ donner en faisant "hg clone http: /.../../ repo1 bb ou myremote" sinon, cela ne fonctionnera pas ou vous devrez vous assurer que votre local Le fichier .hg / hgrc du référentiel contient le même alias, c'est-à-dire (ce que vous avez donné en faisant clone hg .. comme dernier paramètre).

PS les liens suivants pour des détails clairs, désolé pour la grammaire écrite rapidement.

ex: si à l'intérieur de ~ / .hgrc (répertoire personnel de l'utilisateur sous Linux / Unix) ou mercurial.ini dans Windows dans le répertoire personnel de l'utilisateur, contient, la ligne suivante et si vous le faites

`"hg clone http://.../.../reponame myremote"`

, vous ne serez jamais invité à entrer les informations d'identification de l'utilisateur plus d'une fois par lien de mise en pension http. Dans ~ / .hgrc sous [extensions] une ligne pour "mercurial_keyring =" ou "hgext.mercurial_keyring = /path/to/your/mercurial_keyring.py" .. une de ces lignes devrait être là.

[auth]
myremote.schemes = http https
myremote.prefix = thsusncdnvm99/hg
myremote.username = c123456

J'essaie de savoir comment définir la propriété PREFIX pour que l'utilisateur puisse cloner ou effectuer des opérations Hg sans invites de nom d'utilisateur / mot de passe et sans se soucier de ce qu'il a mentionné dans le http: // .... / ... pour nom_serveur lors de l'utilisation du lien repo Hg. Il peut s'agir de l'IP, du nom de serveur ou du nom de domaine complet du serveur


4

Installation de mercurial_keyring sur Mac OSX à l'aide de MacPorts:

sudo port install py-keyring
sudo port install py-mercurial_keyring

Ajoutez ce qui suit à ~ / .hgrc:

# Add your username if you haven't already done so.
[ui]
username = email@address.com

[extensions]
mercurial_keyring =

J'obtiens "aucun module nommé mercurial_keyring" dans TortoiseHg après avoir exécuté ces commandes et mis à jour mon fichier .hgrc.
Dunc

Assurez-vous d'avoir la bonne version de Python, comme décrit ici: stackoverflow.com/questions/5173197/…
phm

2

Si vous utilisez TortoiseHg, vous devez effectuer ces trois étapes indiquées dans la capture d'écran ci-jointe, cela ajouterait vos informations d'identification pour le référentiel spécifique avec lequel vous travaillez.

entrez la description de l'image ici

Pour ajouter des paramètres globaux, vous pouvez accéder au fichier C: \ users \ user.name \ mercurial.ini et ajouter la section

[auth]
bb.prefix=https://bitbucket.org/zambezia/packagemanager
bb.username = $username
bb.password = $password

J'espère que cela t'aides.


0

Bien que cela puisse fonctionner ou non dans votre situation, j'ai trouvé utile de générer une clé publique / privée à l'aide de Putty's Pageant.

Si vous travaillez également avec bitbucket (.org), cela devrait vous donner la possibilité de fournir une clé publique à votre compte d'utilisateur, puis les commandes qui atteindront le référentiel seront automatiquement sécurisées.

Si Pageant ne démarre pas pour vous lors d'un redémarrage, vous pouvez ajouter un raccourci vers Pageant dans votre "menu Démarrer" de Windows et le raccourci devra peut-être avoir des "propriétés" renseignées avec l'emplacement de votre fichier privé (.ppk) .

Avec cela en place, Mercurial et vos référentiels locaux devront être configurés pour pousser / tirer en utilisant le format SSH.

Voici quelques instructions détaillées sur le site d' Atlassian pour Windows OU Mac / Linux.

Vous n'avez pas à me croire sur parole et il existe sans aucun doute d'autres façons de le faire. Peut-être que ces étapes décrites ici sont plus pour vous:

  1. Démarrer PuttyGen à partir de Démarrer -> PuTTY-> PuttyGen
  2. Générez une nouvelle clé et enregistrez-la en tant que fichier .ppk sans phrase secrète
  3. Utilisez Putty pour vous connecter au serveur auquel vous souhaitez vous connecter
  4. Ajoutez le texte de la clé publique de PuttyGen au texte de ~ / .ssh / authorized_keys
  5. Créez un raccourci vers votre fichier .ppk à partir de Démarrer -> Putty to Start -> Démarrage
  6. Sélectionnez le raccourci .ppk dans le menu de démarrage (cela se produira automatiquement à chaque démarrage)
  7. Vous voyez l'icône Pageant dans la barre d'état système? Faites un clic droit dessus et sélectionnez «Nouvelle session»
  8. Saisissez username @ hostname dans le champ «Host name»
  9. Vous allez maintenant vous connecter automatiquement.

0

Utilisez l'extension de porte-clés. Ajoutez l'entrée ci-dessous au fichier mercurial.ini.

[extensions] mercurial_keyring =

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.