Immortal ghosts from the past

[franco]

I think we can find a way to make this feasible... https://github.com/opnsense/core/issues/1072

[Zeitkind]

You can install Mac OS X server via VNC resp. Apple Remote Desktop. This is verrrrry nice to have and handy and I love it. The login is the serial number of that machine, the hostname (to be found eg. via DHCP server ) has the MAC of the first NIC.

I guess it could be kinda easy to get a vnc server running and also use root/MAC-address as login? ^^

[fabian]

Doesn't VNC require X?

[franco]

The first batch went in as https://github.com/opnsense/core/commit/710f00e84

It's missing a default SSH setup in installation mode as the second batch, then the new user "installer" can be reached via root's password.

I'm pondering security implications for automagically starting the SSH daemon with permissive rights. At least the system cannot be compromised forcing entry without a proper root password, but if e.g. the root password is still the default this can cause problems. Then again the same applies for the GUI in every case.

Any thoughts?

[franco]

Pretty picture: https://twitter.com/fitchitis/status/762702508024291329

[MrCCL]

Wau!!!!!

Altough I don't have the technical insight to get the meaning of the "missing SSH setup in installation mode......"

I hope not the security concerns will be an issues for not having this feature...not that I see any myself.

IMO this will really be a deal-breaker compared to PFsense! (Well, one more the list :-))

[Zeitkind]

Well yes, there are security things involved. If you set up a device like this (with a default known root password), you have to ensure that no one else can touch your ethernet.. ^^
A second way might be to change the root password in ssh-mode to e.g. the MAC-address of the first ethernet interface (either xx:xx:.. or xx-xx-..). Apple uses the serial number of the machines, but well, standard hardware doesn't have this or in a different way (like HP or Dell). So, common feature is the MAC, which is often on a sticker on the machines anyway.

[MrCCL]

Then set web-gui password to the MAC address also....and if not?....then don't set it to to the SSH either of the same reasons.

Why is SSH more insecure than the web-interface....I would say it's the other way around, if any difference.

[franco]

Hmm, yes, a better root password mechanism needs to be implemented, but if we talk "headless" how can you see the displayed password / peek at the MAC address? Handling appliances with stickers is pretty easy. Software-only distributions get trickier. We could easily set it during install, the wizard asks for it to be changed on first boot. But what happens before that initial system touch?

I agree that SSH is the same danger level as the GUI, one or two channels doesn't make a difference. Especially with PermitRootLogin, which is needed for the installer to run in the first place... Then again it's only on install media when it'll be run.

The GUI login is protected by firewall rules from !LAN, the same applies to SSH.

All the code is in now, pending more testing over the next weeks. If this doesn't work out no harm ripping out the bits again.

[MrCCL]

For those who might be in a insecure LAN environment, e.g. an educational institution or other public installations,  they can still make the initial setup using VGA, serial or a  private network. No one are forced to install OPNsense connected to an insecure LAN.
They just need to know!
Perhaps a warning could be placed at the download page "Be aware SSH is enabled in the initial installation process using default root password".

And the install process could ask the user to disable SSH as one of the last setup options/questions.

Maybe this would be an acceptable compromise?

[franco]

It's a live system that is supposed to boot up with all the features, enable SSH on the side so it can be reached via SSH for installation. I don't see how a question could be asked whether or not SSH should be enabled if the only way to reach the system is remotely via SSH itself or the GUI without further complicating it with "for optional insecure SSH access log into mandatory insecure GUI and enable SSH". People just want to install...

[MrCCL]

I agree.
I'm not talking about having SSH is enabled when the installation starts, that's implicit ;-)
But after.....if anyone find that to be a problem. Then it could be a way of making sure no one have SSH enable by default without knowing it in the "normal stage ", so to speak.

But I don't see it to be problem myself at all...but I only got criticism in the threat for suggesting default SSH, that's why, just thinking of a way to make those critical voices more happy :-)

But I'm sure you have much more important things to do than implementing this SSH asking...but if people gets crazy about it, it could be a half-way-solution.

[Zeitkind]

Well, if you deploy machines in a big network, security matters for sure. So my suggestion is, that the installer takes care of user interaction right after start. Like a timer that waits for a keyboard pressed (case 1: user has a screen, we take "opnsense" as default root password) and a (decent) timeout and further enabling ssh (case 2: no direct user interaction, we take a MAC as root password). This won't force to change much documentation and won't stress "normal" users but takes care of bigger networks and their specific needs. That's more or less the opposite way it works on many headless systems with a bootloader waiting for a (e.g. serial) interaction to do fancy things like firmware recovery and, if there is no interaction, continues to boot the default headless system with no direct user interaction. Which makes sense, because those devices are headless by default and opnsense is not. So reversing this behavior might be a good idea.

[MrCCL]

In short, you want to implement a timeout, so users connected by VGA or serial can skip the SSH enabling?
You are right, that would make a more secure setup process.
But this timeout feature come with a price: extra coding and hassle for the users who don't wanna bother with monitor, keyboard, serial etc.
Is it worth it? And is this really a real problem?

You're not force to connect it to you insecure LAN until the config is over....for those who are stressed about it.
You're in most cases sitting in front of it anyway, if using VGA or serial.

[franco]

The timeout already exists, it was used for interface configuration (auto vs. manual), defaulting to auto if no keypress was found. I've heard zero feedback for this rework that we did, it seems to work for everybody...  It also makes sure boxes always boot back up into the full system even then the configs cannot be restored.

Now we do the same for the early (install media) boot invoke. Olivier noted a while back that booting into the installer by default is not the best thing to do, so that made sense to finally realign. Now everything is stowed away behind a login prompt of some sort: console, SSH, GUI.

On an install boot, the following now happens:

1. The boot timeouts for launching the installer on keypress, if no event took place it continues with the normal system boot.

2. The boot timeouts for manual interface configuration, otherwise auto-generates a valid interface configuration with a WAN/LAN and continues to boot.

3. Once the system is fully booted (note that this happens without any interaction now), the GUI can be accessed as well as SSH.

I don't see any user-facing issue during testing this. We even managed to lose a bit of old unused and duplicated code in the process.


Cheers,
Franco