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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]