On Thu, Jul 8, 2010 at 10:31 PM, Alec Kloss <alec.kl...@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).