TortiseSVN svn+ssh Error: Unable to connect to a repository at URL … Network connection closed unexpectedly

Question

I\'m having problems accessing an SVN repository using TortoiseSVN 1.7.8.

The SVN repository is on a CentOS 6.3 box with openssh 5.3p1:81.el6 and appear

Answer 1

I finally came across a solution for this. In the TortoiseSVN FAQ of all places:
TortoiseSVN Frequently asked questions

From the FAQ:
SVN+SSH: Connection closed unexpectedly

It has been reported that svn+ssh connections of the form svn+ssh://username@server.com which were previously working, stop working with TortoiseSVN 1.5. This seems to be related to plink, and occurs if you have a default hostname set in PuTTY.

If this is the case you can fix it by using regedit or regedt32 to clear HKEY_CURRENT_USER/Software/SimonTatham/Putty/Sessions/Default%20Settings/HostName.

---

Another user has reported the following server-side fix:

• ssh into your account
• cd ~
• cp /etc/bashrc .bashrc
• nano .bashrc
• put a # before the line "mesg y" (which comments it out)
• Ctrl+X to exit, press Y when prompted to save.

---

I didn't try the first approach of editing my registry.

The second approach of editing the bash configuration worked for me.

A note about the bash configuration method:

If you're on shared hosting, your user .bashrc file will likely be loading the global /etc/bashrc file. You won't be able to edit the global file, so you'll need to work around that.

Some possible approaches:

• Try adding mesg n to your user .bashrc file. I'm not sure if this will work or whether it should be placed before or after the global file is loaded.

• Don't include the global file and hard code all the settings in your user .bashrc file.

• Remove the mesg y setting from the global /etc/bashrc file as it's loading. This question discusses how to do that: Use a grepped file as an included source in bash

Answer 2

I had the same issue, and I tried the regedit solution.

In my case the Default Host Name was not to blame, but the regedit showed me a space in the saved session name (%20).

Putty does not care about the session name when you open a connection from there, hence there was no error when connecting from Putty. But the session name is important in your svn+ssh:// url!

In my case the Putty session name was " server", and when I did a svn checkout I used "svn+ssh://server/srv/svn/repo", hence the error.

Answer 3

Maybe this simple solution will work:
Go to your putty and check whether the saved session name matches with the name (svn saved session name in putty) that you are trying to take checkout with...
E.G.: in svn saved session, the name is saved as coreSvn, and the checkout url is: svn+ssh://svnuser@core/COCRETE/branches/R20181121-0.0.2-RELEASE, this won't work. Change the @core to @coreSvn or @coresvn

Answer 4

An old question, but still top of the stack on Google, so I thought I'd share my solution.

Simply, it was because I didn't have a "home" directory for my user on the server. Changing the SSH client to the plink.exe that comes with Putty (right-click on folder | TortoiseSVN | Settings | Network) allowed me to see the error as the windows appeared on screen.

Answer 5

In my case the cause was, that the svnuser hasn't a shell (it was /bin/false).
This isn't visible in the ssh log even with debug ssh -vvv.

When you have this type of problem your debug output will look like this

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

When the shell is set to /bin/bash the log changes to

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

Answer 6

I ran into this problem when moving my old svn repository to a new Ubuntu 20.04 server and was trying to checkout the repo from Windows (with tortoisesvn). I finally realized the new server didn't have svn installed on it and it is needed to serve the repository. Simple fix for me was:

sudo apt install subversion