¿Cómo guardar nombre de usuario y contraseña con Mercurial?


269

Utilicé Mercurial en un proyecto personal, y he estado escribiendo mi nombre de usuario y contraseña cada vez que quiero enviar algo al servidor.

Intenté agregar lo siguiente al .hgrcarchivo en mi directorio de inicio, pero parece ser completamente ignorado.

[ui]
username = MY_USER_NAME
password = MY_PASSWORD

¿Cómo hacer esto de la manera correcta?

Respuestas:


328

Puede hacer una sección de autenticación en su archivo .hgrco Mercurial.ini, así:

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

La parte 'bb' es un identificador arbitrario y se usa para unir el prefijo con el nombre de usuario y la contraseña, lo que es útil para administrar diferentes combinaciones de nombre de usuario / contraseña con diferentes sitios (prefijo)

También solo puede especificar el nombre de usuario, luego solo tendrá que escribir su contraseña cuando presione.

También recomendaría echar un vistazo a la extensión del llavero . Debido a que almacena la contraseña en el llavero de su sistema en lugar de un archivo de texto sin formato, es más seguro. Se incluye con TortoiseHg en Windows, y actualmente hay una discusión sobre su distribución como una extensión incluida en todas las plataformas.


3
¿Por qué no funciona esto cuando el servidor es: ssh: // HGSERVER? el formato "ssh: // nombre de usuario: contraseña @ HGSERVER" tampoco funciona ..
Oren

1
@Oren: mire el comentario a continuación: si está utilizando SSH, ¿por qué no utilizar el inicio de sesión basado en claves?
David Eads

@santafebound Como dice el texto, es "arbitrario" y se usa solo para asociar el nombre de usuario y la contraseña con el prefijo, por lo tanto, proporcione cualquier etiqueta que tenga sentido para usted.
Chris McCauley

Realmente no recomendaría almacenar contraseñas en texto plano (que es lo que hace esta respuesta, incluso si también menciona brevemente una mejor alternativa).
Jasper

170

Hay tres formas de hacer esto: use el archivo .hgrc, use ssh o use la extensión de llavero


1. La manera INSEGURA: actualice su archivo ~ / .hgrc

El formato que funciona para mí (en mi archivo ~ / .hgrc) es este

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

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


Puede configurar tantos repositorios como desee agregando más tripletas de prefijo, nombre de usuario y contraseña anteponiendo una etiqueta única.

Esto solo funciona en Mercurial 1.3 y obviamente su nombre de usuario y contraseña están en texto plano, no es bueno.


2. La forma segura: use SSH para EVITAR el uso de contraseñas

Mercurial es totalmente compatible con SSH, por lo que podemos aprovechar la capacidad de SSH para iniciar sesión en un servidor sin una contraseña : realiza una configuración única para proporcionar un certificado autogenerado. Esta es, con mucho, la forma más segura de hacer lo que quieres.


Puede encontrar más información sobre la configuración de inicio de sesión sin contraseña aquí


3. La extensión del llavero

Si desea una opción segura, pero no está familiarizado con SSH, ¿por qué no prueba esto?

De los documentos ...

La extensión solicita la contraseña HTTP en el primer pull / push hacia / desde el repositorio remoto dado (tal como se hace de manera predeterminada), pero guarda la contraseña (clave por la combinación de nombre de usuario y url del repositorio remoto) en la base de datos de contraseñas. En la próxima ejecución, busca el nombre de usuario en .hg / hgrc, luego la contraseña adecuada en la base de datos de contraseñas y usa esas credenciales si las encuentra.

Hay información más detallada aquí.


3
Satoru, Chris no está hablando de mercurial, sino de ssh: ssh se puede configurar para que no tenga que identificarse con una contraseña (como se describe, por ejemplo, aquí: debian-administration.org/articles/152 ).
Tomislav Nakic-Alfirevic

44
El Método 2 es realmente la única forma de manejar las cosas de forma segura y mantener los permisos a nivel de usuario en el sistema remoto.
Peter Rowell

2
La respuesta de user570626 de usar la integración de llavero es mucho mejor que cualquiera de estos. @Peter Rowell: la configuración de ssh es una verdadera molestia si tienes algunos usuarios y repositorios; necesita usuarios locales de Unix y tiene que preocuparse por restringir los comandos que se pueden ejecutar con .ssh / Authorizedkeys y un contenedor de shell. No es exactamente una solución limpia.
Draemon

55
@ Peter Rowell: 1. ¿Qué diferencia hace eso? Dije que su solución era mejor no antes. 2. No tiene nada que ver con el entorno de alojamiento, es puramente del lado del cliente (a diferencia de su solución SSH que requiere cambios en el lado del servidor para admitirlo). 3. Pasando por alto el arrastre y la jactancia, sigo diciendo que no es una solución limpia. Necesita un usuario local y debe darles acceso de shell y luego restringirlo. El acceso a Shell no siempre es una opción sensata. Me sorprende que alguien de su experiencia no se haya encontrado con un administrador de sistemas que no quisiera darle acceso a su shell de servicio.
Draemon

2
@Draemon: Creo que tenemos diferentes experiencias. Personalmente, no trabajaré en un sistema donde no tenga un indicador de shell. Me hace completamente dependiente del otro sistema que ya haya instalado lo que necesito. Mi experiencia general es que si no puedo obtener un aviso, casi seguro que no puedo obtener otros servicios que considero fundamentales para mi flujo de trabajo. Diferentes trazos (clave) para diferentes personas.
Peter Rowell

65

Nadie mencionó la extensión del llavero. Guardará el nombre de usuario y la contraseña en el conjunto de claves del sistema, que es mucho más seguro que almacenar sus contraseñas en un archivo estático como se mencionó anteriormente. Realice los pasos a continuación y debería estar listo para comenzar. Tuve esto en funcionamiento en Ubuntu en aproximadamente 2 minutos.

>> 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
Esta es mi solución favorita. ... y solo para secundar lo que dijo @hadrien, después de las tres acciones descritas, funciona de
maravilla

¡También apoyo a @ngeek por apoyarme!
Hadrien

Al menos en Windows, TortoiseHg admite la extensión de llavero: Configuración global -> Extensiones -> mercurial_keyring
user272735

Desafortunadamente, actualmente la extensión de llavero tiene un error en Windows donde solo puede guardar una contraseña a la vez. Ver esta pregunta .
Laurens Holst

Esta parece ser la mejor solución, pero cuando trato de usarla en OSX, Python segfaults cuando intento obtener la contraseña del llavero.
Isaac

30

Un truco simple es agregar nombre de usuario y contraseña a la url de inserción en el .hg/hgrcarchivo de su proyecto :

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

(Tenga en cuenta que de esta manera almacena la contraseña en texto plano)

Si está trabajando en varios proyectos bajo el mismo dominio, es posible que desee agregar una regla de reescritura en su ~/.hgrcarchivo, para evitar repetir esto para todos los proyectos:

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

Nuevamente, dado que la contraseña se almacena en texto plano, generalmente almaceno solo mi nombre de usuario.

Si está trabajando con Gnome, le explico cómo integrar Mercurial y el llavero Gnome aquí:

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


Sin embargo, descargué la extensión cuando traté de presionar la contraseña. La solicitud de contraseña se niega a dejarme pasar :( Puede ser que lo haya hecho de manera incorrecta. Nunca he usado Gnome Keyring antes. Gracias de todos modos.
satoru

Es posible que desee utilizar las opciones --debug y --verbose para hg push para ver qué está mal ...
Roberto Aloi

perfecto para el caso en cuestión ... si está usando ssh, no necesita pasar una contraseña ... para eso están las claves
beauXjames

Suponiendo que tiene el lujo de un dispositivo del que puede obtener la clave pública, por supuesto.
David dado

23

NADIE anteriormente explicó / aclaró los términos a un usuario novato. Se confunden con los términos

.hg / hgrc: este archivo se utiliza para el Repositorio, en la ubicación local / workspace / en la carpeta .hg del repositorio real.

~ / .hgrc: este archivo es diferente del siguiente. este archivo reside en ~ o directorio de inicio.

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

Esta es una de las líneas bajo la sección / directiva [auth], mientras se usa la extensión mercurial keyring. Asegúrese de que el nombre del servidor que coloque allí coincida con lo que usa mientras hace "hg clone", de lo contrario, el llavero dirá, usuario no encontrado. bb o myremote en la línea a continuación, son "nombre de alias" que DEBE dar al hacer "hg clone http: /.../../ repo1 bb o myremote" de lo contrario, no funcionará o debe asegurarse de que su local El archivo .hg / hgrc del repositorio contiene el mismo alias, es decir (lo que proporcionó al hacer clonación hg ... como último parámetro).

PD: los siguientes enlaces para obtener detalles claros, perdón por la gramática escrita rápidamente.

ej .: si está dentro de ~ / .hgrc (directorio de inicio del usuario en Linux / Unix) o mercurial.ini en Windows en el directorio de inicio del usuario, contiene la siguiente línea y si lo hace

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

, nunca se le solicitarán credenciales de usuario más de una vez por enlace de repositorio http. En ~ / .hgrc bajo [extensiones] una línea para "mercurial_keyring =" o "hgext.mercurial_keyring = /path/to/your/mercurial_keyring.py" ... una de estas líneas debería estar allí.

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

Estoy tratando de averiguar cómo configurar la propiedad PREFIX para que el usuario pueda clonar o realizar cualquier operación Hg sin indicaciones de nombre de usuario / contraseña y sin preocuparse por lo que mencionó en http: // .... / ... para nombre del servidor mientras se usa el enlace de repositorio de Hg. Puede ser IP, nombre de servidor o FQDN del servidor


4

Instalación de mercurial_keyring en Mac OSX usando MacPorts:

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

Agregue lo siguiente a ~ / .hgrc:

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

[extensions]
mercurial_keyring =

Recibo "ningún módulo llamado mercurial_keyring" en TortoiseHg después de ejecutar estos comandos y actualizar mi archivo .hgrc.
Dunc

Asegúrese de tener la versión correcta de Python, como se describe aquí: stackoverflow.com/questions/5173197/…
phm

2

Si está utilizando TortoiseHg, debe realizar estos tres pasos que se muestran en la captura de pantalla adjunta, esto agregaría sus credenciales para el repositorio específico con el que está trabajando.

ingrese la descripción de la imagen aquí

Para agregar configuraciones globales, puede acceder al archivo C: \ users \ user.name \ mercurial.ini y agregar la sección

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

Espero que esto ayude.


0

Si bien puede o no funcionar en su situación, he encontrado útil generar una clave pública / privada usando el concurso de Putty.

Si también está trabajando con bitbucket (.org), debería darle la posibilidad de proporcionar una clave pública a su cuenta de usuario y luego los comandos que lleguen al repositorio se protegerán automáticamente.

Si Pageant no se inicia al reiniciarlo, puede agregar un acceso directo a Pageant en su "Menú de inicio" de Windows y es posible que el acceso directo necesite tener un 'propiedades' rellenado con la ubicación de su archivo privado (.ppk) .

Con esto en su lugar, Mercurial y sus repositorios locales deberán configurarse para empujar / tirar utilizando el formato SSH.

Aquí hay algunas instrucciones detalladas en el sitio de Atlassian para Windows O Mac / Linux.

No tiene que aceptar mi palabra y sin duda hay otras formas de hacerlo. Quizás estos pasos descritos aquí son más para usted:

  1. Inicie PuttyGen desde Inicio -> PuTTY-> PuttyGen
  2. Genere una nueva clave y guárdela como un archivo .ppk sin una frase de contraseña
  3. Use Putty para iniciar sesión en el servidor al que desea conectarse
  4. Agregue el texto de clave pública de PuttyGen al texto de ~ / .ssh / Authorized_keys
  5. Cree un acceso directo a su archivo .ppk desde Inicio -> Masilla para iniciar -> Inicio
  6. Seleccione el acceso directo .ppk del menú Inicio (esto sucederá automáticamente en cada inicio)
  7. ¿Ves el icono del concurso en la bandeja del sistema? Haga clic derecho y seleccione "Nueva sesión"
  8. Ingrese username @ hostname en el campo "Nombre de host"
  9. Ahora iniciará sesión automáticamente.

0

Use la extensión de llavero. Agregue la entrada siguiente al archivo mercurial.ini.

[extensiones] mercurial_keyring =

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.