You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For my application I handle authentication at the server where websockify runs, not on the VNC server itself.
The VNC server runs on a hidden non-public network.
Websockify is spawned in response to user connection requests and ideally I would like to add randomly generated password that noVNC would pass to authenticate that it is the intended client.
Failing that, a simpler approach would be to have a cmdline option to pass websockify the client's IP address to expect connections from.
I already use the run-once and connection timeout options but if someone was hammering my server they might be able to hijack a session before the client can connect. VNC's builtin password system is weak security IMO. My authentication system needs to be multi-user which is handled just fine upstream of websockify except for the small window of time between when it is spawned and noVNC connects to it.
Does this sound workable?
I'd assume the patch for checking the IP address is simple, but I'm curious if this would be broadly usable by others.
The text was updated successfully, but these errors were encountered:
@mightypenguin, yep, that's a good idea. We used a similar mechanism with IP restriction at my former employer, part of the external system that launched websockify also installed a temporary iptables rules for that specific source IP.
See this pull request: #16 for a generic external authentication mechanism and my comments on it (the original pull author never got back to implementing my suggestions unfortunately).
Basically it would like like this: websockify would take an option for an external validation script which would be called for every new client connection. That script would be invoked with environment variables that contain all the connection header information. The script would then return 0 if the connection is allowed, or something else (perhaps mapping codes to websocket close codes) if the connection is denied. This would keep the basic websockify uncluttered with various authentication mechanisms (which will likely vary significantly based on what framework websockify is being integrated into) and give it a generic mechanism for authenticating connections. For example, one of the most basic authentication scripts (which should be included as an example) should be one which verifies the origin/host information (CORS) rather than the current everything is allowed situation.
For my application I handle authentication at the server where websockify runs, not on the VNC server itself.
The VNC server runs on a hidden non-public network.
Websockify is spawned in response to user connection requests and ideally I would like to add randomly generated password that noVNC would pass to authenticate that it is the intended client.
Failing that, a simpler approach would be to have a cmdline option to pass websockify the client's IP address to expect connections from.
I already use the run-once and connection timeout options but if someone was hammering my server they might be able to hijack a session before the client can connect. VNC's builtin password system is weak security IMO. My authentication system needs to be multi-user which is handled just fine upstream of websockify except for the small window of time between when it is spawned and noVNC connects to it.
Does this sound workable?
I'd assume the patch for checking the IP address is simple, but I'm curious if this would be broadly usable by others.
The text was updated successfully, but these errors were encountered: