When I run the TigerVNC client viewer from one of our VMs to my VNC server, I get prompted for the password. My connection DOES have the password in it (see attached screenshot, with the password hidden and the hostname blanked out for redaction), so that’s probably why. But that password in the Guac connection is the exact same password that is configured for the user at port 5902, and the one that I enter when the viewer prompts me.
It seems that, for some reason, Guacamole just isn’t sending the password. And based on the tcpdump that my network admin looked over, with the Guac connection attempt, the VNC server sends back a hex value to, I believe, encrypt the connection password and send back to the server, but Guac seems to just send back that same hex value. Thanks, Harry [Image] Harry Devine Secure-OSE System Administrator U.S. Department of Transportation FAA/AJM-2432 (609) 485-4218 (Office) (609) 612-7274 (FAA Cell) [email protected]<mailto:[email protected]> William J Hughes Technical Center Building 300 3rd Floor Column L20 Atlantic City NJ 08405 From: Nick Couchman <[email protected]> Sent: Saturday, May 23, 2026 4:58 PM To: Devine, Harry (FAA) <[email protected]> Cc: [email protected]; Vincent Sherwood <[email protected]> Subject: Re: Issue with VNC in 1.6.0 CAUTION: This email originated from outside of the Federal Aviation Administration (FAA). Do not click on links or open attachments unless you recognize the sender and know the content is safe. On Fri, May 22, 2026 at 10:56 AM Devine, Harry (FAA) <[email protected]<mailto:[email protected]>> wrote: So Red Hat asked me to capture a tcpdump of the connection attempt. I did 2 pcap files: 1 between Guac and the VNC server (connection fails), and 1 between the VNC client and VNC server (connection works). I had our network admin use Wireshark to examine both pcap files. Here’s what he found: Guac -> VNC: * the Guac server sends the connection request; * the VNC server sends back a challenge (hex value); * the Guac server sends back the same challenge (hex value) but no password is encrypted, and VNC server rejects it, resulting in “Authentication Failed” VNC client -> VNC server: * the VNC client sends the connection request; * the VNC server sends back a challenge (hex value); * the VNC client sends back a different response (hex value), indicating that the password entered by the user has been encrypted, and the VNC server accepts it and allows the connection. Based on these findings, I believe that Guacamole is not handling the password encryption via DES between itself and the VNC server. Would you like me to send you my pcap files? Thoughts? I'm still baffled by the fact that you're not being prompted for credentials when you try to connect. The results from above make perfect sense if no password is being sent, but, in the absence of credentials being provided as part of the connection, it should pop up and prompt you for the password, and I've no idea why that isn't happening. What happens if you provide the password as part of the connection parameters? Does it succeed or fail? And, if it fails, do you get the same results in the pcap (no password being sent back)? Also, I'm completely grasping at straws, here, but this message is interesting: May 20 13:59:56 guac-test server[14719]: 13:59:56.316 [http-nio-8080-exec-5] INFO o.a.g.t.h.RestrictedGuacamoleHTTPTunnelServlet - Using HTTP tunnel (not WebSocket). Performance may be sub-optimal. I don't think any of the credential prompting in Guacamole is tied to the use of Websockets vs. straight HTTP, but I'll have to see if I can disable Websockets in my environment and verify that. -Nick
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
