TortiseSVN svn + ssh Error: no se puede conectar a un repository en la URL … La connection de networking se cerró inesperadamente

Tengo problemas para acceder a un repository SVN usando TortoiseSVN 1.7.8.

El repository SVN está en una caja de CentOS 6.3 con openssh 5.3p1:81.el6 y parece estar funcionando correctamente.

 # svnadmin --version # svnadmin, version 1.6.11 (r934486) 

Puedo acceder al repository desde otra caja de CentOS con este command:

 svn list svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest 

Pero cuando bash explorar el repository usando TortiseSVN desde una estación de trabajo Win 7, no puedo hacerlo usando la siguiente ruta:

 svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest 

Recibo el siguiente error de TortoiseSVN:

No se puede conectar a un repository en la URL 'svn + ssh: //USER@xxx.xx.xx.xxx/var/svn/joetest' Para depurar mejor los problemas de connection SSH, elimine la opción -q de 'ssh' en [ Túneles] sección de su file de configuration de Subversion. La connection de networking se cerró inesperadamente

Puedo iniciar session vía SSH desde la estación de trabajo usando Putty.

Los resultados son los mismos si bash acceder como root.

He cedido la propiedad del repository /var/svn/ a USER:USER y ejecuté
chmod 2700 -R /var/svn/ .

Debido a que puedo acceder al repository a través de ssh desde otra caja Linux, los permissions no parecen ser el problema.

Cuando miro el file de logging usando tail -fn 2000 /var/log/secure , veo lo siguiente cada vez que TortiseSVN solicita la contraseña:

 Sep 26 17:34:31 dev sshd[30361]: Accepted password for USER from xx.xxx.xx.xxx port 59101 ssh2 Sep 26 17:34:31 dev sshd[30361]: pam_unix(sshd:session): session opened for user USER by (uid=0) Sep 26 17:34:31 dev sshd[30361]: pam_unix(sshd:session): session closed for user USER 

De hecho, puedo iniciar session, pero la session se cierra inmediatamente.

Me llamó la atención que la session se está abriendo para el usuario por root (uid=0) , que puede ser correcta, pero lo mencionaré en caso de que tenga algo que ver con el problema.

svnserve.conf modificar el svnserve.conf , pero, por lo que puedo decir, no se usa cuando se accede al repository a través de svn+ssh , se crea una instancia de svnserve privada para cada session con este método. Del manual:

Todavía hay una tercera forma de invocar svnserve, y eso está en "modo túnel", con la opción -t. Este modo asume que un progtwig de service remoto como RSH o SSH ha autenticado con éxito a un usuario y ahora está invocando un process svnserve privado como ese usuario. El progtwig svnserve se comporta normalmente (se comunica mediante stdin y stdout), y supone que el tráfico se networkingirige automáticamente a través de algún tipo de túnel al cliente. Cuando svnserve es invocado por un agente de túnel como este, asegúrese de que el usuario autenticado tenga acceso completo de lectura y escritura a los files de la database del repository. (Consulte Servidores y permissions: una palabra de advertencia.) Es esencialmente lo mismo que un usuario local que accede al repository a través de file: /// URLs.

Las únicas configuraciones no pnetworkingeterminadas en sshd_config son:

 Protocol 2 # to disable Protocol 1 SyslogFacility AUTHPRIV ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCnetworkingentials yes UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS X11Forwarding no Subsystem sftp /usr/libexec/openssh/sftp-server 

¿Alguna idea?

Finalmente encontré una solución para esto. En las preguntas frecuentes de TortoiseSVN de todos los lugares:
TortoiseSVN Preguntas frecuentes

De las preguntas frecuentes:
SVN + SSH: connection cerrada inesperadamente

Se ha informado que las conexiones svn + ssh de la forma svn + ssh: //username@server.com que estaban trabajando anteriormente, dejan de funcionar con TortoiseSVN 1.5. Esto parece estar relacionado con el plink, y ocurre si tiene un nombre de host pnetworkingeterminado configurado en PuTTY.

Si este es el caso, puede solucionarlo utilizando regedit o regedt32 para borrar HKEY_CURRENT_USER / Software / SimonTatham / Putty / Sessions / Default% 20Settings / HostName.


Otro usuario ha informado de la siguiente corrección del lado del server:

  • ssh en su count
  • cd ~
  • cp / etc / bashrc .bashrc
  • nano .bashrc
  • pon un # antes de la línea "mesg y" (que lo comenta)
  • Ctrl + X para salir, presione Y cuando se le solicite save.

No probé el primer enfoque de editar mi logging.

El segundo enfoque de editar la configuration de bash funcionó para mí.

Una nota sobre el método de configuration de bash:

Si está en un alojamiento compartido, su file .bashrc de usuario probablemente estará cargando el file global / etc / bashrc. No podrá editar el file global, por lo que deberá evitarlo.

Algunos posibles enfoques:

  • Intente agregar mesg n a su file .bashrc de usuario. No estoy seguro de si esto funcionará o si debe colocarse antes o después de que se cargue el file global.

  • No incluya el file global y el código de la configuration en su file de usuario .bashrc .

  • Elimine la configuration de mesg y del mesg y global / etc / bashrc a medida que se carga. Esta pregunta describe cómo hacer eso: usar un file grepped como fuente incluida en bash

Una vieja pregunta, pero aún es la mejor de la stack en Google, así que pensé en compartir mi solución.

Simplemente, fue porque no tenía un directory "home" para mi usuario en el server. Cambiar el cliente SSH al plink.exe que viene con Putty (haga clic derecho en la carpeta | TortoiseSVN | Configuración | Red) me permitió ver el error a medida que aparecían las windows en la pantalla.

En mi caso, la causa fue que el svnuser no tiene un shell (era / bin / false).
Esto no es visible en el logging ssh incluso con debugging ssh -vvv.

Cuando tienes este tipo de problema, tu resultado de debugging se verá así:

 debug1: Entering interactive session. debug1: Remote: Forced command. debug1: Remote: Port forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Pty allocation disabled. debug1: Remote: Forced command. debug1: Remote: Port forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Pty allocation disabled. debug1: Sending environment. debug1: Sending env LANG = en_GB.UTF-8 debug1: Sending command: svnserve -t debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 

Cuando el shell se establece en / bin / bash, el logging cambia a

 debug1: Sending env LANG = en_GB.UTF-8 debug1: Sending command: svnserve -t Path: MyRepo URL: svn+ssh://svnuser@myServer.com/MyRepo