On Thu, Jul 8, 2010 at 10:31 PM, Alec Kloss <alec.kloss_at_oracle.com> wrote:
> On 2010-07-08 17:04, David Brodbeck wrote:
>>
>> On Jul 8, 2010, at 4:49 PM, Nico Kadel-Garcia wrote:
>> > A local comparison is often best, especially when operating over HTTPS
>> > or svn+ssh for security reasons: Because of the continuing storage of
>> > HTTP/HTTPS/svn/SSH passwords in clear-text by the UNIX or Linux
>> > versions of Subversion, I don't trust anything but the svn+ssh public
>> > key based access for public use. Unfortunately, this does cause a
>> > noticeable performance hit.
>>
>> It's worth pointing out that the private key has to have a passphrase, for this to be a security improvement. Otherwise all you've accomplished is to leave the password-equivalent in ~/.ssh instead of in ~/.svn. ;) I mention this only because a lot of the applications for SSH public keys involve passwordless login.
>>
> [chop]
>
> I feel a little like a broken record, but...
>
> using GSSAPI (or Negotiate for HTTPS) substantially reduces the security
> issues by integrating authentication into the rest of a managed
> single-sign-on system. GSSAPI/Negotiate also has the feature of working
> in all four remote access protocols for Subversion. The downside is
> difficulty in configuration and poor support in some (or many or perhaps
> all) binary distributions of Subversion. I have to admit, I don't think
> very highly of ssh public-key authentication; I have a hard time
> believing very many users or administrators carefully protect, rotate,
> and revoke RSA keys in a timely manner, which seems to me to
> substantially reduce the security of ssh public-key "infrastructure".
It's a longstanding problem. Much as Subversion on UNIX and Linux, by
default, allows the plaintext saving of passwords, the SSH key
management tools allow the saving of passphrase free keys.
GSSAPI is cool. It does take more setup work, and the default versions
of OpenSSH on many industry standard releases do not support it, nor
does the "stable" release of Putty. Various development versions do
permit this, but then the setup has to play well with the ownership of
the files on the server (which svn+ssh does by using a single
designated user) or for shared account access, the setting of the
correct username for logging (which svn+ssh key management does by
setting svnserve command line options).
Received on 2010-07-09 16:55:55 CEST