dcommander
commented
5 years ago What exactly are you trying to achieve? If the SSH server and TurboVNC server are the same machine (visu01), then you should be able to do:
Closed GloktarFR closed 5 years ago
dcommander
commented
5 years ago What exactly are you trying to achieve? If the SSH server and TurboVNC server are the same machine (visu01), then you should be able to do:
GloktarFR
commented
5 years ago SSH server and TurboVNC are not the same machine. I’m trying to tunnel the connection through a gateway server, which in my example is « mylogin ». That’s why I also need the « via » option. In fact, visu01 is not exposed to the network. So I really need to tunnel the connection through the login gateway in order to reach it.
dcommander
commented
5 years ago That doesn't make sense, though. If visu01 is not exposed to the network, then how are you accessing the TurboVNC web server that is running on it? Your URL clearly says "http://visu01:5801".
GloktarFR
commented
5 years ago Yeah you’re right. Only 58xx port are exposed, but not 59xx. The purpose of this method would be to give the user the download url for the jar and jnpl, but then to launch the connection through the login gateway as SSI rules do not allow us to expose VNC ports...
dcommander
commented
5 years ago I think that there is an equal, if not greater, danger in exposing Port 580x, since the built-in web server in the TurboVNC Server may or may not be particularly robust against attacks, and the web server and RFB server both run within the same process. I would instead recommend running a real web server, like Apache, on the gateway machine and serving up the TurboVNC Viewer JARs through that web server. If that approach isn't suitable for some reason, then I'd like to hear your feedback, because the built-in web server in TurboVNC may go away in TurboVNC 3.0 (a reflection of the fact that Java Web Start is now, unfortunately, an obsolete technology.) So if there's a compelling use case for the built-in web server that can't be satisfied in some other way, I want to hear about it.
Now, as to the problem at hand, it was due to an oversight in the built-in HTTP server whereby it ignored parameters with a colon or @ symbol. Fix pushed.
GloktarFR
commented
5 years ago I’ve heard about people using the tornado python framework as a way of automatically start the VNC session (meaning that users connect to a web server and it launches the ssh tunnel and a web VNC client). But I don’t think they use the TurboVNC client...
If I understand correctly, a more secure way would be to setup a proper Apache which serve the same purpose: send the jar (at least until v3.0), and the custom jnpl file. I will have a deeper look into this. But if the java web start goes away in future release, maybe we won’t be able to ask TVNC client to tunnel the connection through a SSH anymore ? Or maybe we will need to use a different technology to relay the traffic like a proxy.
Thank you for the fix.
dcommander
commented
5 years ago We will continue to support Java Web Start with dedicated web servers such as Apache. It is only the embedded web server in Xvnc that may go away in TurboVNC 3.0. It's because that embedded web server is old code. In order to keep it, I would need to update it using libhttpd or something like that-- a modern web server framework that supports HTTPS, is more robust, and (preferably) allows the web server to run in a different thread than the main TurboVNC Server thread. Most TurboVNC shops that are using JWS do so with a dedicated web portal, so they don't need the embedded web server in Xvnc (most of them even disable it system-wide using the directive in /etc/turbovncserver-security.conf). That's why I'm asking for feedback from users who do need the embedded web server feature. If there's a compelling use case for it that can't be satisfied with a dedicated web server such as Apache, then I will put in the effort to upgrade the embedded web server and keep it in 3.0. However, given that public updates for Java SE 8 will end next year, effectively that will be the end of JWS unless someone wants to go to the trouble of installing IcedTea-Web (ITW) or paying for extended support on Java SE 8. My take on the situation is that:
Those are all my assertions, but someone correct me if I'm wrong.
There isn't anything JWS-specific about the Java TurboVNC Viewer. JWS is just using the features that the viewer already provides. SSH tunneling is certainly not going away, because the TurboVNC Session Manager relies upon it.
GloktarFR
commented
5 years ago From my point of view (I work in HPC environments), I found out that for some companies, it is not always easy to deploy the TVNC viewer across all end user stations. In fact, very often, HPC clusters are not fully integrated in the enterprise environment. Some administrators have told me over time when TVNC needed an upgraded, that it could take more than two weeks to upgrade all stations, and that we have to find a way to be able to use the old version of the viewer with the new version of the server...
Another thing is the way VNC servers are exposed to the enterprise network. Sometime security rules allow us to expose 59xx ports to the network, sometimes it requires to go through an SSH gateway. Unfortunately some users are not familiar with Linux CLI and it's a challenge for them to open a SSH tunnel, etc.
All that being said, we found out that the best way to facilitate the launch of TVNC sessions for most of our customers, is to use a web browser. That's where JWS and the embedded web server entered the game. For example, the user connects to the login node of the cluster and select a "desktop" session. In the background, we launch a TVNC server instance and prompt a message to the user which points to the url to connect to. Then the user opens its browser, enters the url and he is ready to work.
dcommander
commented
5 years ago Thanks for the great feedback. Comments and questions inline.
From my point of view (I work in HPC environments), I found out that for some companies, it is not always easy to deploy the TVNC viewer across all end user stations. In fact, very often, HPC clusters are not fully integrated in the enterprise environment. Some administrators have told me over time when TVNC needed an upgraded, that it could take more than two weeks to upgrade all stations, and that we have to find a way to be able to use the old version of the viewer with the new version of the server...
Another thing is the way VNC servers are exposed to the enterprise network. Sometime security rules allow us to expose 59xx ports to the network, sometimes it requires to go through an SSH gateway. Unfortunately some users are not familiar with Linux CLI and it's a challenge for them to open a SSH tunnel, etc.
This problem should already be addressed by the Java TurboVNC Viewer (which is the only TurboVNC Viewer on Mac and Linux), since it has an embedded SSH client that can be configured from the GUI. If you have SSH access to a TurboVNC host but no access to the RFB ports, then all you have to do is check "Use VNC server as gateway" under the Security tab in the TurboVNC Viewer Options dialog and enter your SSH user name in the same dialog. That feature has been in the TurboVNC Viewer for quite some time, so even relatively old versions of the viewer should still have it.
All that being said, we found out that the best way to facilitate the launch of TVNC sessions for most of our customers, is to use a web browser. That's where JWS and the embedded web server entered the game. For example, the user connects to the login node of the cluster and select a "desktop" session. In the background, we launch a TVNC server instance and prompt a message to the user which points to the url to connect to. Then the user opens its browser, enters the url and he is ready to work.
The way many TurboVNC web portals handle this is to generate the .jnlp file using the portal code and download it to the user's browser. Some portals also generate a .vnc connection file instead and download it to the browser, but that requires that the TurboVNC Viewer already be installed on the client machine.
If I understand correctly, the main arguments in favor of keeping the embedded web server, from the point of view of your computing environment, are:
I would again caution, however, that if there are security concerns about the 590x ports, those security concerns should probably also apply to the 580x ports.
Questions:
dcommander
commented
5 years ago You might also want to check out the TurboVNC Session Manager, which is currently available for testing in the 3.0 alpha pre-release builds: https://turbovnc.org/DeveloperInfo/PreReleases Assuming that the 3.0 alpha build is installed on both server and client, this feature allows you to just enter the TurboVNC host name (without a display or port number), and it will automatically connect with SSH and either start a new TurboVNC Server session or list the current sessions on that host under your user account, allowing you to choose one to which to connect, to kill any of your running sessions, or to start a new session. The SSH client in 3.0 has also been upgraded to support password-less logins using ssh-agent (Mac, Linux) or Pageant (Windows.)
GloktarFR
commented
5 years ago Regarding web portals, we have tested some like: Nice EnginFrame, IBM/LFS Application Center. Indeed, they provide a .vnc file to be used with the TVNC viewer installed on the user's station. But then we have the problem of having the viewer installed on all stations which can be somehow difficult for some companies. These portals are also not free, and not all customers are willing to pay, that's where the embedded web server in TVNC appears to be a better replacement solution for launching graphic sessions. Besides, I'm not sure they provides lots of options such as the requirement of passing through a SSH gateway (or at least we may need to modify the .vnc that is generated by the portal to include proper options, never tested that though). Last thing, these portals are not so easy to modify when you find out unsupported functionalities. They rarely implements all great features that you can find in TVNC (like all authentication methods). They usually choose a method and stick to it until some customers ask for more features.
I'm not aware of other "free" portals compatibles with TVNC that would do similar things, nor I'm aware of portals giving .jnpl files. If you have some references, could you please share it with us ?
JWS is currently well integrated in companies, and it is often easier to use the JWS TVNC plugin than the viewer. That may not be true for Universities though, but it is definitively the case for private companies which often relies on Windows workstations. In my opinion, the modern way of addressing this problem may be to use html5 (of course I'm not a developper so I don't know the technical issues you may face). But I'm aware of a product from Fujitsu which is a completed web desktop which includes a VNC plugin. The core mechanism of this portal is based on web sockets and html5, they uses x11VNC though, but I don't see any reason why TVNC could not fit into this as well.
A typical HPC cluster environment hides all the nodes behind login nodes (sometime called gateway or frontend nodes). It is sometime possible to expose 59xx ports or at least SSH port of "VNC servers" nodes, but sometimes it is not an option for security reasons. This is because the login nodes have firewalls, selinux enabled, specific package update policies, and so on. In such case, the only solution is to use login nodes as SSH gateways to reach the TVNC servers hidden behind. My main concern is how it is possible to facilitate the way users will launch their sessions, taking into account the complexity of the underlying network architecture. Based on that, I suppose the embedded web server as it is right now is not an option as it is not secure. And as you advised, ports 58xx shouldn't be exposed at all. So maybe the best solution right now would be to develop a simple Apache server which can provide .jnpl files and handle the underlying network complexity.
Regarding your other questions:
I don't think lots of companies will agree to pay for Java next year. That's a big deal. In the HPC domain, companies are willing to pay for business softwares (for which licenses are very expensive), but not so much for the middleware.
It could be really great to have the possibility to auto-generate a .jnpl file. I assume it would be easier for us to create our own "simple" https server which takes into account the underlying network complexity.
I'm not sure if that answer all your questions. Feel free to insist if this is not the case.
GloktarFR
commented
5 years ago You might also want to check out the TurboVNC Session Manager, which is currently available for testing in the 3.0 alpha pre-release builds: https://turbovnc.org/DeveloperInfo/PreReleases Assuming that the 3.0 alpha build is installed on both server and client, this feature allows you to just enter the TurboVNC host name (without a display or port number), and it will automatically connect with SSH and either start a new TurboVNC Server session or list the current sessions on that host under your user account, allowing you to choose one to which to connect, to kill any of your running sessions, or to start a new session. The SSH client in 3.0 has also been upgraded to support password-less logins using ssh-agent (Mac, Linux) or Pageant (Windows.)
Thank you for the tip. I'll try it out asap.
dcommander
commented
5 years ago Regarding web portals, we have tested some like: Nice EnginFrame, IBM/LFS Application Center. Indeed, they provide a .vnc file to be used with the TVNC viewer installed on the user's station. But then we have the problem of having the viewer installed on all stations which can be somehow difficult for some companies. These portals are also not free, and not all customers are willing to pay, that's where the embedded web server in TVNC appears to be a better replacement solution for launching graphic sessions. Besides, I'm not sure they provides lots of options such as the requirement of passing through a SSH gateway (or at least we may need to modify the .vnc that is generated by the portal to include proper options, never tested that though). Last thing, these portals are not so easy to modify when you find out unsupported functionalities. They rarely implements all great features that you can find in TVNC (like all authentication methods). They usually choose a method and stick to it until some customers ask for more features.
But don't you already have your own web portal for starting the TurboVNC sessions? My idea was for you to extend your existing portal to serve up JNLP files. Then you could do everything with SSH tunneling and not have to bother with the 580x ports. But if you don't have a portal already, then I totally understand why the embedded web server would be a more straightforward solution. And, to be clear, I don't know of any security issues in the embedded web server. Maybe there are none. I just don't think it makes sense to trust the embedded web server if you don't trust the RFB server. The danger is that the embedded web server is served up from within the Xvnc process, and hypothetically, the right security hole in that embedded web server might open up an exploit whereby a hacker could obtain information from the Xvnc heap (which might include the information necessary to successfully authenticate with the TurboVNC Server session.)
There is no way currently to set up SSH tunneling using a .vnc connection file. I would have to extend the .vnc file format to accommodate that, although it would be a straightforward modification.
(Aside: The reason I have never done that is that TurboVNC portals that serve up .vnc files typically do so to the Windows native TurboVNC Viewer, which doesn't support encryption and which requires additional software in order to support SSH tunneling. That is, incidentally, a big reason why the Windows native TurboVNC Viewer is going to be replaced by the Windows/Java TurboVNC Viewer in TurboVNC 3.0. The Windows native TurboVNC Viewer is written using raw Win32 API code, so it's very difficult to maintain and extend the GUI in that viewer. It would have taken more time for me to port the TurboVNC Session Manager to that viewer than to improve the Java viewer so that it has all of the features of the native viewer. jlink made it possible for me to embed a custom JRE into the Java TurboVNC Viewer, so I chose that approach rather than continuing to maintain two viewers.)
I'm not aware of other "free" portals compatibles with TVNC that would do similar things, nor I'm aware of portals giving .jnpl files. If you have some references, could you please share it with us ?
The portals I was referring to are all in-house solutions, unfortunately. I mentioned them in the context of best practices. At one time, the plan for TurboVNC was to release our own web portal, and one of my customers had even agreed to let me open source their portal code (which is a .vnc-based portal, not a JNLP-based portal.) However, with Oracle's abandonment of JWS, I ultimately decided that the TurboVNC Session Manager was a better approach for three reasons:
My thinking was basically that, if the web portal is just doing simple session management, then we can do that with the TurboVNC Viewer and cut out the middle man.
JWS is currently well integrated in companies, and it is often easier to use the JWS TVNC plugin than the viewer. That may not be true for Universities though, but it is definitively the case for private companies which often relies on Windows workstations. In my opinion, the modern way of addressing this problem may be to use html5 (of course I'm not a developper so I don't know the technical issues you may face). But I'm aware of a product from Fujitsu which is a completed web desktop which includes a VNC plugin. The core mechanism of this portal is based on web sockets and html5, they uses x11VNC though, but I don't see any reason why TVNC could not fit into this as well.
HTML 5 doesn't currently provide the necessary performance or features to duplicate the functionality of the TurboVNC Viewer, and even if it did, it would take many hundreds of hours to develop an HTML 5/Javascript version of the TurboVNC Viewer (even if I based it on an existing code base like noVNC.) TurboVNC 3.0 will more tightly integrate with noVNC, by allowing users to start a noVNC proxy for their TurboVNC session. This is all handled by extensions to the vncserver script. However, this isn't meant for day-to-day remote desktop usage. It's mainly meant to enable TurboVNC users to temporarily share their session with a colleague who doesn't have the TurboVNC Viewer installed, and to provide access (with reduced features/performance) to a TurboVNC session from mobile devices.
Even if I had funding for an HTML 5/Javascript TurboVNC Viewer, it would take 100% of my labor for 6-12 months to bring it to market, and that would take me away from the important work of maintaining and improving the existing product. The other issue is that, with HTML 5/Javascript, you have to treat each different web browser as if it were a different platform, because they all behave differently in subtle ways. I spent some time playing with the noVNC code base a couple of years ago, and it just isn't easy to work with at all-- mainly due to the technical constraints of HTML 5/Javascript. In the long term, WebAssembly (WASM) is a more likely candidate for a browser-based TurboVNC Viewer, but there are a lot of current issues with that as well. I've also spent some time trying to bring up a simple proof of concept for a WASM TurboVNC Viewer, but I could never make the sockets layer work properly. Also, in order to port libjpeg-turbo to WASM, WASM first needs to support SIMD instructions, and I would need to write a new SIMD extension for libjpeg-turbo in order to accommodate those.
A typical HPC cluster environment hides all the nodes behind login nodes (sometime called gateway or frontend nodes). It is sometime possible to expose 59xx ports or at least SSH port of "VNC servers" nodes, but sometimes it is not an option for security reasons. This is because the login nodes have firewalls, selinux enabled, specific package update policies, and so on. In such case, the only solution is to use login nodes as SSH gateways to reach the TVNC servers hidden behind. My main concern is how it is possible to facilitate the way users will launch their sessions, taking into account the complexity of the underlying network architecture. Based on that, I suppose the embedded web server as it is right now is not an option as it is not secure. And as you advised, ports 58xx shouldn't be exposed at all. So maybe the best solution right now would be to develop a simple Apache server which can provide .jnpl files and handle the underlying network complexity.
I would be happy to rewrite the embedded HTTP server using libhttpd or some other solution that would address the security concerns, but upon further reflection, I think this really needs to be implemented as a separate process-- external to Xvnc-- in order for it to be secure. It would be straightforward to do so, but funding is really tight on this project right now, so I wouldn't be able to make that happen in the existing stable branch (2.2.x) of the code unless someone paid for my labor.
Regarding your other questions:
- I don't think lots of companies will agree to pay for Java next year. That's a big deal. In the HPC domain, companies are willing to pay for business softwares (for which licenses are very expensive), but not so much for the middleware.
I concur, which is why I didn't think it was worthwhile to put any further effort into the embedded web server. If your company isn't going to pay for extended support on Java SE 8, then your ability to use JWS will go away next year, and even if I rewrote the embedded web server, that rewrite would effectively only have a lifespan of 1 year.
- It could be really great to have the possibility to auto-generate a .jnpl file. I assume it would be easier for us to create our own "simple" https server which takes into account the underlying network complexity.
Upon further reflection, this is already easy to accomplish using sed, since all you need to do is replace the $SERVER, $HTTPPORT, $DISPLAY, and $PARAMS variables in /opt/TurboVNC/java/VncViewer.jnlp.in. So maybe the best solution is more of a script-based approach, i.e. a script that creates a temporary directory, generates a customized version of VncViewer.jnlp in that directory, copies the JAR files to that directory, then starts a web server process (perhaps using the Python SimpleHTTPServer framework or something like that) on Port 580x to serve up the files. If the script was written in Python and it directly invoked SimpleHTTPServer, then it might be possible to support converting URL parameters to TurboVNC Viewer parameters as well, thus duplicating the functionality of the existing embedded web server. But I'm not well-versed in Python, unfortunately.
Hi,
I'm trying to use the options "via" and "server" with the JWS viewer. I would like to use something like that:
It looks like these options are not properly set in the jnpl file. If I add it manually though, it works like a charm, for instance :
<argument>visu01:1</argument><argument>via=myuser@mylogin</argument><argument>server=visu01:1</argument>Maybe I'm not using the right options in the url ? Any advice would be appreciate :-)
Thx.