bash TortiseSVN svn+ssh 错误：无法连接到 URL 处的存储库...网络连接意外关闭

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

提问by codewaggle

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

我在使用 TortoiseSVN 1.7.8 访问 SVN 存储库时遇到问题。

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

SVN 存储库位于 CentOS 6.3 机器上，openssh 5.3p1:81.el6并且似乎运行正常。

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

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

我可以使用以下命令从另一个 CentOS 机器访问存储库：

svn list svn+ssh://[email protected]/var/svn/joetest

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:

但是，当我尝试从 Win 7 工作站使用 TortiseSVN 浏览存储库时，我无法使用以下路径进行浏览：

svn+ssh://[email protected]/var/svn/joetest

I receive the following error from TortoiseSVN:

我从 TortoiseSVN 收到以下错误：

Unable to connect to a repository at URL 'svn+ssh://[email protected]/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

无法连接到 URL 'svn+ssh://[email protected]/var/svn/joetest' 的存储库为了更好地调试 SSH 连接问题，请从 [ tunnels] 部分的 Subversion 配置文件。网络连接意外关闭

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

我可以使用 Putty 从工作站通过 SSH 登录。

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

如果我尝试以 root 身份访问，结果是一样的。

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

我已将存储库的所有权/var/svn/授予USER:USER并运行
chmod 2700 -R /var/svn/.

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

因为我可以从另一个 Linux 机器通过 ssh 访问存储库，所以权限似乎不是问题。

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

当我使用 观看日志文件时tail -fn 2000 /var/log/secure，每次 TortiseSVN 要求输入密码时，我都会看到以下内容：

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.

我实际上能够登录，但会话随后立即关闭。

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.

我注意到会话是由 root 为 USER 打开的(uid=0)，这可能是正确的，但我会提到它，以防它与问题有关。

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.conf，但据我所知，通过 访问存储库时不使用它svn+ssh，通过此方法为每次登录创建一个私有 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.

还有第三种调用 svnserve 的方法，那就是在“隧道模式”下，使用 -t 选项。此模式假定远程服务程序（例如 RSH 或 SSH）已成功验证用户身份，并且现在正在以该用户身份调用私有 svnserve 进程。svnserve 程序正常运行（通过 stdin 和 stdout 进行通信），并假设流量通过某种隧道自动重定向回客户端。当像这样的隧道代理调用 svnserve 时，请确保经过身份验证的用户对存储库数据库文件具有完全的读写访问权限。（请参阅服务器和权限：警告。）它本质上与本地用户通过 file:/// URL 访问存储库相同。

The only non-default settings in sshd_configare:

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

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

Any thoughts?

有什么想法吗？

采纳答案by codewaggle

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

我终于找到了解决方案。在所有地方的 TortoiseSVN FAQ 中：
TortoiseSVN 常见问题

From the FAQ:
SVN+SSH: Connection closed unexpectedly

来自常见问题解答：
SVN+SSH：连接意外关闭

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

据报道，以前工作的 svn+ssh 形式的 svn+ssh://[email protected] 连接停止使用 TortoiseSVN 1.5。这似乎与 plink 相关，如果您在 PuTTY 中设置了默认主机名，则会发生这种情况。

如果是这种情况，您可以通过使用 regedit 或 regedt32 清除 HKEY_CURRENT_USER/Software/SimonTatham/Putty/Sessions/Default%20Settings/HostName 来修复它。

---

另一位用户报告了以下服务器端修复：

• ssh 进入您的帐户
• 光盘~
• cp /etc/bashrc .bashrc
• 纳米.bashrc
• 在“mesg y”行之前放一个#（将其注释掉）
• Ctrl+X 退出，提示保存时按 Y。

---

---

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

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

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

编辑 bash 配置的第二种方法对我有用。

A note about the bash configuration method:

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

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.

如果您在共享主机上，您的用户 .bashrc 文件可能会加载全局 /etc/bashrc 文件。您将无法编辑全局文件，因此您需要解决这个问题。

Some possible approaches:

一些可能的方法：

• Try adding mesg nto 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 .bashrcfile.

• Remove the mesg ysetting 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

• 尝试添加mesg n到您的用户 .bashrc 文件。我不确定这是否可行，或者是否应该在加载全局文件之前或之后放置它。

• 不要在用户.bashrc文件中包含全局文件和硬编码所有设置。

• 在mesg y加载时从全局 /etc/bashrc 文件中删除设置。这个问题讨论了如何做到这一点：使用 grepped 文件作为 bash 中包含的源

回答by Grim...

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.

简单地说，这是因为我在服务器上没有我的用户的“主”目录。将 SSH 客户端更改为 Putty 附带的 plink.exe（右键单击文件夹 | TortoiseSVN | Settings | Network）让我在窗口出现在屏幕上时看到错误。

回答by jeb

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.

就我而言，原因是 svnuser 没有外壳（它是 /bin/false）。
即使使用 debug ssh -vvv，这在 ssh 日志中也不可见。

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 [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1

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

当 shell 设置为 /bin/bash 时，日志更改为

debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending command: svnserve -t
Path: MyRepo
URL: svn+ssh://[email protected]/MyRepo

回答by user1987625

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

我遇到了同样的问题，我尝试了 regedit 解决方案。

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

在我的情况下，默认主机名不是罪魁祸首，但 regedit 在保存的会话名称 (%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!

当您从那里打开连接时，Putty 不关心会话名称，因此从 Putty 连接时没有错误。但是会话名称在您的 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.

在我的例子中，Putty 会话名称是“server”，当我进行 svn checkout 时，我使用了“svn+ssh://server/srv/svn/repo”，因此出现了错误。

回答by user10684854

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 @coreto @coreSvnor @coresvn

也许这个简单的解决方案会起作用：
转到您的腻子并检查保存的会话名称是否与您尝试结帐的名称（腻子中的 svn 保存的会话名称）匹配...
EG：在 svn 保存的会话中，名称保存为coreSvn，结帐网址为： svn+ssh://svnuser@core/COCRETE/branches/R20181121-0.0.2-RELEASE，这不起作用。更改@core为@coreSvn或@coresvn