Bug#352518: extend authorized_keys command handling
Package: openssh-server
Version: 1:4.2p1-5
Severity: wishlist
Tags: upstream
Hi,
Currently the way command="" is handled in authorized_keys parsing
(auth-options.c) is to force that particular command on anyone
authenticating with that key.
At fd.o, we're in the process of moving to several hosts, as opposed to
everything on the one machine. One host in particular is our new
source-only machine, which will be used as the master for CVS/SVN/etc
sources. In particular, developers will not have shell access unless
necessary.
Currently the way we're enforcing this is with command="/usr/bin/cvs
server", which is rather suboptimal for several reasons. One, it's
rather confusing when you attempt to SSH there and are greeted with
nothing but CVS (imagine the hilarity when the host you're SSHing to
tells you, I HATE YOU). Two, it doesn't allow for multiple commands.
svn+ssh is, as far as I'm aware, the optimal solution for SVN access
(bearing in mind that something like svnserve is a particularly poor fit
for our model, because it means that any committer to the icon theme
specification has access to the X.Org repository). However,
command="/usr/bin/cvs server" will stifle that.
A field like allow_command="..." would be nice, where you could specify
multiple allowed commands (CVS, SVN, whatever), and then simply refuse
authentication for that key if the user wants to run something other
than what's specified in allow_command. Optional bonus points if you
allow arbitrary arguments: one thing I'd rather like to do is set up an
account that can only run rsync, but with the arguments changing (so we
can sync individual roots we know to be dirty, rather than the
brute-force sync-the-entire-repo approach). Again, this is not possible
with the current command="" handling.
I understand that this sort of thing won't be carried in a Debian patch,
but I'm not sure where to submit things upstream (and, to be honest, I'm
quite cheerful at the prospect of using the Debian BTS as a means of not
dealing with Theo de Raadt), so hence the tag.
Cheers,
Daniel
Reply to: