Bug#522745: [security] debian/openssh-server.postinst improved sshd_config
On Mon, Apr 06, 2009 at 10:15:08PM +0300, Jari Aalto wrote:
> Colin Watson <email@example.com> 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
> 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.
Colin Watson [firstname.lastname@example.org]