Wie speichere ich Benutzername und Passwort mit Mercurial?


269

Ich habe Mercurial in einem persönlichen Projekt verwendet und jedes Mal, wenn ich etwas auf den Server übertragen möchte, meinen Benutzernamen und mein Passwort eingegeben.

Ich habe versucht, der .hgrcDatei in meinem Home-Verzeichnis Folgendes hinzuzufügen , aber es scheint völlig ignoriert zu werden.

[ui]
username = MY_USER_NAME
password = MY_PASSWORD

Wie mache ich das richtig?

Antworten:


328

Sie können einen Authentifizierungsabschnitt in Ihrer .hgrcoder Ihrer Mercurial.iniDatei erstellen, wie folgt:

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

Der 'bb'-Teil ist eine beliebige Kennung und wird verwendet, um das Präfix mit dem Benutzernamen und dem Passwort abzugleichen - praktisch zum Verwalten verschiedener Kombinationen aus Benutzername und Passwort mit verschiedenen Sites (Präfix)

Sie können auch nur den Benutzernamen angeben, dann müssen Sie nur Ihr Passwort eingeben, wenn Sie drücken.

Ich würde auch empfehlen, einen Blick auf die Schlüsselringverlängerung zu werfen . Da das Kennwort anstelle einer Nur-Text-Datei im Schlüsselring Ihres Systems gespeichert wird, ist es sicherer. Es wird mit TortoiseHg unter Windows gebündelt, und es wird derzeit diskutiert, es als gebündelte Erweiterung auf allen Plattformen zu verteilen.


3
Warum funktioniert das nicht, wenn der Server: ssh: // HGSERVER ist? Das Format "ssh: // Benutzername: Passwort @ HGSERVER" funktioniert auch nicht.
Oren

1
@Oren - siehe folgenden Kommentar - Wenn Sie SSH verwenden, warum nicht die schlüsselbasierte Anmeldung verwenden?
David Eads

@santafebound Wie der Text sagt, ist es "willkürlich" und wird nur verwendet, um den Benutzernamen und das Passwort mit dem Präfix zu verknüpfen. Geben Sie daher jedes Tag an, das für Sie sinnvoll ist.
Chris McCauley

Ich würde wirklich nicht empfehlen, Passwörter im Klartext zu speichern (was diese Antwort tut, auch wenn sie kurz eine bessere Alternative erwähnt).
Jasper

170

Es gibt drei Möglichkeiten, dies zu tun: Verwenden Sie die .hgrc-Datei, verwenden Sie ssh oder verwenden Sie die Schlüsselring-Erweiterung


1. Der INSECURE-Weg - aktualisieren Sie Ihre ~ / .hgrc-Datei

Das Format, das für mich funktioniert (in meiner ~ / .hgrc-Datei), ist dieses

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

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


Sie können so viele Repos konfigurieren, wie Sie möchten, indem Sie weitere Triplets mit Präfix, Benutzername und Kennwort hinzufügen, indem Sie ein eindeutiges Tag voranstellen.

Dies funktioniert nur in Mercurial 1.3 und offensichtlich sind Ihr Benutzername und Ihr Passwort im Klartext - nicht gut.


2. Der sichere Weg - Verwenden Sie SSH, um die Verwendung von Passwörtern zu vermeiden

Mercurial unterstützt SSH vollständig, sodass wir die Möglichkeit von SSH nutzen können , sich ohne Kennwort bei einem Server anzumelden. Sie führen eine einmalige Konfiguration durch, um ein selbst generiertes Zertifikat bereitzustellen. Dies ist bei weitem der sicherste Weg, um das zu tun, was Sie wollen.


Weitere Informationen zum Konfigurieren der kennwortlosen Anmeldung finden Sie hier


3. Die Schlüsselringverlängerung

Wenn Sie eine sichere Option wünschen, aber mit SSH nicht vertraut sind, versuchen Sie es doch einmal.

Aus den Dokumenten ...

Die Erweiterung fordert beim ersten Pull / Push zum / vom angegebenen Remote-Repository zur Eingabe des HTTP-Kennworts auf (genau wie dies standardmäßig der Fall ist), speichert jedoch das Kennwort (verschlüsselt durch die Kombination aus Benutzername und URL des Remote-Repositorys) in der Kennwortdatenbank. Beim nächsten Durchlauf wird in .hg / hgrc nach dem Benutzernamen und dann in der Kennwortdatenbank nach einem geeigneten Kennwort gesucht und diese Anmeldeinformationen verwendet, falls sie gefunden wurden.

Weitere Informationen finden Sie hier


3
Satoru, Chris spricht nicht von mercurial, sondern von ssh: ssh kann so eingerichtet werden, dass Sie sich nicht mit einem Passwort identifizieren müssen (wie zB hier beschrieben: debian-administration.org/articles/152 ).
Tomislav Nakic-Alfirevic

4
Methode 2 ist wirklich die einzige Möglichkeit, Dinge sicher zu handhaben und Berechtigungen auf Benutzerebene auf dem Remote-System beizubehalten.
Peter Rowell

2
Die Antwort von user570626 auf die Verwendung der Schlüsselringintegration ist viel besser als beide. @Peter Rowell: Das SSH-Setup ist ein echtes Problem, wenn Sie einige Benutzer und Repositorys haben. Sie benötigen lokale Unix-Benutzer und müssen sich mit der Einschränkung der Befehle herumschlagen, die mit .ssh / authorized_keys und einem Shell-Wrapper ausgeführt werden können. Nicht gerade eine saubere Lösung.
Draemon

5
@ Peter Rowell: 1. Welchen Unterschied macht das? Ich sagte, seine Lösung sei nicht früher besser. 2. Es hat nichts mit der Hosting-Umgebung zu tun, es ist rein clientseitig (im Gegensatz zu Ihrer SSH-Lösung, für deren Unterstützung Änderungen auf der Serverseite erforderlich sind). 3. Ich beschönige das Trolling und das Prahlen und sage immer noch, dass es keine saubere Lösung ist. Sie benötigen einen lokalen Benutzer und müssen ihm Shell-Zugriff gewähren und diesen dann einschränken. Shell-Zugriff ist nicht immer eine sinnvolle Option. Ich bin überrascht, dass jemand Ihrer Erfahrung keinen Systemadministrator gefunden hat, der Ihrem Service-Shell keinen Zugriff gewähren wollte.
Draemon

2
@ Draemon: Ich denke wir haben unterschiedliche Erfahrungen. Persönlich werde ich nicht auf einem System arbeiten, auf dem ich keine Shell-Eingabeaufforderung habe. Es macht mich völlig abhängig von dem anderen System, bereits installiert zu haben, was ich brauche. Meine allgemeine Erfahrung ist, dass ich, wenn ich keine Eingabeaufforderung erhalten kann, mit ziemlicher Sicherheit keine anderen Dienste erhalten kann, die ich für grundlegend für meinen Workflow halte. Verschiedene (Tasten-) Striche für verschiedene Leute.
Peter Rowell

65

Niemand erwähnte die Schlüsselringverlängerung. Der Benutzername und das Kennwort werden im Systemschlüsselring gespeichert. Dies ist weitaus sicherer als das Speichern Ihrer Kennwörter in einer statischen Datei, wie oben erwähnt. Führen Sie die folgenden Schritte aus, und Sie sollten bereit sein, loszulegen. Ich hatte dies unter Ubuntu in ca. 2 Minuten zum Laufen gebracht.

>> 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
Dies ist meine Lieblingslösung. ... und nur um zu bestätigen, was @hadrien gesagt hat, nach den beschriebenen drei Aktionen funktioniert es wie ein Zauber unter Mac OS X.
Ngeek

Ich unterstütze auch @ngeek, weil er mich abgeordnet hat!
Hadrien

Zumindest unter Windows unterstützt TortoiseHg die Schlüsselringerweiterung: Globale Einstellungen -> Erweiterungen -> mercurial_keyring
user272735

Leider weist die Schlüsselringerweiterung derzeit einen Fehler unter Windows auf, bei dem jeweils nur ein Kennwort gespeichert werden kann. Siehe diese Frage .
Laurens Holst

Dies scheint die beste Lösung zu sein, aber wenn ich versuche, es unter OSX zu verwenden, tritt Python-Fehler auf, wenn versucht wird, das Kennwort aus dem Schlüsselbund abzurufen.
Isaac

30

Ein einfacher Hack besteht darin, der Push-URL in der .hg/hgrcDatei Ihres Projekts einen Benutzernamen und ein Passwort hinzuzufügen :

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

(Beachten Sie, dass Sie auf diese Weise das Passwort im Klartext speichern.)

Wenn Sie an mehreren Projekten unter derselben Domäne arbeiten, möchten Sie möglicherweise eine Umschreiberegel in Ihre ~/.hgrcDatei einfügen, um zu vermeiden, dass dies für alle Projekte wiederholt wird:

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

Da das Passwort im Klartext gespeichert ist, speichere ich normalerweise nur meinen Benutzernamen.

Wenn Sie unter Gnome arbeiten, erkläre ich hier, wie Sie Mercurial und den Gnome-Schlüsselring integrieren:

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


Ich habe die Erweiterung jedoch heruntergeladen, als ich versuchte, einen Push zu machen. Die Passwortabfrage weigert sich, mich passieren zu lassen :( Vielleicht habe ich es falsch gemacht. Ich habe Gnome Keyring noch nie benutzt. Trotzdem danke.
Satoru

Vielleicht möchten Sie --debug und --verbose Optionen für hg push verwenden, um zu sehen, was falsch läuft ...
Roberto Aloi

Perfekt für den vorliegenden Fall ... Wenn Sie ssh verwenden, müssen Sie kein Passwort eingeben ... das sind die Schlüssel für
beauXjames

Vorausgesetzt, Sie haben den Luxus eines Geräts, von dem Sie natürlich den öffentlichen Schlüssel abziehen können.
David gegeben

23

NIEMAND oben erläuterte / geklärte Begriffe für einen Anfänger. Sie werden durch die Begriffe verwirrt

.hg / hgrc - Diese Datei wird für das Repository am lokalen / Arbeitsbereich / im .hg-Ordner des tatsächlichen Repositorys verwendet.

~ / .hgrc - Diese Datei unterscheidet sich von der folgenden. Diese Datei befindet sich im Verzeichnis ~ oder im Ausgangsverzeichnis.

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

Dies ist eine der Zeilen unter [auth] Abschnitt / Direktive, während die Erweiterung des Quecksilberschlüsselrings verwendet wird. Stellen Sie sicher, dass der Servername, den Sie dort eingegeben haben, mit dem übereinstimmt, den Sie beim Ausführen von "hg clone" verwenden. Andernfalls wird durch den Schlüsselbund angezeigt, dass der Benutzer nicht gefunden wurde. bb oder myremote in der folgenden Zeile sind "Aliasnamen", die Sie angeben müssen, während Sie "hg clone http: /.../../ repo1 bb oder myremote" ausführen. Andernfalls funktioniert es nicht oder Sie müssen sicherstellen, dass Ihr lokaler Name vorhanden ist Die .hg / hgrc-Datei des Repositorys enthält denselben Alias, dh (was Sie beim Ausführen von hg clone .. als letzten Parameter angegeben haben).

PS die folgenden Links für klare Details, entschuldigen Sie die schnell geschriebene Grammatik.

Beispiel: Wenn sich in ~ / .hgrc (Home-Verzeichnis des Benutzers unter Linux / Unix) oder mercurial.ini in Windows im Home-Verzeichnis des Benutzers die folgende Zeile befindet und wenn Sie dies tun

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

Dann werden Sie nie mehr als einmal pro http-Repo-Link zur Eingabe von Benutzeranmeldeinformationen aufgefordert. In ~ / .hgrc unter [Erweiterungen] sollte eine Zeile für "mercurial_keyring =" oder "hgext.mercurial_keyring = /path/to/your/mercurial_keyring.py" .. eine dieser Zeilen sollte vorhanden sein.

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

Ich versuche herauszufinden, wie die PREFIX-Eigenschaft so festgelegt werden kann, dass Benutzer Hg-Vorgänge ohne Eingabeaufforderung für Benutzername / Kennwort klonen oder ausführen können, ohne sich Gedanken darüber zu machen, was er in http: // .... / ... für erwähnt hat Servername bei Verwendung des Hg-Repo-Links. Dies kann IP, Servername oder der vollqualifizierte Domänenname des Servers sein


4

Installation von mercurial_keyring unter Mac OSX mit MacPorts:

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

Fügen Sie ~ / .hgrc Folgendes hinzu:

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

[extensions]
mercurial_keyring =

Ich erhalte in TortoiseHg "kein Modul mit dem Namen mercurial_keyring", nachdem ich diese Befehle ausgeführt und meine .hgrc-Datei aktualisiert habe.
Dunc


2

Wenn Sie TortoiseHg verwenden, müssen Sie die drei im beigefügten Screenshot gezeigten Schritte ausführen. Dadurch werden Ihre Anmeldeinformationen für das spezifische Repository hinzugefügt, mit dem Sie arbeiten.

Geben Sie hier die Bildbeschreibung ein

Um globale Einstellungen hinzuzufügen, können Sie auf die Datei C: \ users \ user.name \ mercurial.ini zugreifen und den Abschnitt hinzufügen

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

Hoffe das hilft.


0

Obwohl es in Ihrer Situation möglicherweise funktioniert oder nicht, habe ich es als nützlich empfunden, mit Putty's Pageant einen öffentlichen / privaten Schlüssel zu generieren.

Wenn Sie auch mit bitbucket (.org) arbeiten, sollten Sie die Möglichkeit haben, Ihrem Benutzerkonto einen öffentlichen Schlüssel bereitzustellen. Befehle, die das Repository erreichen, werden dann automatisch gesichert.

Wenn Pageant bei einem Neustart nicht für Sie gestartet wird, können Sie Ihrem Windows-Startmenü eine Verknüpfung zu Pageant hinzufügen. Für die Verknüpfung müssen möglicherweise Eigenschaften mit dem Speicherort Ihrer privaten (PPP-) Datei angegeben werden .

Wenn dies vorhanden ist, müssen Mercurial und Ihre lokalen Repositorys so eingerichtet sein, dass sie im SSH-Format Push / Pull ausführen.

Hier finden Sie einige detaillierte Anweisungen auf der Atlassian -Website für Windows ODER Mac / Linux.

Sie müssen nicht mein Wort dafür nehmen und es gibt zweifellos andere Möglichkeiten, dies zu tun. Vielleicht sind diese hier beschriebenen Schritte mehr für Sie:

  1. Starten Sie PuttyGen von Start -> PuTTY-> PuttyGen
  2. Generieren Sie einen neuen Schlüssel und speichern Sie ihn als PPK-Datei ohne Passphrase
  3. Verwenden Sie Putty, um sich bei dem Server anzumelden, zu dem Sie eine Verbindung herstellen möchten
  4. Hängen Sie den Text des öffentlichen Schlüssels von PuttyGen an den Text von ~ / .ssh / authorized_keys an
  5. Erstellen Sie eine Verknüpfung zu Ihrer PPK-Datei über Start -> Putty to Start -> Startup
  6. Wählen Sie die PPK-Verknüpfung aus dem Startmenü (dies geschieht automatisch bei jedem Start).
  7. Sehen Sie das Festzugssymbol in der Taskleiste? Klicken Sie mit der rechten Maustaste darauf und wählen Sie "Neue Sitzung".
  8. Geben Sie Benutzername @ Hostname in das Feld "Hostname" ein
  9. Sie werden sich jetzt automatisch anmelden.

0

Schlüsselringverlängerung verwenden. Fügen Sie den folgenden Eintrag zur Datei mercurial.ini hinzu.

[Erweiterungen] mercurial_keyring =

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.