Bug 1171177

Summary: security enhancement: don't enable ssh daemon by default
Product: [openSUSE] openSUSE Tumbleweed Reporter: Ludwig Nussel <lnussel>
Component: MicroOSAssignee: Kubic Bugs <kubic-bugs>
Status: RESOLVED WONTFIX QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: rbrown
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Ludwig Nussel 2020-05-05 11:55:44 UTC
MicroOS enables sshd by default ie exposes an open port by default. That violates best practice of the main product to not expose such services by default.

YaST in the main product offers a convenient way to optionally enable ssh in the installation summary screen that could be used for MicroOS as well.

In the appliance case openssh on by default is not very useful anyways as the appliance needs to be configured via ignition to have a password or key in the first place. So ignition could also enable the ssh service if needed.
Comment 1 Thorsten Kukuk 2020-05-05 12:34:55 UTC
From our experience with MicroOS users, the main usage is to login via ssh.
You can see this with Raspberry Pi, where Raspian comes with disabled sshd. They don't get credit for better security, but for bad usability.
We even changed YaST so that you can deploy your ssh key during installation already and don't need to set a root password at all. That's what the people wanted.

Additional, we also learned that people don't change the defaults during installation, many even don't read what they accept, even if you bring up a popup warning them.

For Carwos (so main uscase single computer no remote login), this makes absolute sense. For an OS where people normaly login via ssh, this doesn't make any sense.
Comment 2 Ludwig Nussel 2020-05-05 13:04:06 UTC
rpi is the best example here actually. The appliance is useless by default. You need an Ignition config or you can't log in, not even locally. So we have to provide documentation that includes an example ignition file. That example would also include enabling ssh. We can remove it from from presets though.
Comment 3 Richard Brown 2020-07-03 13:39:38 UTC
I can agree to this for the images, because there needs to be some configuration done on first boot to make the system useful and if you're forced to set the root password you might as well make it mandatory to set ssh also

I disagree with this principle for the YaST installed variations of MicroOS though, for all the reasons Thorsten points out.
Comment 4 Ludwig Nussel 2020-07-06 14:08:24 UTC
Ok, so we agree to remove it from the preset then, thanks :-)

IMO the setting in YaST is a bit inconsistent though. The ssh/on off is a control file setting but the import of the public key has no relation to that. So I've filed https://jira.suse.com/browse/PM-2016 to potentially get an actual check box in the dialog that relates to ssh on/off.
Comment 5 Thorsten Kukuk 2020-10-07 11:59:39 UTC
I'm still missing the benefit for the customer for this change, like PM did (that's why Daniel rejected this for SUSE MicroOS).
Currently, there is no benefit for the customer, but he has to do more work and there is more confusion. This is not customer friendly at all without any advantage for a customer.

To your comment #2: Rasbian/RaspberryOS is the best example of how customer unfriendly this is and that we should not do it. The most frequently question you can find in the net about Rasbian is, how to enable the ssh daemon for the first boot.
Yes, it's only a configure option as you want to have for MicroOS, but customers need to find that first and configure it correct. Additional work to read, understand, and write correct. So many points where they could fail. And then it's not their fault, but our, as we make it so complicated without benefit.
Comment 6 Thorsten Kukuk 2020-10-07 12:00:49 UTC
Between, I'm also missing the security benefit. Your very first sentence is wrong here.
Comment 7 Ludwig Nussel 2020-10-07 14:17:44 UTC
yeah whatever