我的Subversion服务器只能通过HTTPS访问; 对svn + ssh的支持已经被删除了，因为我们希望避免在SVN上创build系统用户。 现在我试图为用户提供一种caching密码一段时间的方式，而不会以未encryption的forms将其保存在文件系统中。
这对Gnome或KDE用户来说不成问题，因为他们可以分别使用gnome-keyring和kwallet。 IIRC，TortoiseSVN也有类似的caching机制。 但是在非GUI系统上的用户呢？
一些上下文：在这种情况下，我们有一个开发/testing服务器，其中一个项目已签出到Apache htdocs目录中。 这个项目的开发几乎已经完成，只有很小的文本/布局变化直接在这个服务器上执行。 不过，应该将这些更改检入到存储库中。 在这个系统上没有kwallet，也没有gnome-keyring，而ssh-agent也不能帮忙，因为这个版本库是通过https而不是svn + ssh访问的。
据我所知，每次与SVN服务器通话时，都会input密码，或以不安全的方式存储密码。
有没有什么办法可以得到像gnome-keyring和kwallet在非GUI环境中提供的东西？
你不能。
HTTPS不支持对密码进行任何types的单向散列。 在这个过程的某个时候，你需要明文密码。 有可能在这一点上对它进行encryption，但是考虑到你也需要服务器上的解密密钥，所以没什么意义。
即使HTTPS支持单向散列密码，你也无法做到这一点（这将需要有一些防止重播攻击的保护，否则你的密码散列成为密码！）
这不是一个真正的解决scheme，但切换到分布式的东西，如Git，可以很好地解决这个问题。 你可以让用户configurationSSH代理转发到他们连接的机器上，auth就是基于这个的。
不确定IT帅哥对我们的SVN服务器做了什么，但是我厌倦了GUI密码提示，所以我调整了~/.subversion/config文件来删除[gui] kwallet，只使用文本模式提示：
password-stores = gnome-keyring
但是即使这样还是有些恼人，所以我在源代码树中做了几次：
vi +/http .svn/entries
并改变了http: https:几次，然后我不再提示。
奇怪的是，我并不需要在任何地方……也可能在任何地方……在某个时候，一个守护进程死了，或者一个SIGHUP发送了什么……我注意到这个目录下的一个文件得到了更新：
~/.subversion/auth/svn.simple/
似乎很好的如何。 啊，这个捣乱的解决办法
正如@devicenull所说，实际的密码需要最终可用。 但是，一种select是使用类似encfs或ecryptfs的东西来encryption整个或部分[0]用户的主目录，这意味着密码将被encryption存储在磁盘上。 当他们login时，这仍然需要解锁（尽pipe如果他们使用密码authentication，这可以通过PAM来完成），并且用户必须确保在完成之后将其卸载。
[0]很明显，你会希望〜/ .ssh /被encryption的部分。