Quoting Gavin McCullagh (ilug_gmc at fiachra.ucd.ie):
> Well, I hate to say it but I'm running debian sarge on two different
> machines and I've checked the config which had in both cases
> (/etc/ssh/sshd_config):
>> PermitRootLogin yes
(Late comment just before sending: You're absolutely right. More
below.)
I have no idea from personal knowledge what the installation defaults
are, for two reasons: (1) Can't recall when it was that any of those
boxen were first installed, but it's almost certainly a long time ago.
(One tends to not reinstall Debian boxes; you just keep progressively
tracking a development branch from version to version.) (2) No
distribution's installation defaults last longer than about sixty
seconds when I'm setting up a machine.
> I've check two of a colleagues debian machines (one stable and one testing,
> installed in the past six months) to which I have a login and again both
> allow root logins as above.
Well, I don't know about you, but I don't regard _any_ *ix box's initial
installation as completed until I've been over /etc/* pretty
extensively. So, honestly -- upon reflection -- I have no idea whether
PermitRootLogin being set to "No" is my doing or the installer's.
> Actually I think in all cases openssh is pinned back to stable so that
> security updates come through quickly syaing testing is a red herring.
> Might this policy have changed in sarge Rick?
Here's the general answer, as I understand it (not limited just to
OpenSSH):
If you're tracking the testing branch, it's very worthwhile to keep
security.debian.org entries in /etc/apt/sources.list for both the stable
and testing branches, like so:
deb http://security.debian.org testing/updates main contrib non-free
deb http://security.debian.org stable/updates main contrib non-free
However, _if_ on the testing branch, you cannot just trust to apt-get to
automatically fetch appropriate security fixes, as you can on stable.
(The Debian Security FAQ stresses that point: They maintain an apt
repository for testing-branch packages, but make no service commitment.)
Instead, what you have to do is browse Debian Security Advisory e-mails
as they come out, see if any are relevant to your system, and (if so)
take whatever corrective steps are necessary. Sometimes, just pulling
automatic package-fetches via apt-get from security.debian.org will get
you a suitable patched version. Other times, doing "apt-get -t unstable
install <pkgname> will do the trick. Or you might have to go find a
suitable .deb with a Web browser, fetch it, and do "dpkg -i" -- like
maybe one from the stable branch. Generally, there's no big problem,
but nobody guarantees security updating will happen automagically
(on testing).
People who enjoy just turning their minds off and trusting the Debian
Security Team to (in effect) remotely administer their systems should
run "stable". ;->
> I'm sure I haven't changed this setting.
OK, then that must be the Debian default, then -- and something I
absent-mindedly fix on every system without being quite aware of doing
so.
Thank you for investigating! (I agree with the guy who wrote that
template file.)
--
Cheers, Founding member of the Hyphenation Society, a grassroots-based,
Rick Moen not-for-profit, locally-owned-and-operated, cooperatively-managed,
rick at linuxmafia.com modern-American-English-usage-improvement association.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!