CendioOssman
commented
6 years ago The extensions are now documented in the rfbproto project:
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst
Open kanaka opened 13 years ago
CendioOssman
commented
6 years ago The extensions are now documented in the rfbproto project:
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst
tybin
commented
1 year ago What is the current status of this? I see the issue opened, and a linked issue #70 reported working noVNC + ESXi setup, but experimenting on my own I couldn't figure this out.
I've tested both vCenter proxy and direct connection to ESXi (VMWare 6.7), both seem to expose non-RFB compliant endpoints, with different starting messages and messaging schemes. VMWare HTML Console SDK also requests an undocumented vmware-vvc subprotocol, and not negotiating it doesn't downgrade the connection to RFB. Am I missing a pure-RFB/VNC endpoint?
tybin
commented
1 year ago Acutally there is a pure RFB endpoint, docs say its on VMWare 6.0 and up:
Mouse-keyboard-screen over WebSocket ticket. MKS protocol is VNC (a.k.a. RFB) protocol with VMware extensions; the protocol gracefully degrades to standard VNC if extensions are not available. wss://{Ticket.host}/ticket/{Ticket.ticket}
I've just tested it and it seems to work fine, so I guess noVNC does support VMWare, just not the extensions. The ticket type and request path controls whether the host exposes custom VMWare traffic or regular RFB.
Lantizia
commented
3 months ago so I guess noVNC does support VMW
Have you tested this works, or just presumed it would based off what you've read?
I've got a whole bunch of ESXi hosts here (managed by a vCenter) on the latest ESXi 8.x... but since VMware dropped the ability to connect with regular VNC (ever since ESXi 7.x was released) it means WebMKS is the only choice.
However WebMKS seems to just be VNC tunneled via a WebSocket (much like websockify does), so first of all I thought I'd try it the way VMware documents it for developers...
The VMware way (scroll down for trying this with noVNC)
wmks.min.js (with a few supporting files) that VMware created as their equivalent to noVNC.
├── css
│ ├── extended-keypad.css
│ ├── main-ui.css
│ ├── trackpad.css
│ └── wmks-all.css
├── img
│ ├── touch_sprite_feedback.png
│ └── touch_sprite.png
├── test
│ ├── config
│ │ └── karma.conf.js
│ ├── Gruntfile.js
│ ├── package.json
│ ├── README.md
│ ├── spec
│ │ ├── basic.js
│ │ ├── core.js
│ │ └── mobile.js
│ └── view
│ └── index.html
└── wmks.min.jsindex.html file alongside the extracted wmks.min.js file, with the following contents (taken from this page in the VMware Docs)...
<!DOCTYPE html PUBLIC"-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Console</title>
</head>
<body>
<link rel="stylesheet" type="text/css" href="css/wmks-all.css" />
<script type="text/javascript" src="http://code.jquery.com/jquery-3.4.1.min.js"></script>
<script type="text/javascript" src="http://code.jquery.com/ui/1.12.0/jquery-ui.min.js"></script>
<script type="text/javascript" src="wmks.min.js"></script>
<div id="wmksContainer" style="position:absolute;width:100%;height:100%"></div>
<script>
var wmks = WMKS.createWMKS("wmksContainer",{})
.register(WMKS.CONST.Events.CONNECTION_STATE_CHANGE, function(event,data){
if(data.state == WMKS.CONST.ConnectionState.CONNECTED){
console.log("connection state change : connected");}
});
wmks.connect("wss://ESXi.host.IP.Address:443/ticket/webmksTicket");
</script>
</body>
</html>/mob as the path (e.g. https://vcenter.example.lan/mob) and logged in. You can also do this with the hostname of an ESXi but you'll need to follow this first, and the paths I mention below will be slightly different.wss://ESXi.host.IP.Address:443/ticket/webmksTicket.file:///home/user/Downloads/WebMKS_SDK_2.2.0/index.html), I could see and control the VM perfectly fine.The noVNC way
I tried this...
file:///home/user/Downloads/noVNC-1.5.0/vnc.html?autoconnect=1&host=an-esxi-host.example.lan&port=443&path=/ticket/5ba3d919a399a648937efb33747e47e8
And all I get is this...
So I'm wondering how reasonable it was to have expected this to just work?
It's VNC within a WebSocket sure! But I guess it all depends on if an ESXi host "websockifies" things, the same way that websockify does!?
tybin
commented
2 months ago @Lantizia it is way out of scope of this issue, but it is a common practice I found when working with hypervisors in general to issue one-time tickets after authenticating. You'll need some backend to request the ticket in a safe manner for sure. A stolen ticket is worth nothing to the attacker that wants to assume control over the environment, the VM access notwithstanding.
The noVNC client library works with VMWare 6/7, I haven't tested 8 as I don't have access to one. The only quirk is encoding artifacts shown as discolouring, but it is present even in VMWare GUI for console access, so I assume this has something to do with their implementation and not noVNC.
VMWare implements some extensions to the protocol that would be interesting to support in noVNC. I'm unlikely to personally get around to this (and don't have access to a ESX server) but somebody might be interested in doing this.
Some relevant links:
http://mail.gnome.org/archives/gtk-vnc-list/2008-January/msg00005.html http://wiki.multimedia.cx/index.php?title=VMware_Video http://bluebear.org/projects/kodiak/repository/revisions/master/entry/src/com/bluebear/rfb/vnc.h