blank password login via ssh

[lordfolken]

As soon as OV has a connection, sshing into the ip with the root user, yields instant access without password.

Comcast also thought this would be a good idea. Lets not be Comcast.

There seems to be a yocto image option: image-features

allow-empty-password: Allows Dropbear and OpenSSH to accept root logins and logins from accounts having an empty password string.

We should disable this.

[linuxianer99]

also discussed in #27

[lordfolken]

That commit just manages ssh. It doesn't solve the problem that login without any credentials is possible. The -B switch for dropbear needs to go.

[linuxianer99]

That commit just manages ssh. It doesn't solve the problem that login without any credentials is possible. The -B switch for dropbear needs to go.

Ok ... it was auto-closed due to your commit message ... Should we open the issue again ?

[lordfolken]

@linuxianer99 yes please. Its still an issue.

1. dropbear is still startable via socket activation, so its not disabled.
2. there is still the -B switch for blank passwords.

I meanwhile found the culprit: https://github.com/Openvario/meta-openvario/blob/995b173497133e265b124906288af22703d0afdb/conf/local.conf#L118-L123

[MaxKellermann]

1. dropbear is still startable via socket activation, so its not disabled.

Not true - the systemd socket is disabled by default: https://github.com/Openvario/meta-openvario/blob/995b173497133e265b124906288af22703d0afdb/meta-ov/recipes-apps/ovmenu-ng/files/disable_dropbear.preset#L1

It will only be enabled (temporarily) after explicit user action: https://github.com/Openvario/meta-openvario/blob/995b173497133e265b124906288af22703d0afdb/meta-ov/recipes-apps/ovmenu-ng/files/ovmenu-ng.sh#L215-L224

[lordfolken]

i can ssh into the box, without touching that menu. All i do is start connmanctl and connect to wifi.

"Disabling a service means it will not start at boot, but can be started manually, or as a dependency of another service. Enabling or disabling a running service does not automatically change its current state; if it is running it will continue to run, and if it is not running it will not start. "

"A masked service cannot be started by any means, and must be unmasked to be usable. "

[MaxKellermann]

I know all of that. But about:

Enabling or disabling a running service does not automatically change its current state;

... unless one uses the --now parametr!

but can be started manually, or as a dependency of another service

So... which dependency caused dropbear.socket to start on your OV?

[MaxKellermann]

root@openvario-7-PQ070:~# systemctl list-dependencies --reverse dropbear.socket
dropbear.socket

On my OV, there are no dependencies on dropbear.socket. Are you sure you're running a fresh image? What does systemctl status dropbear.socket say? Here:

     Loaded: loaded (/lib/systemd/system/dropbear.socket; disabled; vendor preset: disabled)

Does /etc/systemd/system/sockets.target.wants/dropbear.socket exist? If yes, what is its time stamp?

[MaxKellermann]

I double-checked this, and indeed dropbear.socket comes enabled in the OpenVario image (sorry folken), even though it is disabled by a vendor preset. That is a Yocto bug which I did not notice when I changed the default: the ipkg postinst unconditionally calls systemctl enable in some circumstances, and systemctl preset in others. This makes no sense, only preset is correct and leads to the correct result.

I have an idea how to work around this (patching SYSTEMD_AUTO_ENABLE:pn-dropbear), but I have another idea how to properly fix this; I'll write a new systemd target which boots exactly what we need, but no more. This will give us more control over the userspace boot process. Then, say, openvario.target gets booted instead of multi-user.target; an OpenVario is not a general-purpose multi-user computer, so it makes little sense to act as if it were.

[mihu-ov]

I understand it is good practice to disable SSH access until specifically enabled but think a user should be able to enable SSH using a stick remote only, without a keyboard connected to OV. Ideally, once enabled, the setting should be persistent and survive updates. With SSH enabled a smartphone can be used to transfer files over SFTP or even as a terminal, for advanced users this is more convenient than downloading files on a laptop, transfer them to an USB drive and upload from there to OV.

[MaxKellermann]

@mihu-ov that is exactly what I implemented. (Minus the auto-enable bug.)

[mihu-ov]

Great, thank you Max.

[lordfolken]

There two points should be address at the minimum:

• generate a root password and display it to user from omenu
• remove the option in local.conf for blank password autheentication (dropbear -B is evil.,)