On 02/01/2014 12:03 AM, Jake Linkous wrote:
I'd say by installing an SSH server and having it run on boot without letting the user know. root's password complexity is a quantitative measure, meaning it takes some time to bruteforce, but the SSH installation is a qualitative one - it makes no sense to bruteforce an SSH server that isn't running.-----Original Message----- From: grihad@gmail.com Sent: Fri, 31 Jan 2014 17:55:51 +0400 To: debian-live@lists.debian.org Subject: Live CD default sshd install allowed root privileges to be gained <snip> The break in was caused by the fact that Debian's Live CD installed and enabled SSH server to run (with PermitRootLogin enabled) without telling me about it - I don't need an SSH server at home and would never run it in this way with an easy to guess root password, which was simply root, because I would never use the root account for logging in via network and would definitely harden SSH configuration with AllowUsers, public keys, firewall etc. I did install & enable a permissive iptables firewall ("deny by default"), but a day or two after the break-in, long before I detected the intrusion and what caused it.The problem appears to all come down to the poor choice of using root as the root password.
Either warn the user that an SSH server has been installed & configured to run on boot, or present him with a list of services to run on boot with sensible defaults already checked. FreeBSD installer does the latter.If you are arguing for a change in behavior/action then you should state what change you desire and present an argument for such change. As far as I know upstream ships with rootlogin enabled, and the debian maintainers have considered the issue and left it as is. What exactly are you wanting in regards to this issue?