After more 2 000 000 (two million) views on forum for 1.5.0.x development versions... and 1.6.1.0, 1.6.3.0-dev versions A new stable version, UltraVNC 1.6.4.0 and UltraVNC SC 1.6.4.0 have been released: https://forum.uvnc.com/viewtopic.php?t=38095 Feedback is always welcome
2025-12-03: Could you please complete our poll/survey? Renaming UltraVNC files and service to be more clear: https://forum.uvnc.com/viewtopic.php?t=38128 There was a problem to vote, it is solved now! Thanks in advance!
2025-12-02: We need help: English Wikipedia UltraVNC page has been requested to deletion: https://forum.uvnc.com/viewtopic.php?t=38127 Any help is welcome to improve the UltraVNC page and/or to comment on the Wikipedia Talk page
In reverse connection -- NO.
If the key is omitted at server end, the listening viewer will still accept the connection without notification (still working under encryption, but not using the original pre-shared key.
Reference [topic=27039]Possible Bug ?? SecureVNC -- Client Authentication Keys[/topic] for more detail.
Thanks YY,
I'm talking about direct, client-initiated connection.
In this scenario, how can I configure the server to refuse the connection if the client doesn't provide the pre-shared key (instead of generate a new one on the fly)?
Not necessary to config the server to reject such a connection
For a server using SecureVNC with xxxx_Server_ClientAuth.pubkey,
a viewer without the corresponding xxxx_Viewer_ClientAuth.pkey is not able to establish a connection with that server. After input the password, an error message will be returned.