Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


new image 8.3.x using an older backup/restore
#1
I think I've probably glossed over too many details with regard to the new security setup since 8.3.0, and what implications there may or may not be when restoring from an older backup. 

The sole reason why I've ever really needed to use the back/restore function is to preserve numerous custom internet radio stations. All other configuration steps take me literally 1 minute, no sweat, I don't actually need to use a backup for that, but the custom internet radio stations would take forever, and thus I've used backup/restore ever since the radio station manager was changed some versions ago whereby there is no longer a separate radio station only backup/restore tool or procedure.

I had numerous problems with the recent Moode updates resulting in a bricked system, both in-place updates to existing working images, and new images written using the Raspberry Pi Imager tool, using with the media player OS option, or using an image downloaded to my computer.

Somehow my last attempt using Balena Etcher in writing a new image, then having the ability to boot that image and enter the System config to apply an older backup and restore my settings and radio stations actually worked, and resulted in a working 8.3.2 on a new 8GB v1.5 board. All other previous attempts using that same board and same new microSD card had failed. I can enable SSH on that instance after restoring the backup, however the old userid and password are rejected.

So my question is this: If in a previous backup SSH was set to disabled, and there had been no previous attempt in that instance to change the userid or password, if I then apply that backup to a newly written 8.3.x image, will my userid and password remain the old and now considered no longer secure combination from 8.2.x and prior?

If yes to the above, I can still restore from that backup, and then just use the instructions for how to change the userid and password on Existing Installations, i.e. sudo rename-user?

On a Lite image such as Moode, I can use sudo rename-user via SSH?

Or is there a better way to utilize an older backup that was configured for SSH disabled, with no change to the userid or password, and a new 8.3.x image?

The goal is to preserve and restore a ton of custom internet radio stations contained in the backup, while adhering to the new security setup.
Reply
#2
(04-30-2023, 02:46 PM)MikeyFresh Wrote: I think I've probably glossed over too many details with regard to the new security setup since 8.3.0, and what implications there may or may not be when restoring from an older backup. 

The sole reason why I've ever really needed to use the back/restore function is to preserve numerous custom internet radio stations. All other configuration steps take me literally 1 minute, no sweat, I don't actually need to use a backup for that, but the custom internet radio stations would take forever, and thus I've used backup/restore ever since the radio station manager was changed some versions ago whereby there is no longer a separate radio station only backup/restore tool or procedure.

I had numerous problems with the recent Moode updates resulting in a bricked system, both in-place updates to existing working images, and new images written using the Raspberry Pi Imager tool, using with the media player OS option, or using an image downloaded to my computer.

Somehow my last attempt using Balena Etcher in writing a new image, then having the ability to boot that image and enter the System config to apply an older backup and restore my settings and radio stations actually worked, and resulted in a working 8.3.2 on a new 8GB v1.5 board. All other previous attempts using that same board and same new microSD card had failed. I can enable SSH on that instance after restoring the backup, however the old userid and password are rejected.

So my question is this: If in a previous backup SSH was set to disabled, and there had been no previous attempt in that instance to change the userid or password, if I then apply that backup to a newly written 8.3.x image, will my userid and password remain the old and now considered no longer secure combination from 8.2.x and prior?

If yes to the above, I can still restore from that backup, and then just use the instructions for how to change the userid and password on Existing Installations, i.e. sudo rename-user?

On a Lite image such as Moode, I can use sudo rename-user via SSH?

Or is there a better way to utilize an older backup that was configured for SSH disabled, with no change to the userid or password, and a new 8.3.x image?

The goal is to preserve and restore a ton of custom internet radio stations contained in the backup, while adhering to the new security setup.

SSH service and OS userid/password are strictly outside and independent of moOde Backup/Restore feature. If your Restore to 832 is not working then troubleshooting will be needed.

Also, if the Raspberry Pi Imager method of prepping a new image with SSH and userid/password etc is not working according to the Setup guide then I'll need some help in trying to create a failure repro because on my end it's working perfectly.

Just be aware that I'm limited to using MacOS for the Pi Imager. If the Pi Imager app is not working correctly on Windows or Linux desktops then another dev with those OS's will need to help troubleshoot.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#3
(04-30-2023, 03:16 PM)Tim Curtis Wrote:
(04-30-2023, 02:46 PM)MikeyFresh Wrote: I think I've probably glossed over too many details with regard to the new security setup since 8.3.0, and what implications there may or may not be when restoring from an older backup. 

The sole reason why I've ever really needed to use the back/restore function is to preserve numerous custom internet radio stations. All other configuration steps take me literally 1 minute, no sweat, I don't actually need to use a backup for that, but the custom internet radio stations would take forever, and thus I've used backup/restore ever since the radio station manager was changed some versions ago whereby there is no longer a separate radio station only backup/restore tool or procedure.

I had numerous problems with the recent Moode updates resulting in a bricked system, both in-place updates to existing working images, and new images written using the Raspberry Pi Imager tool, using with the media player OS option, or using an image downloaded to my computer.

Somehow my last attempt using Balena Etcher in writing a new image, then having the ability to boot that image and enter the System config to apply an older backup and restore my settings and radio stations actually worked, and resulted in a working 8.3.2 on a new 8GB v1.5 board. All other previous attempts using that same board and same new microSD card had failed. I can enable SSH on that instance after restoring the backup, however the old userid and password are rejected.

So my question is this: If in a previous backup SSH was set to disabled, and there had been no previous attempt in that instance to change the userid or password, if I then apply that backup to a newly written 8.3.x image, will my userid and password remain the old and now considered no longer secure combination from 8.2.x and prior?

If yes to the above, I can still restore from that backup, and then just use the instructions for how to change the userid and password on Existing Installations, i.e. sudo rename-user?

On a Lite image such as Moode, I can use sudo rename-user via SSH?

Or is there a better way to utilize an older backup that was configured for SSH disabled, with no change to the userid or password, and a new 8.3.x image?

The goal is to preserve and restore a ton of custom internet radio stations contained in the backup, while adhering to the new security setup.

SSH service and OS userid/password are strictly outside and independent of moOde Backup/Restore feature. If your Restore to 832 is not working then troubleshooting will be needed.

Also, if the Raspberry Pi Imager method of prepping a new image with SSH and userid/password etc is not working according to the Setup guide then I'll need some help in trying to create a failure repro because on my end it's working perfectly.

Just be aware that I'm limited to using MacOS for the Pi Imager. If the Pi Imager app is not working correctly on Windows or Linux desktops then another dev with those OS's will need to help troubleshoot.

Thanks Tim, my original attempts at this described above were all a week or more ago, so I won't bother trying to remember what exactly happened in each instance, the above is the best I can describe it at this point and it's water under the bridge, I will try to move forward today with some fresh attempts.

I just prepared a brand new 8.3.2 image using the Raspberry Pi Imager tool (like you on macOS) and went through the new security setup as well to create a userid and password, and I also enabled SSH though I plan to eventually just turn that on/off as needed.

I will boot this new image and see if I can restore my backup, and I appreciate the confirmation that all of that should be entirely separate of the userid/password/SSH elections I just made in the RPi Imager tool.

That backup has a different host name than what I just elected in the imager tool, so after I restore the backup I just revise that hostname right back again to what I want it to be in this new instance?
Reply
#4
@Tim Curtis 

As an aside in response to your last point about testing the use of the Raspberry Pi Imager, I use it routinely on my Linux hosts and can use it on my Windows 10 guest OS albeit somewhat clumsily. If push came to shove, I could "borrow" time on my partner's Win10 laptop. 

Regards,
Kent
Reply
#5
My fresh attempt this morning is so far showing no signs of any trouble, the newly written 8.3.2 image with security setup and SSH enabled via the Pi Imager tool is functioning, playing JB Radio2 for an hour or so now, I had left the house and I've now returned to find it running as normal.

Now I'll try to apply my backup and see how that goes.
Reply
#6
Restore from backup went fine, so it's now entirely unclear to me what all of my troubles were a week or so ago, but they were similar to what a few others are reporting, and they were occurred variously with an in-place update attempt, flashing a new image with the Pi Imager tool, and trying to restore a backup.

To answer my own question about what the host name will be after restoring from an older backup, in Configure -> System -> General, the Host name/player reverted to moode, however my newly chosen userid.local is what brings up the UI, and not moode.local.

Additionally, as you indicated, that new userid and password persisted after the restore from backup, and I can login using them via SSH, which I will now disable until such time as it's ever needed.
Reply
#7
So I guess to wrap this in my own head I'll explain what my original (flawed?) thinking was with regard to use of the new security setup or not.

I had thought perhaps the ultimate security was to skip the userid and password entirely, so instead of leaving an open door via the old default userid and password, how about no door at all?

In other words don't even setup a userid/password/SSH at all, then there is no way for a malicious/unauthorized access to occur. That did not go well last week at all, however doing it in the manner prescribed/specified worked just fine today, with the one bit above about Moode's UI thinking the Host name/player was moode after a restore from backup, even though it was actually my new userid.local that brought up the UI, and that new userid is also what worked via SSH.
Reply
#8
(04-30-2023, 05:31 PM)MikeyFresh Wrote: So I guess to wrap this in my own head I'll explain what my original (flawed?) thinking was with regard to use of the new security setup or not.

I had thought perhaps the ultimate security was to skip the userid and password entirely, so instead of leaving an open door via the old default userid and password, how about no door at all?

In other words don't even setup a userid/password/SSH at all, then there is no way for a malicious/unauthorized access to occur. That did not go well last week at all, however doing it in the manner prescribed/specified worked just fine today, with the one bit above about Moode's UI thinking the Host name/player was moode after a restore from backup, even though it was actually my new userid.local that brought up the UI, and that new userid is also what worked via SSH.

To your point, the Setup guide didn't explicitly state that SSH and userid/password are in fact required for moOde to operate correctly, and for being able to get logs and such for troubleshooting issues.

I've updated the guide for upcoming 8.3.3 release (Q3 2023)

ETA: Here is the updated section with the new NOTE.
 
Code:
OS IMAGE AND SECURITY

The OS image does not contain the userid pi, SSH service, WiFi SSID or Access
Point password.

- Use the official Raspberry Pi Imager to choose a moOde OS image, enable SSH,
  create the pi userid and password and optionally a WiFi SSID and password.

  NOTE: SSH and userid/password are required for correct operation of moOde.

  The moOde OS images are listed in the "Media Player OS" category or if they
  were downloaded directly via the Download page at http://moodeaudio.org they
  can be selected via the "Use custom" category.

- Refer to the links below for more information on operating system security
  and how to download and use the Raspberry Pi Imager.
  https://www.raspberrypi.com/software/
  https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/

- The Access Point password can be entered via the WebUI, Network Config screen
  after the system starts or via an edited /boot/moodecfg.ini file. The file is
  described in this document in the CUSTOM CONFIGURATION section.

To access the operating system command console use Secure Shell (SSH). An easy
to use WebSSH terminal is available in System Config.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#9
(04-30-2023, 05:31 PM)MikeyFresh Wrote: So I guess to wrap this in my own head I'll explain what my original (flawed?) thinking was with regard to use of the new security setup or not.

I had thought perhaps the ultimate security was to skip the userid and password entirely, so instead of leaving an open door via the old default userid and password, how about no door at all?

In other words don't even setup a userid/password/SSH at all, then there is no way for a malicious/unauthorized access to occur. That did not go well last week at all, however doing it in the manner prescribed/specified worked just fine today, with the one bit above about Moode's UI thinking the Host name/player was moode after a restore from backup, even though it was actually my new userid.local that brought up the UI, and that new userid is also what worked via SSH.



It's not SSH that's the problem. The security problem is the fact that gazillions of raspberry pis have been put in use with any of only a few username/password pairs well known because they've been published on the Internet (this has also been true for a number of other devices such as routers as well). The small number of such pairs makes for easy credential stuffing attacks.

In my personal opinion, simply changing the password to something known only to you is the critical step; changing the username, not so much. Public key authentication, also supported by SSH, is far superior to using passwords. Of course, if the bad guys have access to your LAN, then it's pretty much game over anyway. Proper firewall management and use of NAT is helpful there. If you have IPv6 running on your LAN and through your router to the Internet then you have more headaches.

The fact that restoring a backup created confusion over the hostname sounds like a bug.

As an aside, in recent versions of moOde you can choose to backup only the radio stations---the predefined stations AND/OR your added stations. This writes a (zipped) file containing only the station data in json format as well as the logo images. This file can be restored to any moOde player without affecting the system configuration/preferences. It's an effective way to preserve your custom stations.


Regards,
Kent
Reply
#10
(05-01-2023, 03:27 AM)TheOldPresbyope Wrote:
(04-30-2023, 05:31 PM)MikeyFresh Wrote: So I guess to wrap this in my own head I'll explain what my original (flawed?) thinking was with regard to use of the new security setup or not.

I had thought perhaps the ultimate security was to skip the userid and password entirely, so instead of leaving an open door via the old default userid and password, how about no door at all?

In other words don't even setup a userid/password/SSH at all, then there is no way for a malicious/unauthorized access to occur. That did not go well last week at all, however doing it in the manner prescribed/specified worked just fine today, with the one bit above about Moode's UI thinking the Host name/player was moode after a restore from backup, even though it was actually my new userid.local that brought up the UI, and that new userid is also what worked via SSH.

It's not SSH that's the problem. The security problem is the fact that gazillions of raspberry pis have been put in use with any of only a few username/password pairs well known because they've been published on the Internet (this has also been true for a number of other devices such as routers as well). The small number of such pairs makes for easy credential stuffing attacks.

Understood however I never had SSH enabled 24/7 anyway, to your point it's the default userid and password that are the real problem being addressed.

(05-01-2023, 03:27 AM)TheOldPresbyope Wrote: In my personal opinion, simply changing the password to something known only to you is the critical step; changing the username, not so much. Public key authentication, also supported by SSH, is far superior to using passwords. Of course, if the bad guys have access to your LAN, then it's pretty much game over anyway. Proper firewall management and use of NAT is helpful there. If you have IPv6 running on your LAN and through your router to the Internet then you have more headaches.

Regards,
Kent

Agreed, though not a huge problem, perhaps a source of confusion for me one week ago, but not today after a better understanding of the situation as a whole.

(05-01-2023, 03:27 AM)TheOldPresbyope Wrote: As an aside, in recent versions of moOde you can choose to backup only the radio stations---the predefined stations AND/OR your added stations. This writes a (zipped) file containing only the station data in json format as well as the logo images. This file can be restored to any moOde player without affecting the system configuration/preferences. It's an effective way to preserve your custom stations.


Regards,
Kent

Now that is news to me, and not something I'd seen clearly explained previously, or even now. How is this done in terms of save and restore?
Reply


Forum Jump: