Re: Error checking out large repository -- illegal padding

From: Andy Helten <andy.helten_at_dot21rts.com>
Date: 2004-08-09 23:31:10 CEST

This technique was not part of _my_ general SSH knowledge two weeks ago.  The SVN book contains several paragraphs on configuring apache -- some of which are not SVN specific and therefore available elsewhere.  Regardless, I did not realize the book was written for sysadmin types.  I am not a sysadmin -- I am a programmer.  I also find it curious that only one individual proposed this solution that makes use of such "general SSH knowledge".

I understand the difficulty of balancing what goes into a document and what doesn't, but consider for a moment that this approach is also the ONLY ONE AVAILABLE TO ME (recall the illegal padding bug in SVN/SSL)!  With that in mind, consider adding something like the second paragraph below to the "SSH authentication and authorization" section (first paragraph is verbatim from the book):

[snip]

What's happening here is that the Subversion client is invoking a local ssh process, connecting to host.example.com, authenticating as the user harry, then spawning a private svnserve process on the remote machine, running as the user harry. The svnserve command is being invoked in tunnel mode (-t) and all network protocol is being “tunneled” over the encrypted connection by ssh, the tunnel-agent. svnserve is aware that it's running as the user harry, and if the client performs a commit, the authenticated username will be attributed as the author of the new revision.

In some cases it is not desirable to provide system accounts to certain users that require ssh access to the SVN repository.  The sshd's authorized_keys2 configuration file provides a method for solving this problem.  First, the person associated with username harry generates a key using ssh-keygen (or puttygen for TortoiseSVN).  The system administrator then adds this newly generated public key to the authorized_keys2 configuration file (~harry/.ssh/authorized_keys2 for example) and associates that key with the 'svnserve -t' command.  Consult sshd documentation for details on exactly how to configure authorized_keys2 to run a particular command for a user generated key.  When using keys in this way, the person being granted SVN access does not know the password for user harry's system account, thereby preventing shell level access for the person associated with username harry.  In other words, the user can run only the command associated with his key in the authorized_keys2 file on the server.

[snip]

Thanks,
Andy



Ben Collins-Sussman wrote:

On Mon, 2004-08-09 at 15:18, Andy Helten wrote:

  

Thanks again Faried.  And SVN folks -- please consider documenting
this approach in the book.
    

This technique is a part of general SSH knowledge;  most sysadmins
already know about it.

I mean you're right, it *could* be in the book, but it becomes a tricky
business to to decide where to draw the line.  We don't document how to
configure apache to use SSL client or server certs either -- because
that's covered by apache docs.  In that same vein, if you're using ssh
to access a repository, we assume admins have access to ssh
documentation that explains some of the more advanced ssh key-sharing
techniques.



  

--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For additional commands, e-mail: users-help@subversion.tigris.org Received on Mon Aug 9 23:31:55 2004