Fixed. Seems there was an "edit" sub-path in the url, so Github thought you wanted to edit the page. Which is why he required you to logon to github...
Make sure that you only allow access to required commands, not full sudo access. So, using visudo, something like
bart ALL=(ALL) NOPASSWD: /bin/systemctl
Then only that command can be run from node-red.
1 Like
Thanks for taking the time to explain Bart.
You should certainly lock that down and you should certainly run Node-RED under a separate user id anyway. You can still enable users to do things like restart node-red by adding the command to sudoers without a password prompt. Restarting Node-RED is often not that insecure though possible to get a denial of service that way. Allowing the Node-RED user to restart the Pi might be more problematic.
One way around these issues is to have 2 instances of Node-RED. A more secure instance that runs under a separate id and that has a defined API that controls things like restarts (and restricts how often the restart is allowed for example so you don't get DOS'd) and the more generic instance - still under its own id. That one doesn't have privileged access but may be able to request things via the secure instance. This gives you a lot more control and an extra layer of security to work with.
When working with a Pi it is particularly important that you control access of course because the Pi user is TOTALLY OPEN with access to do anything. It is set that way to let the Pi be used as a learning and exploratory device, not for security. If you want a secure Pi, you really need to get rid of the Pi user and group.
Of course, we are really getting into the weeds here and, at the end of the day, you have to decide what your risks are and how much you want to try and mitigate them.
For me personally, my home server cannot be accessed directly from the Internet at all. I have some flows where I can control certain things and request certain information via Telegram. Then I have a couple of specific endpoints defined via Cloudflare Zero Trust - but the Node-RED editor isn't included by default. However, I do have a method that would let me turn on access should I need it.
But then, as I always say, my profession and experience makes me more than averagely paranoid. 
2 Likes
Is it possible to specify parameters on the allowed command? So allow sudo systemctl restart nodered but not other systemctl commands. I could not find any evidence that one could do that.
Yes, absolutely. And you can restrict to specific users or groups.
For example, here is 1 line from my live server:
/usr/sbin/iwlist wlp3s0 scan | grep -B 2 ESSID
Which, as you can see, is a complete BASH command line.
How do you put that into the NOPASSWD spec in sudoers?
You do sudo sudoers as usual, then you should have a line for the user you want to change:
myuser ALL= NOPASSWD:/some/command with params \
/usr/sbin/iwlist wlp3s0 scan | grep -B 2 ESSID
Note the trailing \ which is a line continuation marker so that you can lay things out in a way that is comprehensible. 
Oh, I see. I didn't see any examples of that anywhere.
So to limit systemctl to restarting node-red I can just use
me ALL=(ALL) NOPASSWD: /bin/systemctl restart nodered
Excellent, thanks.
1 Like
I also created a small simple service for secure access to local servers:
It doesn't have a lot of features, but it also has no dependencies on the client side (except for a browser) and it's super simple to setup.
1 Like
