On 10/04/2016 11:47 AM, 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.
Maybe from HTTP overhead, but otherwise they're ultimately going to use the same
PAM stack (with whatever lockout policy we implement).
> 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.
I mentioned in another reply that the problem with this approach is that
Cockpit's communication between machines (when managing more than one) is via
SSH as well, so this would make it very hard to initially get them running.