TortiseSVN SVN + SSH错误：无法连接到一个URL库...网络连接意外关闭 [英] TortiseSVN svn+ssh Error: Unable to connect to a repository at URL ... Network connection closed unexpectedly

问题描述

我在访问使用TortoiseSVN 1.7.8的SVN仓库的问题。

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

在SVN仓库是一个CentOS 6.3框的openssh 5.3p1：81.el6 和似乎正常

The SVN repository is on a CentOS 6.3 box with openssh 5.3p1:81.el6 and appears to be functioning correctly.

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

我可以从另一个CentOS的盒子用这个命令访问知识库：

I can access the repository from another CentOS box with this command:

svn list svn+ssh://[e-mail]/var/svn/joetest

但是，当我尝试从Win 7的工作站，我无法做到使用以下路径浏览使用TortiseSVN库：

But when I attempt to browse the repository using TortiseSVN from a Win 7 workstation I'm unable to do so using the following path:

svn+ssh://[e-mail]/var/svn/joetest

我收到以下错误在TortoiseSVN：

I receive the following error from TortoiseSVN:

无法在URL连接到存储库
  SVN + SSH：//[e-mail]/var/svn/joetest为了更好地调试SSH
  连接问题，在[隧道]从'SSH'删除-q选项
  Subversion的配置文件的部分。网络连接
  意外关闭

Unable to connect to a repository at URL 'svn+ssh://[e-mail]/var/svn/joetest' To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. Network connection closed unexpectedly

我可以通过SSH使用腻子工作站登录。

I'm able to login via SSH from the workstation using Putty.

的结果是相同的，如果我试图访问的根。

The results are the same if I attempt access as root.

我给库的/ var / SVN / 的所有权用户：User 就跑

搭配chmod 2700 -R在/ var / SVN / 。

I've given ownership of the repository /var/svn/ to USER:USER and ran
chmod 2700 -R /var/svn/.

由于我可以通过SSH从另一个Linux机器访问该存储库，权限似乎不成为问题。

Because I can access the repository via ssh from another Linux box, permissions don't appear to be the problem.

当我看使用尾-fn 2000在/ var / log中的日志文件/安全，我看到每个TortiseSVN询问密码的时间如下：

When I watch the log file using tail -fn 2000 /var/log/secure, I see the following each time TortiseSVN asks for the password:

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

我居然能够登录，但会话，然后立即关闭。

I'm actually able to login, but the session is then closed immediately.

这吸引了我的眼球，本次会议是由root打开USER （UID = 0），这可能是正确的，但我会在案件提到它它牵扯到的问题。

It caught my eye that the session is being opened for USER by root (uid=0), which may be correct, but I'll mention it in case it has something to do with the problem.

我看着修改的svnserve.conf ，但据我所知，通过访问存储库时它不使用 SVN + SSH ，为每个登录通过此方法创建一个私有的svnserve实例。从手册：

I looked into modifying the svnserve.conf, but as far as I can tell, it's not used when accessing the repository via svn+ssh, a private svnserve instance is created for each log in via this method. From the manual:

有仍然调用svnserve的第三种方式，那就是在隧道
  模式，用-t选项。这个模式假设一个远程服务
  程序如RSH或SSH已经成功验证的用户和
  现在调用私有svnserve进程作为用户。该svnserve的
  程序正常运行（通过stdin和stdout通讯），以及
  假定流量对一些被自动重定向
  排序隧道回客户端。当svnserve已经通过调用
  隧道代理这个样子，肯定的是，经过身份验证的用户具有完全
  读写访问存储库数据库文件。 （见服务器
  和权限：一个字的警告），它本质上是一样的。
  本地用户通过文件访问资源库：///网址

There's still a third way to invoke svnserve, and that's in "tunnel mode", with the -t option. This mode assumes that a remote-service program such as RSH or SSH has successfully authenticated a user and is now invoking a private svnserve process as that user. The svnserve program behaves normally (communicating via stdin and stdout), and assumes that the traffic is being automatically redirected over some sort of tunnel back to the client. When svnserve is invoked by a tunnel agent like this, be sure that the authenticated user has full read and write access to the repository database files. (See Servers and Permissions: A Word of Warning.) It's essentially the same as a local user accessing the repository via file:/// URLs.

在的sshd_config 唯一的非默认设置是：

The only non-default settings in sshd_config are:

Protocol 2 # to disable Protocol 1

SyslogFacility AUTHPRIV

ChallengeResponseAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials 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

有什么想法？

推荐答案

我终于跨越的解决方案来了这一点。在所有的地方TortoiseSVN的常见问题解答：结果
TortoiseSVN的常见问题

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

从常见问题：结果
SVN + SSH：连接关闭意外

From the FAQ:
SVN+SSH: Connection closed unexpectedly

据报的形式的该SVN + ssh连接
  SVN + SSH：//[e-mail]这是previously工作，停止
  与TortoiseSNV 1.5工作。这似乎PLINK有关系，并
  如果你有一个腻子默认主机名设置发生。

It has been reported that svn+ssh connections of the form svn+ssh://[e-mail] 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.

如果是这样的话，你可以使用Regedit或regedt32以修复
  明确
  HKEY_CURRENT_USER /软件/ SimonTatham /腻子/会话/默认％20Settings /主机名。

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到您的帐户

  
• CD〜

  
• CP的/ etc / bashrc中的.bashrc

  
• 纳米的.bashrc

  
• 把＃前行MESG Y（这评论吧）

  
• 按Ctrl + X，以提示保存退出时，preSS年。

  

我没有尝试编辑我的注册表的第一种方法。

---

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

编辑bash的配置第二种方法为我工作。

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

关于bash的配置方法的说明：

如果你在共享主机，你的用户.bashrc文件可能会被载入全局的/ etc / bashrc中的文件。您将不能够编辑全局文件，所以你需要努力解决这一问题。

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.

一些可能的方法：

• 尝试添加 MESGñ到您的用户.bashrc文件。我不知道，如果这
  将工作或是否应之前或之后的全局被放置
  文件被加载。

• 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.

不要在全局文件和硬code所有设置的
用户的.bashrc 文件。

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

删除 MESG是从全局的/ etc / .bashrc的文件设置，因为它是
加载。这个问题讨论了如何做到这一点：<一href=\"http://stackoverflow.com/questions/2452657/use-a-grepped-file-as-an-included-source-in-bash\">Use一个grepped文件
作为bash中包含的源

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

这篇关于TortiseSVN SVN + SSH错误：无法连接到一个URL库...网络连接意外关闭的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！