When setting up my Pi I want to change the default login on the pi itself from "Pi" to something else. The problem is that every time I do Octoprint stops working sue to it's dependency on the "Pi" user account. I plan on using my pi in a public makerspace and want to increase my security. I have followed two guides on how to do it and both have resulted in breaking Octoprint.
I am new to coding and will need a little assistance when you ask for logs etc...
Not sure what a sshkey is. But having a universally known username is still a security risk. Ask any security professional. By changing the username someone with malicious intent now has to guess two bits of information to get in. Not just one.
Assume that you've used the ModMyPi suggestions and have renamed the pi username to elvis
Do an ls -al ~/.octoprint to verify that all the files are owned by elvis with a group of elvis. (I assume that the ModMyPi suggestions didn't include creating or otherwise renaming the pi group which is also involved here.) Or leave the files as owned by elvis:pi then (username:group).
If this isn't the case, then I think I would try to recursively chown everything there to the new user you've created (assuming that they're still pi:pi). This goes for everything in the former-pi's home directory.
Edit ~/scripts/octoprint.default and update OCTOPRINT_USER.
You might want to consider adding Access Control in the startup wizard for the sake of security. And you can use sudo raspi-config to update the default password for the pi user as well. I think this is the usual method of trying to keep it secure. Anything else as described above is going to make updating a nightmare.
While it is a bit harder to setup the first time, it can eliminate the use of usernames and passwords for login purposes and now someone with malicious intent needs to have access to NSA level super computers and some number of years to get in.
You can generate separate individual keys for anyone you want to have access so it is easy to remove someone if they should no longer have access
And best of all, I think it will be faster to learn and setup than figuring out all the changes necessary to change the default account name.
There's probably something wrong with my logic here, but, it looks to me like everything is set up to run under user pi
The scripts and everything are programmed to be found under /home/pi/oprint
It seems to me that if you change the username (as in the second link posted) then when octoprint goes to look for its scripts, it won't be able to find them cuz /home/pi/oprint no longer exists
Do a clean install of Raspbian (NOT an octopi image) lite on a different SD card. Then change the user name as in the second link
Then, create a totally other user, and install octopi and octoprint under that new user name, and, since it gets installed under whatever user installs it, that new user will be the owner of Octoprint
Thanks for the info! I'll definitely take an in depth look at sshkey!
As for root... I noticed that by default it is deactivated in the build I am using.
There are far better ways to secure Octo than worrying about the username. How about HTA access or VPN into your network and not let Octo touch the outside world. or even set up access to only allow certain remote IPs or ranges?
these are all better way to secure your set up...assuming you are going to have the HTTP exposed to the outside world - which is not really ideal not matter what.
I use a dedicated user for OctoPrint that is even not allowed to login at all, so it doesn't need a password.
That is a common practice on Unix/Linux systems to use a dedicated user that is not able to login for daemons like mail or web servers, so why not do it for OctoPrint too?
AFAIK only some start scripts depend on the user Pi, so it is not a difficult task.
I can definitively confirm that it is possible to run under a dedicated user. I have set it up like this. If you still want to do this, we need a bit more information which distribution you are using (OctoPi or Raspian or whatever) and what your setup looks like.
On the other hand as already mentioned you should take some general security considerations. The details what you want to do and what you want to allow/deny you did not state/specify. Thus it is too much guessing to make a good statement. In general I would
Deny all password based authentication via SSH (only private/public keys via sshkey)
Let the Octoprint Server run on a local network device (localhost) without access from the outside
Put a webserver that allows SSL-based authentication as a proxy in front of it
Disable any unneeded services
Make regular copies of the SD card image in case anything goes south
It does not look like you need security of fort Knox. But I might have guessed wrong.
