On Tue, Oct 4, 2016 at 1:16 AM, Lars Seipel <lars.seipel(a)gmail.com> wrote:
On Mon, Oct 03, 2016 at 09:03:05AM -0600, Chris Murphy wrote:
> An alternative might be disabling sshd out of the box. It could be
> turned on via cockpit, and require no additional configuration to ssh
> login. That perhaps is a compromise between better out of the box
> security and usability.
Having to manually log in to a web interface before you can use your
server is a waste of time and an absolut non-solution.
OK.
Doesn't Cockpit allow password-based login just as well? Why do
you
consider it any more resistant to attack than OpenSSH sshd?
Most ssh attacks are initiated by bots. Could someone teach a bot how
to iterate Cockpit logins? OK sure, and then teach the bot how to
"navigate" and turn on services it wants to exploit, like ssh.
Possible but pretty unlikely. Also I'd expect there's a much much
longer time delay in between failed Cockpit logins compared to sshd.
Of course, public-key-based auth would be the superior approach. But
short of installing from a custom kickstart, you need a way to get your
keys to the machine in the first place. Disabling sshd without solving
the actual problem first is only going to annoy users.
That's why I was suggesting adding the key via Cockpit. I'll buy that
it's a hurdle or two to do that. But it's the same over on macOS and
Windows - these services are not enabled out of the box even on their
server equivalents. I'm all in favor of doing better than that. But
the idea that it's untenable isn't convincing seeing as many people do
exactly that and aren't super bothered by it.
If the officially supported install method for Server created
customized
images with integrated SSH keys, that would be the point where no one
would mind the disabling of password logins.
Sounds like two parts: some method of transferring the client pub key
to the install target, and a method for the installer to install it in
the correct location. The install media doesn't enable ssh, and even
if it were enabled, no user exists with a default password so it's not
possible to scp.
Rudimentary idea: have the install media created with sshd enabled;
when the sysadmin doing the OS installation creates the first (admin)
user and password, use that not just for the installed system but also
for the running installation environment; now it's possible to scp the
public key to say /tmp where a post-install script puts it into the
correct location once created.
--
Chris Murphy