On Tue, 2016-10-04 at 09:47 -0600, Chris Murphy wrote:
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,
Not by default, but
it can be be enabled by a boot option:
https://github.com/rhinstaller/anaconda/blob/master/docs/boot-options.r
st#instsshd
The SSH password for the installation environment can be set by
kickstart:
https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-d
ocs.rst#sshpw
> 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.
>
>
>