Multiple Established Connections

[Andrew]

Hello. I am using TurboVNC 2.1.90 in a RHEL 7.7 environment. When I have user/password authentication enabled to access the Xvnc session and leave the login prompt open without entering any credentials, an lsof command shows an established connection to the VNC port on the remote system. If I then open a viewer on a different system and Authenticate into the same Xvnc session lsof now shows two established connections. I have -NeverShared set on the Xvnc session. These two connections (one “real”, one not) are throwing off some custom software. Is there a recommended way to either prevent more than one connection or distinguish between multiple? Looking through docs for newer versions I do see that 2.2.2 added a “-maxconnections” parameter. Would that solve the issue? I ask here because In my environment I am unable to change versions at will. Thank you for any input and also for a great product.

[DRC]

TurboVNC 2.1.90 is 2.2 beta1.  Beta versions are instantly obsolete as
soon as the corresponding final version (2.2, in this case) is released,
and stable versions are instantly obsolete as soon as the next stable
version in the same series is released.  Please upgrade to the latest
stable 2.2.x version (2.2.5.)  That's what stable branches are for.

As far as the open connections, all VNC implementations behave that way,
and it's a feature rather than a bug.  If a VNC server, when started
with -nevershared (or the equivalent), automatically rejected new
connections without authentication, then a malicious client might be
able to overwhelm the server by repeatedly attempting to connect
(assuming an existing connection was already successfully established.) 
Also, if the server was started with -disconnect (or the equivalent),
then for obvious reasons, it is necessary to authenticate the new
connection before automatically closing the old connection.

'-maxconnections' operates at the socket level rather than the RFB
protocol level, so '-maxconnections 1' should achieve what you want. 
However, note that it will introduce the same potential for attack
described above (which is why the default value of -maxconnections is
quite high.)

[Andrew]

Thank you for the reply. I am in progress of updating to 2.2.5. I do have One follow-up question about the connections: if a user on the client machine brings up the login prompt but does not enter any credentials, does TurboVNC support a way to drop the connection after a period of time? I looked through the man page for Xvnc and tried a couple of options like “-rfbwait” but it didn’t seem to do what I wanted. I am able to achieve this behavior with custom bash scripts, but if Turbo supports this natively that would be ideal. There was a similar question asked a year or so ago, but there did not seem to be a resolution reached at that time. Thank you again for your time.

[DRC]

The server doesn't support that at the moment, and I see why that's
potentially a problem with '-maxconnections 1' (because, since
-maxconnections is implemented at the socket level, the TCP connection
that is held open while the authentication dialog is open counts toward
the connection limit.) -rfbwait just specifies the maximum amount of
time that the server should wait for a network read or write to
complete. The problem is that, when the viewer's authentication dialog
is open, the server isn't waiting for a read or write to complete. It's
just sitting idle until the viewer sends it the expected authentication
credentials, and the RFB protocol doesn't require that those credentials
be sent in a timely manner.

TigerVNC has a parameter called "IdleTimeout" that drops a connection
after a specified period of inactivity. That effectively prevents an
open VNC viewer authentication dialog from holding open a TCP connection
to the server indefinitely, but the problem with IdleTimeout is that it
doesn't just apply to authentication. If, for instance, you specify
IdleTimeout=60, the VNC connection will be dropped if the user steps out
of the office for a minute. That's not generally desirable behavior. I
think the correct solution would be to implement an authentication
timeout-- to specify that, after the server enters the authentication
state for a particular connection, authentication must complete within a
specified period of time or the connection will be dropped. I'm happy
to implement that feature as a funded development project. Contact me
offline for an estimate if you are interested in pursuing that.

[Andrew]

Great! thank you for your reply and the information