SVN+SSH Connection Giving Error 210002, Network Connection Closed Unexpectedly

OK, I’m having a problem settings up SVN+SSH.

I have SVN running on a Linux server and trying to connect from a Mac laptop running Snow Leopard. XCode tries to connect, but gives the message “Error 210002, network connection closed unexpectedly.”

  • iOS Can't perform HTTP GET request -Error Domain=NSURLErrorDomain Code=-1012
  • How to handle user authentication persistance in IOS?
  • A method for making HTTP requests on Unity iOS?
  • HTTP “Content-Disposition: attachment” and downloading files on iOS web browser
  • RestKit: Getting HTTP status code when a request fails
  • Using Swift to handle GZipped (containing JSON) HTTP response
  • Nothing online seems to explain. I connect using xcode with HTTP and it works correctly for all repositories.

    Here’s my SVN vesrion:

    svn, version 1.5.4 (r33841)
    compiled Aug  7 2009, 01:44:11
    
    Copyright (C) 2000-2008 CollabNet.
    Subversion is open source software, see http://subversion.tigris.org/
    This product includes software developed by CollabNet (http://www.Collab.Net/).
    
    The following repository access (RA) modules are available:
    
    * ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
      - handles 'http' scheme
      - handles 'https' scheme
    * ra_svn : Module for accessing a repository using the svn network protocol.
      - with Cyrus SASL authentication
      - handles 'svn' scheme
    * ra_local : Module for accessing a repository on local disk.
      - handles 'file' scheme
    

    I currently have it set up to use http, which works without problems.

    http://username@example.com/svn/project
    

    I can ssh to the server using username and password, and run commands such as

    svn list file:///home/svn/project
    

    and I get a listing of the contents of that project. So, I don’t think it’s a permissions problem.

    Files on server are at /home/svn/project.

    I’m trying to get this to work in XCode. Doesn’t work using the path as /home/svn/project or just /svn/project as works in http.

    But, from the laptop, the following command does list info as expected:

    svn list svn+ssh://username@example.com/home/svn/project
    username@example.com's password:
    branches
    tags
    trunk
    Killed by signal 15.
    

    The program svnserve isn’t running, but the user I’m logging in with has the ability to run it. If I do start it in foreground mode, it doesn’t seem to change anything.

    Any ideas what I’m missing. Would love to be able to run svn+ssh and turn off http access.

    Cheers!

    EDIT

    For some more information, I found that it’s only one repository. All other repositories on the server seem to be working correctly with SVN+SSH.

    It seems to be an XCode bug, but I don’t know for sure. It’s something about how XCode reads SSH connection information that may be cached in the computer.

    6 Solutions Collect From Internet About “SVN+SSH Connection Giving Error 210002, Network Connection Closed Unexpectedly”

    To suppress “killed by signal 15” messages please set SVN_SSH="ssh -q" as mentioned here.

    That ‘Killed by signal 15’ is a clue that something is not quite right even with your command line usage. I remember fixing the same issue, but don’t remember the exact cause. I think it had to do with how I was handling my non-standard ssh port and having a different username on my local computer and the remote server.

    Does your svn host have a non-standard ssh port and/or different username? I switched from using a SVN_SSH variable to set the port to putting a proper entry in my .ssh/config file that set both the username and port for the ssh connection.

    Host example.com
      User username
      Port port
    

    I’m not sure whether xcode respects your .ssh/config though.

    Does your server have a firewall, and if so, does it limit the number of SSH connection attempts, such as by the method described here? We were experiencing the exact same problem of having the connection dropped for svn checkout, but not for svn ls, over svn+ssh://. We adjusted the connection settings on the firewall to be more lenient, allowing more connections per minute, and this instantly cleared our problems. It seems that SVN is very aggressive in initiating connections during certain operations, and less so for others.

    None of solutions given here worked with svn+ssh, but I could connect and checkout via https:

    $ svn checkout --username myusername https://scm.gforge.inria.fr/svn/concha
    

    Here’s how I fixed this (on Mac OS X, but fix should work on any client).

    This particular issue arises when you are using a non-standard port (let’s say 12001 for sake of example) for your SSH server.

    Apparently the SVN client experiences syntax errors when given a port address on a command line like this one:

    svn list svn+ssh://username@domainname.com:12001/home/username/svn/myproject
    

    So, to fix this, you need to create a client-side config file for SSH like this:

    cd ~
    cd .ssh
    vi config (create a config file like the one that follows)
    :w
    :q
    

    Config file located in ~/.ssh/config:

    Host domain.com
      User username
      Port 12001
    

    Then, issue your svn+ssh command WITHOUT the port like this:

    svn list svn+ssh://username@domain.com/home/username/svn/myproject
    

    I had the same problem with “Killed by signal 15.”, btw. Adding host, user and port to the .ssh/config did not resolve this problem.

    OSX 10.5/10.6 doesn’t document the flag -q (that’s why at least I ignored this advice, as sl suggested, for a long time), but it does work on OSX 10.5 (surely on 10.6, too, but I don’t have it). In ~/.subversion/config, I added

    ssh = $SVN_SSH ssh -q -o ControlMaster=no
    

    somewhere around line 55 (if yours is still fresh out of the box, it probably has a commented out line very similar to this right there). The -o ControlMaster=no deals with another ssh setting that I have, that otherwise breaks this entirely.