我在使用TortoiseSVN 1.7.8访问SVN存储库时遇到问题。
SVN存储库位于带有openssh 5.3p1:81.el6的CentOS 6.3机箱上，运行正常。
# 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连接问题，请从[tunnels]中的"ssh"中删除-q选项部分。网络连接意外关闭
我可以使用Putty通过SSH从工作站登录。
如果我尝试以root身份访问，结果是一样的。
我已将存储库/var/svn/的所有权授予USER:USER，并运行chmod 2700 -R /var/svn/。
因为我可以通过ssh从另一个Linux盒子访问存储库，所以权限似乎不是问题。
当我使用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
我实际上可以登录，但会话会立即关闭。
我注意到根(uid=0)正在为USER打开会话，这可能是正确的，但我会提到它，以防它与问题有关。
我考虑过修改svnserve.conf，但据我所知，在通过svn+ssh访问存储库时没有使用它，通过这种方法为每次登录都会创建一个私有的服务器实例。来自手册：
还有第三种方法可以调用svnserve，那就是"tunnelmode"，带有-t选项。此模式假定远程服务诸如RSH或SSH之类的程序已经成功地验证了用户，并且现在正在作为该用户调用一个私有svnserve进程。服务器程序运行正常(通过stdin和stdout进行通信)，并且假设流量通过某些有点像回到客户端的隧道。当svnserve由像这样的隧道代理，请确保经过身份验证的用户已满对存储库数据库文件的读写访问。(请参阅服务器和权限：警告语。)它本质上与本地用户通过文件访问存储库：///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
有什么想法吗？
我终于找到了一个解决方案。在所有地方的TortoiseSVN常见问题解答中：
TortoiseSVN常见问题
来自常见问题解答：
SVN+SSH：连接意外关闭
据报道svn+ssh://username@server.com以前正在工作，请停止使用TortoiseSVN 1.5。这似乎与plink有关，并且如果在PuTTY中设置了默认主机名，则会发生。
如果是这种情况，您可以使用regedit或regedt32来修复它清楚的HKEY_CURRENT_USER/Software/SimonTatham/Putty/Sessions/Default%20Settings/HostName。
另一个用户报告了以下服务器端修复：
- ssh进入您的帐户
- cd~
- cp/etc/bashrc.bashrc
- nano.bashrc
- 在"mesg y"一行之前加一个#(注释)
- Ctrl+X退出，当提示保存时按Y
我没有尝试编辑注册表的第一种方法。
第二种编辑bash配置的方法对我有效
关于bash配置方法的注意事项：
如果你在共享主机上，你的user.bashrc文件可能会加载全局/etc/bashrc文件。您将无法编辑全局文件，因此需要解决此问题。
一些可能的方法：
-
尝试将
mesg n添加到用户.bashrc文件中。我不确定这是不是是否有效，或者是否应将其放置在全局文件已加载。 -
不要在您的用户CCD_ 11文件。
-
从全局/etc/bashrc文件中删除
mesg y设置加载。这个问题讨论了如何做到这一点：使用grepped文件作为bash 中的包含源
这是一个老问题，但在谷歌上仍然是最重要的，所以我想分享我的解决方案。
简单地说，这是因为我在服务器上没有用户的"主"目录。将SSH客户端更改为Putty附带的plink.exe(右键单击文件夹|TortoiseSVN|Settings|Network)使我能够在窗口出现在屏幕上时看到错误。
在我的案例中，原因是svnuser没有shell(它是/bin/false)
即使使用调试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
我遇到了同样的问题，我尝试了regedit解决方案。
在我的情况下，默认主机名不是罪魁祸首，但regedit在保存的会话名称中显示了一个空格(%20)。
当您从Putty打开连接时，Putty并不关心会话名称，因此从Putty连接时没有错误。但是会话名称在svn+ssh://url中很重要！
在我的例子中，Putty会话的名称是"server"，当我签出svn时，我使用了"svn+ssh://server/srv/svn/repo"，因此出现错误。
我在将旧的svn存储库移动到新的Ubuntu 20.04服务器时遇到了这个问题，当时我正试图从Windows(使用tortoisesvn)签出repo。我终于意识到新服务器上没有安装svn，需要它来为存储库提供服务。对我来说，简单的解决方案是：
sudo apt install subversion
TL；DL：向PageAnt添加密钥
首先测试你的Putty配置是否良好-你可以通过Putty使用密钥进行连接，然后你会看到这样的东西：
使用用户名"svn"；。使用公钥进行身份验证"；导入的openssh密钥"；服务器拒绝分配pty(成功(2 2()(编辑管道svndiff1缺少条目提交revprops深度日志revprops原子revprops部分重播继承的props短暂txnprops文件revs反向))
然后启动PageAnt(它与PuTTY和PuTTYgen在同一个安装包中)，您必须在那里添加密钥。
就我而言，它解决了问题。在某些情况下，配置在不配置PageAnt的情况下可以正常工作，但在一些情况下则不然，尽管似乎所有选项都是以相同的方式设置的。
也许这个简单的解决方案会起作用：
转到您的putty，检查保存的会话名称是否与您试图签出的名称(svn保存在putty中的会话名称)匹配
E.G.：在svn保存的会话中，名称保存为coreSvn，签出url为：svn+ssh://svnuser@core/COCRETE/branches/R20181121-0.0.2-RELEASE，这行不通。将@core更改为@coreSvn或@coresvn