You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by km...@rockwellcollins.com on 2009/09/01 14:14:31 UTC
Re: how can I change my password by SVN client?
Nico Kadel-Garcia <nk...@gmail.com> wrote on 08/31/2009 06:57:30 PM:
> 2009/8/31 David Weintraub <qa...@gmail.com>:
> > Subversion doesn't have its own native security. This is actually a
better
> > way because it allows you to use external security regimens.
> >
> > For example, we use LDAP and connect to our Active Server via Apache.
Now, I
> > don't have to worry about settiing up users independently. If a user
is in
> > the Windows server's engineering group, they automatically have access
to
> > Subversion without me doing anything. Once they leave, they have no
more
> > access.
> >
> > Even better, their Subversion password is the same as their Windows
> > password. No more forgetting their password.
> >
> > If I use ssh+svn://, the operating system handles logging in and out.
My
> > name and password is the same as my Unix account.
>
> What? No-no-no-no-no. This is used by some, but the far safer and more
> useful way to do is to designate an svn user, who's
> $HOME/.ssh/authorized_keys file This relies on SSH keys, not
> passwords, which allows single-sign-on style user access by having an
> ssh-agent (or a Gnome or KDE "wallet", which is out of band of
> Subversion's key storage).
> No user passwords. None. Nyet. Nil. Nein. Nada. A user selected
> password is normally used to unlock the relevant SSH key, and a Gnome
> or KDE wallet can manage that. And this way, the repository URL's look
> ile 'svn+ssh://svn@reposerver/var/lib/svn/repository', or a similar
> structure. This allows user login to that server to be quite distinct
> and even unnecessary. This is the approach that Sourceforge uses, for
> example. The public SSH key in is set to designate the relevant
> Subversion user based on which key is used. It's a very handy
> approach, and avoids the security issues that I tend to rant about, at
> the cost of some setup time.
This setup is a pain for both the user and the administrator. Additional
steps must be performed by each before work can begin.
(And ssh keys are really no better than a password, you are just
forcing the user to have different piece of secret information.)
Why not use something like kerberos? Windows will transparently
checkout a ticket. No password needed and no additional setup needed
by either the user or the administrator for new users. Granted, this
only works well in a corporate environment, but it is a very big win
when dealing with less technical users...
The beauty of Subversion is that it lets YOU choose the
appropriate authentication method for your environment.
Kevin R.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389774
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: how can I change my password by SVN client?
Posted by David Weintraub <qa...@gmail.com>.
My whole point was that Subversion doesn't force you to use a built-in
security scheme.
YOU are free to choose the system YOU want for passwords. We use LDAP and
Apache. You can use ssh keys, wallet, kerberos, or simply store the
information in a text auth-password file and use plain old "svn". Exactly
how you do your security is up to the site.
On Tue, Sep 1, 2009 at 10:14 AM, <km...@rockwellcollins.com> wrote:
>
> Nico Kadel-Garcia <nk...@gmail.com> wrote on 08/31/2009 06:57:30 PM:
>
> > 2009/8/31 David Weintraub <qa...@gmail.com>:
> > > Subversion doesn't have its own native security. This is actually a
> better
> > > way because it allows you to use external security regimens.
> > >
> > > For example, we use LDAP and connect to our Active Server via Apache.
> Now, I
> > > don't have to worry about settiing up users independently. If a user is
> in
> > > the Windows server's engineering group, they automatically have access
> to
> > > Subversion without me doing anything. Once they leave, they have no
> more
> > > access.
> > >
> > > Even better, their Subversion password is the same as their Windows
> > > password. No more forgetting their password.
> > >
> > > If I use ssh+svn://, the operating system handles logging in and out.
> My
> > > name and password is the same as my Unix account.
> >
> > What? No-no-no-no-no. This is used by some, but the far safer and more
> > useful way to do is to designate an svn user, who's
> > $HOME/.ssh/authorized_keys file This relies on SSH keys, not
> > passwords, which allows single-sign-on style user access by having an
> > ssh-agent (or a Gnome or KDE "wallet", which is out of band of
> > Subversion's key storage).
>
> > No user passwords. None. Nyet. Nil. Nein. Nada. A user selected
> > password is normally used to unlock the relevant SSH key, and a Gnome
> > or KDE wallet can manage that. And this way, the repository URL's look
> > ile 'svn+ssh://svn@reposerver/var/lib/svn/repository', or a similar
> > structure. This allows user login to that server to be quite distinct
> > and even unnecessary. This is the approach that Sourceforge uses, for
> > example. The public SSH key in is set to designate the relevant
> > Subversion user based on which key is used. It's a very handy
> > approach, and avoids the security issues that I tend to rant about, at
> > the cost of some setup time.
>
> This setup is a pain for both the user and the administrator. Additional
> steps must be performed by each before work can begin.
> (And ssh keys are really no better than a password, you are just
> forcing the user to have different piece of secret information.)
>
> Why not use something like kerberos? Windows will transparently
> checkout a ticket. No password needed and no additional setup needed
> by either the user or the administrator for new users. Granted, this
> only works well in a corporate environment, but it is a very big win
> when dealing with less technical users...
>
> The beauty of Subversion is that it lets YOU choose the
> appropriate authentication method for your environment.
>
> Kevin R.
>
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389877
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Fwd: how can I change my password by SVN client?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
[ accidentally replied only to Les ]
On Tue, Sep 8, 2009 at 9:03 AM, Les Mikesell <le...@gmail.com> wrote:
> They just use their own login/password to establish who they are so either
> apache or svn path based access control should work and logging works as you
> would expect. They just can't get in at all unless they have a certificate
> from the trusted authority that hasn't been revoked. I haven't used this
> scheme myself but I believe another part of my company does - probably using
> Novell's certificate management to mesh with their Notes ids. I assume that
> anything capable of doing https these days can handle client certificates -
> including whatever libraries the svn clients use.
OK, color me still sad. The SSL key controls site access to the web
services, but you still wind up using password authentication to
Subversion and thus still wind up with passwords in $HOME/.svn/auth
for non-Windows clients? Then this scheme protects the Subversion
server at the expense of security for anything else that uses the same
passwords.
Or do I misunderstand what you mean by "use theor own
login/passwords"? If it's unlocking the SSL key, how are they
retaining the unlocked state for additional Subversion operations in
the same session?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393592
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: how can I change my password by SVN client?
Posted by Les Mikesell <le...@gmail.com>.
Nico Kadel-Garcia wrote:
>
>>>> Nico Kadel-Garcia wrote:
>>>>>> * Have you ever tried to teach a newbie (possibly quite talented, but
>>>>> nevertheless a newbie) to configure customized Kerberos setups? I
>>>>> have. It wasn't pretty.
>>>> Are there similar issues using https and a client certificate
>>>> requirement?
>>> The last time I tried that sort of thing, there was effort, but it
>>> wasn't as bad. Organizing the server side to manage the sertificates
>>> and synchronize access for each client to the same repository but with
>>> a different key was...... fascinating. I basically wrote a little
>>> script to survey the key list and genarate alias configurations for
>>> each user with a different URL to the same material. Workable, but it
>>> wouldn't necessarily scale well.
>> Can't you configure apache to trust a certificate authority, not individual
>> certificates, and then use something like tinyca to generate (and revoke if
>> necessary) the certificates? You still need passwords, but they are
>> ssl-encrypted on the wire and you can't get in without both the password and
>> certificate.
>
> *Interesting*. I like it! How do you store the unlocked key this way
> for your active TortoiseSVN or command line svn clients, to avoid
> having to repeatedly type it in. You still have to do something about
> giving different users slightly different access to the same material
> in order to set the 'user' for logging, and I don't see how to do it
> with this approach unless you repeat my approach and set slightly
> different repository paths for different SSL keys.
They just use their own login/password to establish who they are so either
apache or svn path based access control should work and logging works as you
would expect. They just can't get in at all unless they have a certificate from
the trusted authority that hasn't been revoked. I haven't used this scheme
myself but I believe another part of my company does - probably using Novell's
certificate management to mesh with their Notes ids. I assume that anything
capable of doing https these days can handle client certificates - including
whatever libraries the svn clients use.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392379
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: how can I change my password by SVN client?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Sep 7, 2009 at 12:02 PM, Les Mikesell <le...@gmail.com> wrote:
> Nico Kadel-Garcia wrote:
>>
>> On Sun, Sep 6, 2009 at 12:19 PM, Les Mikesell <le...@gmail.com>
>> wrote:
>>>
>>> Nico Kadel-Garcia wrote:
>>>>>
>>>>> * Have you ever tried to teach a newbie (possibly quite talented, but
>>>>
>>>> nevertheless a newbie) to configure customized Kerberos setups? I
>>>> have. It wasn't pretty.
>>>
>>> Are there similar issues using https and a client certificate
>>> requirement?
>>
>> The last time I tried that sort of thing, there was effort, but it
>> wasn't as bad. Organizing the server side to manage the sertificates
>> and synchronize access for each client to the same repository but with
>> a different key was...... fascinating. I basically wrote a little
>> script to survey the key list and genarate alias configurations for
>> each user with a different URL to the same material. Workable, but it
>> wouldn't necessarily scale well.
>
> Can't you configure apache to trust a certificate authority, not individual
> certificates, and then use something like tinyca to generate (and revoke if
> necessary) the certificates? You still need passwords, but they are
> ssl-encrypted on the wire and you can't get in without both the password and
> certificate.
*Interesting*. I like it! How do you store the unlocked key this way
for your active TortoiseSVN or command line svn clients, to avoid
having to repeatedly type it in. You still have to do something about
giving different users slightly different access to the same material
in order to set the 'user' for logging, and I don't see how to do it
with this approach unless you repeat my approach and set slightly
different repository paths for different SSL keys.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392349
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: how can I change my password by SVN client?
Posted by Les Mikesell <le...@gmail.com>.
Nico Kadel-Garcia wrote:
> On Sun, Sep 6, 2009 at 12:19 PM, Les Mikesell <le...@gmail.com> wrote:
>> Nico Kadel-Garcia wrote:
>>>> * Have you ever tried to teach a newbie (possibly quite talented, but
>>> nevertheless a newbie) to configure customized Kerberos setups? I
>>> have. It wasn't pretty.
>> Are there similar issues using https and a client certificate requirement?
>
> The last time I tried that sort of thing, there was effort, but it
> wasn't as bad. Organizing the server side to manage the sertificates
> and synchronize access for each client to the same repository but with
> a different key was...... fascinating. I basically wrote a little
> script to survey the key list and genarate alias configurations for
> each user with a different URL to the same material. Workable, but it
> wouldn't necessarily scale well.
Can't you configure apache to trust a certificate authority, not individual
certificates, and then use something like tinyca to generate (and revoke if
necessary) the certificates? You still need passwords, but they are
ssl-encrypted on the wire and you can't get in without both the password and
certificate.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2391992
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: how can I change my password by SVN client?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, Sep 6, 2009 at 12:19 PM, Les Mikesell <le...@gmail.com> wrote:
> Nico Kadel-Garcia wrote:
>>
>> > * Have you ever tried to teach a newbie (possibly quite talented, but
>> nevertheless a newbie) to configure customized Kerberos setups? I
>> have. It wasn't pretty.
>
> Are there similar issues using https and a client certificate requirement?
The last time I tried that sort of thing, there was effort, but it
wasn't as bad. Organizing the server side to manage the sertificates
and synchronize access for each client to the same repository but with
a different key was...... fascinating. I basically wrote a little
script to survey the key list and genarate alias configurations for
each user with a different URL to the same material. Workable, but it
wouldn't necessarily scale well.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2391737
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: how can I change my password by SVN client?
Posted by Les Mikesell <le...@gmail.com>.
Nico Kadel-Garcia wrote:
> >
> * Have you ever tried to teach a newbie (possibly quite talented, but
> nevertheless a newbie) to configure customized Kerberos setups? I
> have. It wasn't pretty.
Are there similar issues using https and a client certificate requirement?
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2391551
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: how can I change my password by SVN client?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Sep 1, 2009 at 10:14 AM, <km...@rockwellcollins.com> wrote:
>
> Nico Kadel-Garcia <nk...@gmail.com> wrote on 08/31/2009 06:57:30 PM:
>> 2009/8/31 David Weintraub <qa...@gmail.com>:
>> > Subversion doesn't have its own native security. This is actually a
>> > better
>> > way because it allows you to use external security regimens.
>> >
>> > For example, we use LDAP and connect to our Active Server via Apache.
>> > Now, I
>> > don't have to worry about settiing up users independently. If a user is
>> > in
>> > the Windows server's engineering group, they automatically have access
>> > to
>> > Subversion without me doing anything. Once they leave, they have no more
>> > access.
>> >
>> > Even better, their Subversion password is the same as their Windows
>> > password. No more forgetting their password.
>> >
>> > If I use ssh+svn://, the operating system handles logging in and out. My
>> > name and password is the same as my Unix account.
>>
>> What? No-no-no-no-no. This is used by some, but the far safer and more
>> useful way to do is to designate an svn user, who's
>> $HOME/.ssh/authorized_keys file This relies on SSH keys, not
>> passwords, which allows single-sign-on style user access by having an
>> ssh-agent (or a Gnome or KDE "wallet", which is out of band of
>> Subversion's key storage).
>
>> No user passwords. None. Nyet. Nil. Nein. Nada. A user selected
>> password is normally used to unlock the relevant SSH key, and a Gnome
>> or KDE wallet can manage that. And this way, the repository URL's look
>> ile 'svn+ssh://svn@reposerver/var/lib/svn/repository', or a similar
>> structure. This allows user login to that server to be quite distinct
>> and even unnecessary. This is the approach that Sourceforge uses, for
>> example. The public SSH key in is set to designate the relevant
>> Subversion user based on which key is used. It's a very handy
>> approach, and avoids the security issues that I tend to rant about, at
>> the cost of some setup time.
>
> This setup is a pain for both the user and the administrator. Additional
> steps must be performed by each before work can begin.
> (And ssh keys are really no better than a password, you are just
> forcing the user to have different piece of secret information.)
>
> Why not use something like kerberos? Windows will transparently
> checkout a ticket. No password needed and no additional setup needed
> by either the user or the administrator for new users. Granted, this
> only works well in a corporate environment, but it is a very big win
> when dealing with less technical users...
>
> The beauty of Subversion is that it lets YOU choose the
> appropriate authentication method for your environment.
I'd love to have it Kerberos-based! But there are fascinating requirements.
* Kerberos and possibly LDAP management of the Subversion as a
distinct privilege from shell login, to prevent the need for system
shell accounts on the Subversion server. This is fundamental: the
ordinary Subversion repository user *should not* have shell access to
the server in a secure environment, and most definitely should not
have user-based write privileges to the repository directories to
avoid file ownership whackiness of file-based access. The places I've
been consulting lately, for family travel reasons, all have their own
Active Directory services which I had little input for, but I took
advantage of their Kerberos user authentication. But this approach
could buy much better tools for managing the service privileges
necessary for Subversion. It takes some work.
* Support for the necessary Kerberos utilities on all the requisite
clients. That's a pretty serious demand on client toolsuites: it's
theoretically feasible for TortoiseSVN, as a well-defined and
well-managed toolkit, but getting it into more odd basic OS's is not
so easy. And as soon as you allow access *without* the necessary
Kerberos utilities, for example by un-Kerberos-based SSH, you're
screwed by the plain-text password storage problem, and you may as
well throw out all that Kerberos work because many users will simply
have no incentive to use it. And even Putty doesn't have full Kerberos
support, and that of many "stable", popular production grade operating
systems like RHEL 4 is years out of date and therefore rather limited.
* If you're using Kerberos based ssh+svn, where do you inject the
settings to set the 'user' based on their particular login key or
other settings? This works well with the SSH public keys because the
public keys set the 'user' for Subversion logging, even though they're
all coming in through the same centrally managed account. But that's
the sort of thing that Kerberos/LDAP integration would be great for,
and that's a lot of work I don't personally have the expertise or time
to do. If you do, *FABULOUS*. I'd welcome and support your work.
* A major difficulty there is that most Kerberos authentication
systems allow password authentication at connect time, rather than
insisting on the previous local storage of a Kerberos ticket. As soon
as you have that, I think you run headlong into *exactly* what I was
most concerned about: the storage of user passwords in
$HOME/.svn/auth/.
* Have you ever tried to teach a newbie (possibly quite talented, but
nevertheless a newbie) to configure customized Kerberos setups? I
have. It wasn't pretty.
Kerberos is amazing and cool stuff: I was very lucky to meet some of
its original authors and catch presentations on how it works at MIT
and Harvard, and I'd *love* to see it well-integrated into Subversion.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2391501
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].