mac - Mercurial sobre ssh cliente y servidor en Windows

bitvise ssh server

Question

Estoy intentando configurar Mercurial para usarlo tanto con un servidor de Windows (freeSSHd) como con un cliente (tanto con la línea de comandos como con TortoiseHG). Estoy usando las versiones más recientes de todo ... todas descargadas en los últimos días. Usando autenticación de clave pública, he podido conectarme al servidor y puedo usar plink para ejecutar "hg version" y obtener una respuesta, pero cuando intento clonar un repositorio desde el servidor ssh, aparece el comando para colgar. Corriendo con -v rendimientos:

hg -v clone ssh://<username>@<server>//hg/repositoryA testRepositoryA
running "plink.exe -i "<path to private key file>" <username>@<server> "hg -R /hg/repositoryA serve --stdio""

Con nada más por venir. La ejecución del comando hg serve directamente en el servidor produce un servidor Mercurial aparentemente receptivo, pero los clientes no parecen realizar más solicitudes.

La ejecución de "hg serve" en el directorio del repositorio y la clonación sobre http funciona perfectamente.

¿Qué debo buscar para ayudar a depurar esto? ¿Hay algo que los clientes (hg y TortoiseHG) no están enviando para continuar la transmisión de solicitudes?

Información adicional: Si cambio a un repositorio no válido en la máquina de destino, se muestra el error apropiado, por lo que parece que el hg remoto se está ejecutando y está evaluando correctamente la ruta.

Ejecutar con --debug y --traceback da como resultado:

sending hello command
sending between command

Se cuelga aquí, hasta que CTRL-C.

Traceback (most recent call last):
  File "mercurial/dispatch.pyo", line 46, in _runcatch
  File "mercurial/dispatch.pyo", line 452, in _dispatch
  File "mercurial/dispatch.pyo", line 320, in runcommand
  File "mercurial/dispatch.pyo", line 504, in _runcommand
  File "mercurial/dispatch.pyo", line 457, in checkargs
  File "mercurial/dispatch.pyo", line 451, in <lambda>
  File "mercurial/util.pyo", line 402, in check
  File "mercurial/commands.pyo", line 636, in clone
  File "mercurial/hg.pyo", line 187, in clone
  File "mercurial/hg.pyo", line 63, in repository
  File "mercurial/sshrepo.pyo", line 51, in __init__
  File "mercurial/sshrepo.pyo", line 73, in validate_repo
KeyboardInterrupt
interrupted!

Respondiendo a Ryan: No parece haber ningún uso de CPU o un aumento en el uso de memoria en el servidor. Parece estar esperando que el cliente envíe una solicitud o algo similar.

19/11/2009: Más información: El problema está definitivamente en el lado de la ecuación de freeSSHd / server. Conectarse a bitbucket sobre ssh con el mismo conjunto de teclas funciona bien. Sigo trabajando en esto.

Answer 1

Ahora mismo tengo los mismos síntomas, aunque hg fue un poco más útil después de Ctrl + C; aparentemente, Plink me estaba esperando para decir "y / n" para "guardar el servidor en caché". Desafortunadamente, hg no pudo pasar mi y / n a ella de manera interactiva (ni me diga que Plink imprimió algo importante ...)

Solución:

1. Plink al host una vez y guarda la información del servidor en caché
2. agregue -batch a la línea de comando de plink para que la próxima vez que esto suceda, se anule.

También agrego mi clave al concurso, por lo que no necesito escribir la contraseña en ningún otro lugar.

Ejemplo completo de archivo .hgrc (Win + R, notepad %USERPROFILE%/.hgrc ):

[ui]
ssh=C:/Path/To/plink.exe -C -batch -ssh -i C:/Path/To/My/putty-private-ssh-key.ppk

Answer 2

En mi caso pude conectarme a mi servidor una vez, pero la segunda vez falló.

Tengo la misma configuración y funcionó perfectamente ... pero solo una vez. No hay nada en mis sesiones almacenadas.

[ui]
ssh=C:/Path/To/plink.exe -C -batch -ssh -i C:/Path/To/My/putty-private-ssh-key.ppk

Answer 3

La solución que funcionó para mí fue deshabilitar la opción "Usar nuevo motor de consola" que está dentro de la pestaña SSH. Otra cosa es el camino. ssh: // ssh_user @ SSH_Server_Address: SSH_Port / Win_Drive_Letter: / Path_To_HG_Repository

Un ejemplo concreto:

ssh: //[email protected]: 5522 / D: / Repository / MyProyect / trunk

Actualmente utilizo MercurialHG no el CLI. Espero que esta ayuda.

JQ

La solución en realidad lo tengo desde here

Answer 4

Me encontré con este mismo problema. No estoy seguro de cómo se relaciona con el tuyo, pero esto es lo que funcionó para mí. En primer lugar, voy a explicar mi configuración. Tengo un repositorio en mi sitio en vivo mysite.com Tengo un repositorio local en mi máquina local en una carpeta mysite.com Tengo otros repositorios, así que agrego la configuración [ui] a /.hg/.hgrc en cada carpeta del repositorio en mi máquina local en lugar del archivo Mercurial.ini.

Primero, si ya se conectó a través de Putty, guarde la sesión porque Plink puede usar sesiones almacenadas. Usa Pageant y agrega tu clave. Intente ejecutar plink desde la línea de comandos para conectarse utilizando la sesión almacenada. Por ejemplo, guardé mi sesión como "mysite" en Putty.

C:/>plink mysite
    Using username "mysite".
    Last login: Fri Feb 26 21:16:05 2010 from ca-xxx-xx-x-xxx.sta.host.net
    ←]0;mysite@server:~[mysite@server ~]$

Si eso funciona, intente lo siguiente en su archivo .hgrc

[path]
default = ssh://mysite@myhost
[ui]
username = RB <[email protected]>
ssh=plink.exe -ssh -i mysite

Plink está configurado en mi RUTA, y como la sesión de mi sitio ya estaba almacenada en Putty, sabe qué buscar.

Estaba tratando de hacer un tirón, así que estaba probando usando:

hg pull --debug --traceback

Espero que ayude.

Edit: Lo siento, vi demasiado tarde que estabas usando tortoiseHG en lugar de masilla. Espero que ayude de todos modos.

Answer 5

Otra opción sería probar las versiones Cygwin de hg y ssh. Puede registrar problemas de SSH en esa versión con la opción -e; por ejemplo, hg clone -e ''ssh -vvv'' ssh: // you @ server / repo ...

Answer 6

Tal vez sea el caso que ''hg'' no esté en el camino. Puede ver desde la línea de comandos que se invoca que ''hg'' se ejecuta como ''hg'', lo que significa que tiene que estar en la ruta del servidor. Intente usar la opción --remotecmd para clonar y darle la ruta completa al ejecutable hg en el servidor (buena suerte si se obtiene el correcto --remotecmd las ventanas).

Es posible que la prueba de la hg version plink hg version funcione porque se lanzó como un shell interactivo que tiene un camino diferente, al menos eso obstaculiza con frecuencia a las personas en Unix.