5

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?

Improve this question
6
  • "support for svn+ssh has been dropped because we wanted to avoid creating system users on that machine just for SVN access" -- that's a rather misguided action.
    – womble ♦
    Aug 16, 2011 at 0:16
  • How so, womble? Fewer system users means fewer vectors of attack. In our setup, if a Subversion user gets compromised, the worst that can happen is that something inappropriate gets written to one SVN repository. If a system user gets compromised, on the other hand... Local privilege escalation is a very real problem.
    – Zilk
    Aug 16, 2011 at 0:47
  • Two issues: 1) whatever's running your webserver is a "system user" anyway, so you're not actually improving security; 2) Your assumption that to run svn+ssh requires multiple "system users" is incorrect.
    – womble ♦
    Aug 16, 2011 at 0:50
  • womble: ad 1) the web server user has no password and no shell; ad 2) you need one system account for each svn+ssh user, unless they all share an account, which may be acceptable in some companies, but not in ours.
    – Zilk
    Aug 16, 2011 at 1:22
  • svn+ssh user accounts can have no password and no shell too.
    – womble ♦
    Aug 16, 2011 at 4:19

3 Answers 3

Reset to default
2

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.

Improve this answer
1

Unsure what the IT dudes did to our SVN server to cause this, but I got tired of the GUI password prompt, so I tweaked ~/.subversion/config file to remove the [gui] kwallet, and use only the text-mode prompt:

password-stores = gnome-keyring

But even that was still kind of annoying, so I did this a few times in my source tree:

vi +/http .svn/entries

and changed the http: to https: a couple of times, and then I was no longer prompted.

Oddly, I didn't need to change it everywhere... or maybe anywhere... at some point, a daemon died or a SIGHUP sent or something... I noticed that one of the files under this dir got updated:

~/.subversion/auth/svn.simple/

Seems good for how. Ah, the hack-tastic workaround.

Improve this answer
0

As @devicenull said, the actual password needs to eventually be available. However, one option would be to use something like encfs or ecryptfs to encrypt entire or part of[0] users' home directories, which would mean that the password would be stored encrypted on the disk. This would still need to be unlocked when they log in (although this can be done with PAM if they're using password authentication), and users would have to ensure that it is unmounted when they're done.

[0] Obviously you'd want ~/.ssh/ to be on the encrypted part.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .