mpvader - Per the latest Venus OS beta versions...
Making SignalK server work with externally set password?
Per the latest Venus OS beta versions, we’ve added a network security profile setting; which allows securing all local access with a single password.
So thats remote console, gui-v2, mqtt (if enabled/needed), and Node-RED is and/or was secured with the same password as well.
How could we go about using the same for Signal-K? Are there config options for that already? I checked, but couldn’t find any.
And we might have discussed this earlier @Scott Bender / @Teppo Kurki , but then I forgot the outcome 🙈
51 Replies
Main reason to want this is to making onboarding for new users easier.
@Ilker showed me some stats the other day, that for his saillogger app the use of cerbos versus raspberrypis is quite significant. A surprise, nice one!
What might make this a bit extra complex is that er have an “unsecured” option in Venus OS, which means no password at all.
So to harmonise that, signalk would also need to have such option.
Are talking single sign on?
Possibly, but not necessarily
But its an option maybe; we do have that for the other services. A simple 365 days stored cookie; and nginx checking it
What I meant was more to do something so that the user doesn’t have to set a password up in signalk, since he has one already
The security stuff in the server is essentially "pluggable", so, in theory, with some work, we should be able to do anything we want
Also, Signal K comes with passwordless in the initial configuration. The problem with that though is some functions (like restarting the server) is not available when password is not set. So it requires rebooting the host platform (Venus OS or RPi, etc) when that happens which is pretty frictionful.
The security stuff in the server is essentially "pluggable", so, in theory, with some work, we should be able to do anything we want@Scott Bender to understand this more, let's say I want to set a password or change it from a plugin or a daemon, how do I do it? A similar question I have is around basic server settings, name/MMSI etc, I can write them on the json directly I guess but is there a way to do it differently?
You could use the same http endpoints that the admin ui uses.
Requires authentication of course
How do you get authenticated the first time to set the password if there is no password set?
That first time does not require authentication
Relatedly is there a way to restart Signal K programmatically when there is no password set?
There’s no interface for it, but all it really does is exit the process.
And then the os starts it back up
I think we’ve discussed removing that limitation, I don’t remember where that ended up…
Venus OS can restart it
The restarting of it is not a problem
Getting off topic I think
@Ilker please start another thread if you want to talk about this more…
Keeping the password inside signalk server in sync with the venus os pwd, using https or other method, seems error prone
Agreed
Yes agree
Can you get me info on the cookie that you’re using? Including how to validate it.
@mpvader VenusOS is nowadays using one of the real http servers, right? i forget which one
one very clean solution would be to run a reverse proxy in front of the sk server, which should bind to localhost. the reverse proxy would add a header that the sk server should trust for authentication
What do you mean “blind to localhost”?
if it listens only on localhost and none of the externally accessible interfaces the only way to access it from the outside would be via the reverse proxy
if it were accessible from the outside it would be susceptible to spoofing the trusted header that would need to be signed
Yep
nginx
perfect reverse proxy
and headers can be readily added
They are using nginx, definitely doable
needs a bit of work on the skServer side
Iirc it does the ssh + auth part for node-red.
https://github.com/victronenergy/meta-victronenergy/blob/master/meta-venus/recipes-extended/node-red-venus/files/nginx-rules
Node-red itself binds to localhosr only
Could btw be that it doesn’t do auth yet; and can’t test that now
I was going to ask about that../
Our prio wrt all this was to get the core functionality out
But making it to security shouldn’t be too hard
We have a login page; and cookie setting.
And its used for both remote console (vnc in browser) as well as for the webassembly one.
In other words, same page is already used for multiple webapps
I won’t be spending time on that one myself. And I’m not familar with ngingx too much anyway
Source code of the login page is here: https://github.com/victronenergy/venus-www
I can work on a generic “sso” kind of thing for the server. I think it could be useful in other cases also. Like people have wanted to be logged in automatically if on the local network.
Oh. It’s not a cookie?
Yuk. Session variable.
Ok. Persistent sessions.
We definitely can’t use that session cookie, I don’t even think nginx would be able to.
I’ll be interested to see how you do the node-red auth. I must be missing something here…
Guessing the session cookie is not signed
Maybe it doesn’t do that yet in that way
lol. The long lost security expert in me is coming out…. 🤣
Its easy enough to check, but then you need a GX device or Pi handy; and I don’t have that
Install the latest beta, set secure mode, try open node-red on port https://ip:1881/
If you get the central login page, then its in somewhere there hidden
If not, then not 🙂
I’ll play with it when I get home, don’t want to f with the boat right now.
👍
More later. But I’m happy, this sounds super promising, together with the settings, to lower the bar a bit
Me too
We are close
Type in a couple things, flip a switch and you have Signal K!
Exacrly
And hopefully soon I have a gift in return: Tailscale with a flip of a switch
Might save you some time in seeing whats wrong on a boat out there
The missing key…
Might solve the issue that WilhelmSK users can’t access their SignalK remotely?
Maybe
I don’t know whats at the bottom of that
I don’t have a way to get through vrm proxy from the app.
It is coming up more and more now…
You’re still in our Slack, right? I’ll put you in touch with the right person
Yes. I am.
Ok done
I’m thinking that we should keep this stuff consistent. node-red still requires the user to login. It’s just that an admin user is already setup. So not doing sso there.
There are issues with that sso approach, like handling things that use existing authentication methods, like WilhelmSK, sense esp devices, etc.
And, of course, things get more complicated the more I get into it.
1. If a user has already enabled security? I think is ok, we can add an “admin” user with the Venus os password if there isn’t already an admin account.
2. What to do if they then disable security in Venus OS? I don’t think we can turn off security in Signal K. They could have created other users, given access to SensESP devices, etc.
For node-red, we’ll probably make it sso
Hm.. 2 seconds later, not sure though… some integrators want the end user to not have access to node red flow editor, while do have access to normal UIs
(Node red is really heavily used, also for commercial projects)
Kinda similar issue with sk too. That’s why we still need to have user managenent in sk in this case. The need to be able to give out read-only logins.
I’m away from keyboard for awhile now
Tokensecurity already reads token from header. If we
- tweak that to honor a header by reverse proxy that gets set if the user has active venus session
- create a default admin user
do we really need more? All the rest of tokensecurity works as today; access requests, user management if the reverse proxy passes all requests, including ones without venus web session
As an end user i would really appreciate sso. Creating and managing users and passwords separately for each app with no default ”it just works” configuration is just too much mucking around for most normal humans
I think do need to be able to validate the Venus os password. That way they can use the same password for WilhelmSK, etc. (Already have that working, they do it the exact same way we do)
And if they go strait to SK without logging in via Venus OS.
That stuff is all pretty simple (Although I’m not sure how to do the nginx part, they use php for the session/auth stuff)
And we need to setup the security.json at some point to enable security.
And then what to do if they toggle off security in Venus OS later?
good points
I see two options here if they disable security in venos os after having enabled it and used sk.
1. Disable security in sk. If they had created any other users, etc. they will no longer work. They will work if security is turned back on.
2. Leave security on in sk. The admin user will retain the password previously used for Venus OS.
What do you think @mpvader ?
@Teppo Kurki do we have a way to make the server only bind to localhost?
no, but we should. or to expand a little: allow configuring what interfaces it should use
Check my PR when you get a chance. Have the header thing and logging in using the Venus OS password working.
I’ll look into specifying interfaces next…