6

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

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

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

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

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

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

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

我从 TortoiseSVN 收到以下错误:

无法连接到 URL 'svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest' 的存储库 为了更好地调试 SSH 连接问题,请从 [你的 Subversion 配置文件的隧道] 部分。网络连接意外关闭

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

如果我尝试以 root 身份访问,结果是相同的。

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

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

当我使用 观看日志文件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

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

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

我考虑修改svnserve.conf,但据我所知,通过 访问存储库时没有使用它svn+ssh,通过此方法为每个登录创建一个私有 svnserve 实例。从手册:

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

中唯一的非默认设置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

有什么想法吗?

4

7 回答 7

4

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

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

据报道,svn+ssh://username@server.com 形式的 svn+ssh 连接以前可以工作,但在 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。

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

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

关于 bash 配置方法的说明:

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

一些可能的方法:

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

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

  • mesg y在加载时从全局 /etc/bashrc 文件中删除设置。这个问题讨论了如何做到这一点:Use a grepped file as an included source in bash

于 2013-01-31T05:37:38.317 回答
2

一个老问题,但在谷歌上仍然是最重要的,所以我想我会分享我的解决方案。

简单地说,这是因为我在服务器上没有我的用户的“主”目录。将 SSH 客户端更改为 Putty 附带的 plink.exe(右键单击文件夹 | TortoiseSVN | 设置 | 网络)允许我在屏幕上出现窗口时看到错误。

于 2015-03-12T11:34:14.050 回答
1

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

当您遇到此类问题时,您的调试输出将如下所示

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

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

debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending command: svnserve -t
Path: MyRepo
URL: svn+ssh://svnuser@myServer.com/MyRepo
于 2016-11-30T11:07:08.260 回答
1

我有同样的问题,我尝试了 regedit 解决方案。

在我的情况下,默认主机名不是罪魁祸首,但 regedit 在保存的会话名称 (%20) 中显示了一个空格。

当您从那里打开连接时,Putty 不关心会话名称,因此从 Putty 连接时没有错误。但是会话名称在您的 svn+ssh:// url 中很重要!

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

于 2018-07-11T07:20:55.297 回答
1

我在将旧的 svn 存储库移动到新的 Ubuntu 20.04 服务器并尝试从 Windows(使用 tortoisesvn)签出存储库时遇到了这个问题。我终于意识到新服务器上没有安装 svn,它需要为存储库提供服务。对我来说简单的解决方法是:

sudo apt install subversion
于 2020-07-31T17:41:42.383 回答
0

TL;DL:将密钥添加到PageAnt

首先测试您的 Putty 配置是否正常 - 您可以通过 Putty 使用密钥进行连接,您会看到如下内容:

使用用户名“svn”。使用公钥“imported-openssh-key”进行身份验证服务器拒绝分配 pty(成功(2 2())(编辑管道 svndiff1 缺席条目提交-revprops 深度 log-revprops atomic-revprops 部分重播继承-props ephemeral-txnprops文件-revs-reverse ) ) )

然后启动 PageAnt(它与 PuTTY 和 PuTTYgen 在同一个安装包中),你必须在那里添加你的密钥。

就我而言,它解决了问题。在某些情况下,无需配置 PageAnt 就可以正常工作,但在某些情况下却不行,尽管似乎所有选项都以相同的方式设置。

于 2022-01-03T13:11:38.370 回答
-1

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

于 2018-11-21T09:26:53.843 回答