On Thu, Jul 28, 2011 at 10:44 AM, Matthew Beals <mjbeals_at_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.
Received on 2011-07-29 00:37:11 CEST