On Thu, Jul 28, 2011 at 10:44 AM, Matthew Beals <mjbe...@mtu.edu> wrote: >> That "svn" user can be set to have no valid shell, with its shell set >> to something like "/sbin/nologin". This is actually quite common for >> system services to have no valid shell. This is how the "apache" or >> "www-data" user is usually set up. > But that would prevent login using ssh, which I don't want. I can tell > the sysadmin "we need an SSH login for Charlie so he can use > Subversion", but I cannot say "You have to cut the SSH login for Marilyn > so she can't use Subversion".
You've got a basic misapprehension here. They do not use their own shell access for Subversion. It is *divorced* from normal shell access. They still have their shell for non-Subverson access, but for Subversion, they have to come in as the "svn" user with the "svn+ssh://svn@hostname/reponame/" access, with SSH keys. Notice that "svn@" bit? That targets the access through that shared user. This is similar to what HTTP and svnservice access do: the service in those cases runs as a local daemon with a non-shell enabled user. > *Truncated for clarity* > One option would be to generate a different (password enabled... of course) > key for each unique user (all logging in with the same SVN user name). Then > revoking SVN access is as simple as removing that user's key from the > authorized_keys list. You are confusing authorized_keys usage with password access. You have utterly no control, as an admin, Even if you generate SSH private keys and nissue them to users, with passphrases, you have no way to prevent them from stripping out the passphrase protection. This is a long, long standing security risk of common SSH user behavior: people get tired of having to unlock keys and get tempted to use passphrase free keys, especially for Subversion, and won't bother to use an ssh-agent or other key management tool to keep a locally unlocked tool for passphrase Subversion usage. And you, as a network admin, have little leverage to make them use keys properly. It drives me nuts, and I've said that it's a fundamental flaw in the ssh-keygen software that it allows this behavior by default.
