Missing option -noauth to vncserver of Version 2.0.91 about turbovnc HOT 2 CLOSED

Yes, this was a consequence of the addition of VeNCrypt. The -noauth, -novncauth, -nootp, and -nopam options were simply wrappers in the vncserver script. In TurboVNC 2.0.x, the default was to enable all of those authentication types by passing the corresponding arguments -rfbauth, -otpauth, -pamauth to Xvnc, and using one of the -no* arguments with vncserver removed the corresponding authentication argument from the Xvnc command line.

In TurboVNC 2.1, there's a new argument (-securitytypes) that controls which security types are enabled (a "security type" is a combination of an authentication type and an encryption type.) The default in Xvnc is effectively -securitytypes TLSVnc,TLSOtp,TLSPlain,X509Vnc,X509Otp,X509Plain,VNC,OTP, UnixLogin,Plain, but you can override this in order to disable some of the default security types or enable any of the "None" security types ("None", "TLSNone", or "X509None"), all of which require no authentication (NOTE: -securitytypes is passed through from vncserver to Xvnc, so refer to the Xvnc man page for a description of that parameter.)

The "equivalent" options are:

I put "equivalent" in quotes because there isn't really a literal equivalent of the old -no* options. I toyed with the idea of keeping the -no* options in vncserver and making them wrappers for -securitytypes, but this raised additional questions, such as whether those options should work literally the same as they did in TurboVNC 2.0.x (i.e. whether using them would imply disabling encryption.) Also, the problem with implementing backward-compatible -no* options in vncserver is that the -securitytypes argument can be used not just to override the default security types that are available but to override the default order as well. in TurboVNC 2.0.x, the preferred order of authentication types could be specified in the global security config file (/etc/turbovncserver-security.conf), and specifying -noauth or -novncauth, etc., didn't affect this order. There isn't any way to implement an equivalent behavior using the -securitytypes argument, so I felt it best to force the issue by removing the -no* arguments in vncserver and forcing people to switch to using -securitytypes, which is a more standard way of doing this sort of thing. I apologize for the confusion.

from turbovnc.

Thanks for your detailed explanation, although this information maybe should have been given in the release notes or elsewhere. Whatsoever, now people will be able to find it. The suggested approximation to -noauth worked perfectly.

Regards

from turbovnc.