Octopi enables SSH without changing the default password

[securelyfitz]

What were you doing?

1. install octopi-0.18.0-1.7.2
2. complete web setup
3. login over ssh with pi:raspberry

What did you expect to happen?

The default password should not work.

A possible solution would be to change the pi user's password to whatever the user sets up in the octoprint configuration. I recognize that might be an octoprint-vs-octopi issue though, and could be disruptive if octoprint is one of several services running on a device.

What happened instead?

This is a recognized CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38759

Raspberry pi's config tool will recommend setting a new default password if SSH is enabled. The octoprint image has ssh enabled, but has not forced, recommended, or even reminded about the setting of a new default password.

In addition to the SSH issue, any plugin that can execute code could use those default credentials to escalate privilege to root.

Did the same happen when running OctoPrint in safe mode?

Yes

Version of OctoPi

OctoPrint 1.7.2 Python 3.7.3 OctoPi 0.18.0

Printer model & used firmware incl. version

NA

Screenshot(s)/video(s) showing the problem:

I have read the FAQ.

[guysoft]

Currently this is expected behavior which is done here: https://github.com/guysoft/CustomPiOS/blob/devel/src/modules/base/start_chroot_script#L75

Frankly I am not sure how not to do this, since this is also the behavior or OpenWRT: https://openwrt.org/docs/guide-quick-start/sshadministration

Here is the a displuted CVE or that (can't find a more general example): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11965

@foosel Any thoughts?

[QuinnDamerell]

I don't know how hard this would be, but I think ideally the ssh password would get updated to whatever password the user sets when they do the OctoPrint first-run setup. Or possibly, there could be a new step added to the first run where the user is explicitly asked to set a new ssh password.

How hard would it be to add some kind of action in OctoPrint that would be able to invoke a sudo action to the Linux system? Maybe octopi could have A bundled plugin that has the logic?

[cp2004]

I don't think trying to match the password to the one that the OctoPrint user is setup with is a good idea, keeping the passwords different would definitely be a better option. Don't forget OctoPrint isn't always installed through OctoPi and that some people will not like this change so it would need to be able to be disabled. It also would create confusion, as the password would not match the username that it was setup with. While technically possible, doesn't feel like a good idea.

On https://octoprint.org/download the guide specifically mentions to change the password. It could be made more obvious, maybe done in the RPi imager to try and make people do it. I would probably prefer something like this. It would make support issues so much easier. Could detect that the password is default and nag the user to change it manually as another option.

[guysoft]

There is also the option as is in the Ubuntu install, that you are asked to change the password after first SSH. This is the default setting on Ubuntu Server 21.10 today.

Will note though the question is not how hard would it be, but how can we balance security and usability. Evidently you need some standard way to enter with ssh. And I think the ssh file creation on the boot folder is not a decent way for a headless install.

[QuinnDamerell]

That’s a good point. I know it would be more ideal to have two passwords, but I was thinking sharing the password might be a good lowest common denominator for users. I can’t tell you the number of tickets I get for OE where users don’t even know their OctoPrint password and claim they never set it. So I thinking if setting the ssh password is anything more complicated then setting the OctoPrint password, it’s not going to get done or quickly forgotten. Thus I was thinking setting it as the user‘s OctoPrint password at least makes it not the default. But that’s just my thoughts.

As for setting it, I was thinking maybe OctoPrint could have some kind of hook extension that octopi or any other is could use to get the password when set. And if the os doesn’t hook it, it’s just ignored. Or the maybe more abstract way of doing it would be with a octopi specific plug-in that would hold the logic. I really have no idea how feasible any of that is, I’m just spitballing. 😂

[securelyfitz]

First, thanks all of you for taking this seriously. This is, IMHO, a raspberry pi issue that they're sticking their head in the sand about. If the would choose to fix it, it would solve every single pi-based appliance from having to go through this conversation.

As I've pondered and discussed this with many about it in the past few days, the fundamental issue isn't the SSH, it's the default credentials - SSH is just the easiest exploitation path most people are familiar with. Consider any process on the system can run (echo raspberry;echo sudo whoami)| su - pi since the pi user has a default password and full sudoers permissions.

Right now, if you use rpi-imager and choose to enable SSH, it forces you to choose a new password. (my personal preference would be that it be an unconditional step in rpi-imager). Right now, if you ssh in, it does nag you about the default password, but doesn't force you to do anything.

Your documentation recommends rpi-imager, but already has ssh installed. Perhaps the 'fix' is as easy as adjusting your image to not have ssh on by default and force people through the rpi-imager process.

Another possibility - since the default creds are the issue, regardless of SSH status - what about an octoprint plugin that tests the credentials, and warns (severely, like flashing marquee text on the web ui severe) when they're detected?

[foosel]

I've actually thought about adding such a warning screen to the (bundled) PiSupport Plugin in the past. That would be the IMHO best approach.

Disabling SSH and relying on the user to enable it would cause a ton of issues once something breaks. In my experience people don't read instructions too closely (see also the fact that they don't change the password), so most instances out there would run without ssh enabled, and while it can easily be enabled by creating a simple file, that is also something many struggle with and would add an additional source of frustration, even more so if the user has put the Pi at a more inaccessible place (eg inside the printer) as we've seen a lot in support.

(Additionally) shipping with a different default password might also be an option, with the risk of people following outdated information somewhere on the internet and running into issues due to that.

[guysoft]

I think notifying on the pi support plugin, and perhaps even letting people change from it is the best path.

Also ububtu's approach that they prompt you to change the password on first ssh.

The common approach is, keep it open, but prompt changing the default on first contact.

Is better than - keep it all disabled and required user to enable

[securelyfitz]

One dilemma i'd like to point out about the 'change at first ssh' is that i believe many users will never use SSH. As long as they can power on the Pi and see the web UI, they will stick to that (i've seen this on many projects - the amount of support time spent teaching people how to install putty and the number of requests for 'how to do it without putty'... etc.)

In that case - someone who never used SSH still has default credentials and never saw the nag/reminder, except in the 'part of the instructions i skipped'

One benefit of default credentials - as long as they're a risk, you can get the privileges to change them?

I think i agree with @foosel , putting a warning in the pisupport plugin might be the best, most visible, and all-inclusive solution.

[foosel]

I've created a request for that in the PiSupport repo, see above.

[trothwell]

Consider allowing the user to specify ssh allowed key and prevent sshd from authenticating passwords.

The allowed key could be set in a configuration file: /boot/octopi.*

[foosel]

You can already do this when flashing with Raspberry Pi Imager (which is the recommended way to flash)

[guysoft]

Be it though that I can understand why @trothwell can't find them. They are hidden, related: https://github.com/raspberrypi/rpi-imager/issues/180

[wohali]

With the Pi Foundation's bullseye-based release, and OctoPi 1.0.0rc2, default creds are now disabled. For people still on 0.18.x, @foosel 's detector should be sufficient.

This can probably be closed now.

[RenaKunisaki]

One quirk I noticed is that if I log in and change the password, then refresh the page, it still says the password isn't changed.

[guysoft]

@RenaKunisaki sorry for the delay, you could post that to the OctoPrint issue tracker, since that is not in the scope of OctoPi: https://github.com/OctoPrint/OctoPrint/issues