[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Passswords not encrypted

From: Thomas Harold <tgh_at_tgharold.com>
Date: 2007-06-13 16:41:08 CEST

Joseph Mocker wrote:
> I don't see how encrypted passwords would help anyways. If I could
> get to your svn.simple folder, I could probably just copy the files
> to my svn.simple folder and masquerade as you.
> What would be nice is an "ssh-agent" type of capability for
> subversion. Where one could authenticate once for a session, and the
> agent would keep track of the authentication/password. When
> authentication is needed, subversion would query the agent first.

As others have said, svn+ssh works exceedingly well... especially if
you're running the SVN server on a Linux box (or other unix-like
environment). If your SVN server is a Windows box, I'm not 100% sure
that you can use svn+ssh - but I'm probably wrong in thinking that it's
not possible.

It nicely steps around the need to store plaintext passwords in the
files. And I'd consider SSH keys to be more secure then passwords.

Because we limit the SSH keys using the "command=" option in the
~/.ssh/authorized_keys file, we're not very concerned with whether or
not the users are password protecting their keys. The only thing they
can access with a particular key set is the SVN repository (they can't
use it to get shell access or run other commands). Most users don't
even know their password on the SVN server (we set the passwords to a
very long random string).

On the Windows boxes, we have Pageant load the keys into memory as soon
as the user logs in. That provides seamless authentication for any
svn+ssh operations.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 13 16:51:40 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.