My Subversion server only provides access via HTTPS; support for svn+ssh has been dropped because we wanted to avoid creating system users on that machine just for SVN access. Now I'm trying to provide a way for users to cache their passwords for a while, without leaving them stored on the filesystem in unencrypted form.
This is no problem for Gnome or KDE users, because they can use gnome-keyring and kwallet, respectively. IIRC, TortoiseSVN has a similar caching mechanism, too. But what about users on a non-GUI system?
Some context: in this case, we have a development/testing server where one project has been checked out into the Apache htdocs directory. Development for this project is almost complete, and only minor text/layout changes are performed directly on this server. Nevertheless, the changes should be checked into the repository. There's no kwallet and no gnome-keyring on this system, and the ssh-agent can't help because the repository is accessed via https instead of svn+ssh.
As far as I know, that leaves them the choice of entering the password every time they talk to the SVN server, or storing it in an insecure way.
Is there any way to get something like what gnome-keyring and kwallet provide in a non-GUI environment?
Best Answer
No, you cannot.
HTTPS does not support any type of one-way hashing on passwords. At some point in the process, you need the plain text password available. It may be possible to encrypt it up to this point, however given that you would need the decryption key on the server as well, there's very little point.
Even if HTTPS supported one way hashing of passwords, you couldn't do this (It would need to have some protection against replay attacks, otherwise your password hash becomes the password!)
It's not a real solution, but switching to something distributed, like Git, would solve this issue nicely. You would have the users configure SSH agent forwarding to the machine they were connecting to, and auth would be based on that.