Brian A. Seklecki wrote:
On Thu, 10 Jul 2008, Jacob Yocom-Piatt wrote:
maybe if people actually READ THE ARCHIVES, they'd be better
informed. i wish this mailing list had
I didn't want to rehash it all again. Everyone knows the issues.
so put your own /etc/ssh/sshd_config into your siteXY.tgz install set
and stop hard-selling this knob twist that would waste a lot of my and
others' time. then your openbsd install can be as secure as you want
with minimal effort.
However, with respect to the right to disagree, if Marco's and
Darrin's belief that if remote-network-postinstall configuration is
the standing reason, then I consider myself in disagreement.
Also, I think there is a false premise to the argument by Marco and
Jacob that disabling remote root login by default does not provide
real security, only a false illusion.
That sounds like a slippery slope. We all know that security is a
process.
There is a security risk / attack vector here, however remote, without
password quality and failed-login tarpid/delay mechanisms, a remote
root password is subject to brute force.
Plus, hypothetically, how strong is a temporary root password going to
be? Its not going to be the one that you use in production, so likely
you're going to recycle the same one after every install.
- Yes qualified administrators filter sshd(8) w/ pf(4)
- Yes qualified administrators choose strong passwords
- Yes qualified administrators disable PermitRootLogin afterboot
- Yes qualified administrators always use sudo(8) and never use
root shells
I propose, as a compromise, wrapping PermitRootLogin around a Match
statement, limited to the default local subnet gleaned during the
install network config (no "LocalSubnets" macro exists in
sshd_config(5), afaik, but that would be best)
Its just the right thing to do; and we should be leading by example.
Either way, its a healthy discussion worth having.
~~BAS
PermitStupidEmails No
as the default.
i really fail to see how this setting does anything other than make
mgmt types worry because they don't really understand security.
