我在一个有（不必要的）严格的安全要求的组织工作。 去年，我们在一台云计算机上build立了一台SVN服务器。 这台机器的要求决定了唯一被批准的访问方法是通过RSA令牌进行双因素authentication。
这意味着我们不能使用svn + ssh：//，因为开发人员不得不为每一个SVN操作使用不方便的RSA标记。 但是我们也不能天真地使用svn：//因为（天堂禁止）人们可以在不使用双因素令牌的情况下访问SVN服务器上的数据。
最终，我们开发了一个复杂的端口转发系统。 服务器有一个典型的svnserve守护程序进程监听3690上的连接，但防火墙阻止了除localhost之外的所有连接。 如果用户不在中心位置，则必须先将VPN连入networking。 用户将创build一个到服务器的SSH隧道，然后转发端口（比如说）6789到服务器上的端口3690（SVN端口）（换句话说，就是ssh user@server -L 6789:localhost:3690 ）。 只要SSH会话保持打开，用户可以通过引用该端口来使用正常的svn URL：例如， svn://localhost:6789/path/to/repository/trunk 。
对于* nix系统和Windows（使用PuTTY和TortoiseSVN），这已经工作了大约一年。 现在，我们遇到了一个使用Windows / TortoiseSVN的新团队成员的问题。 她可以使用端口转发进行VPN连接并启动SSH会话，但是当她实际检查某些内容（请参阅上面的示例path）时，她会收到以下消息：“networking连接意外closures”。 PuTTY会话不显示任何错误消息或结束，所以我不太确定这是服务器的错误。 我已经独立testing了她的机器通过6789端口收听自己的能力。
我不确定系统中的哪个组件有问题：TortoiseSVN，PuTTY，她的计算机的防火墙设置，她的networking的防火墙设置，我们的服务器的防火墙设置或svnserve进程。 我怀疑它的防火墙设置，因为这是她唯一比其他人都不同的东西。 但是，防火墙如何防止通过SSH端口转发隧道的stream量呢？ 它应该都显示通过端口22，所以它应该通过，如果SSH连接可以成功build立在第一位。 我很难过
所以：