On Mon, Apr 06, 2009 at 10:15:08PM +0300, Jari Aalto wrote: > Colin Watson <[email protected]> writes: > > On Mon, Apr 06, 2009 at 11:37:47AM +0300, Jari Aalto wrote: > >> - PermitRootLogin cha¨nge: from 'yes' to 'no' > > > > No. See README.Debian. > > This wasn't obvious. > > Please add at least a comment to the default conffile for people to > consult /usr/share/doc/openssh-server/README.Debian.gz why it's on in > by default
Done in CVS. > Considering README.Debian: > > ...If you set it to no, then they must compromise a normal user > account. In the vast majority of cases, this does not give added > security; remember that any account you su to root from is equivalent > to root - compromising this account gives an attacker access to root > easily. > > The reasoning doesn' look sound. It would apperar that two-layer > security is better than one, because one would need to: > > 1) Find a user name. Not a obvious task in small sites. > 2) crack user login > 3) crack the root passwd from within site; > not straight forwards, CPU limits ... watchdogs. > > Instead of hammering root-login directly with botnet attacks. Contrariwise, having system administrators ssh directly to root with a suitable public key often provides a better audit trail than going through a user account. It depends on your site setup. Note that turning on PermitRootLogin is *not* something Debian has done at variance with the rest of the world; this is the upstream default too. When we have turned it off in the past, it's caused problems for real system administrators. (Yes, of course they can change the configuration, but I don't consider it acceptable to arbitrarily add yet another thing to the pile of things sysadmins have to do to new Debian machines that differs from upstream. When there is significant contention, we should stick with the upstream default so that at least there is no *confusion*.) I'm not prepared to have even more interminable arguments about this in Debian bug reports. If you want the default changed, please take it up with upstream so that it's the same for everyone (and I think 'without-password' would be better than 'no', in that case). Normally I would forward reports for people, but I don't do that when it's a matter of opinion that I don't share since I'm not going to be any good at arguing such an opinion. > >> - Add paragraph breaks between option groups > > > > Sounds like an excellent way to generate conffile resolution conflicts > > for anyone who's modified this file. Not worth it. > > If there are already custom modifications, the upgrade suggests > a conflict resolution anyway, no? No. Actually, the local file doesn't get upgraded at all because sshd_config isn't a conffile and we don't yet use ucf for it, so my comment was incorrect. Nevertheless, it would generate revision control conflicts for me when merging from upstream, and to be honest I think the current grouping is fine. If you want to make this sort of cosmetic change, feel free to take it up with upstream. Regards, -- Colin Watson [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
