problem starting turbovnc on fedora 40

[joa...@verona.se]

Hello,

I have a problem starting turbovnc on a fedora 40 machine.

some datapoints:
- I have another fc40 machine, where tvnc starts without problem
- I use systemctl start tvncserver to start the service
- if I fiddle a little bit with the init.d script, and remove the call
to /etc/rc.d/functions, tvnc does start, if I call the script directly
- If i dont remove the call to functions, fedora has aparently set this
up so the call is diverted to the systemd machinery, that somehow fails
in my case
- I tried setting export _SYSTEMCTL_SKIP_REDIRECT=1 but that didnt help
unless I also commented out functions call
- I tried sprinkling the tvncserver scripts with echos to a debug file,
but those seem never to be called, I guess systemd maybe caches the
original init.d script somewhere or something.
- I tried setenforce 0, but that didnt seem to help

hmm thats about it I guess. Any hints appreciated.
--
Joakim Verona
joa...@verona.se

[joa...@verona.se]

Hello,

I reinstalled the turbovnc rpm, and then it started working.

I dont know what the original problem was.

I received some replies in private, and thanks for those.

Regards
/Joakim

--
Joakim Verona
joa...@verona.se

[DRC]

Glad it is working.  The init.d scripts are basically legacy
functionality that I keep around because some people prefer that startup
method, but the recommended startup method these days is the TurboVNC
Session Manager. Upgrading the init.d scripts to support systemd is
something I want to do eventually, but it's a low priority. Also, I
would still have to keep the init.d scripts around for FreeBSD users.  I
would prefer not to have to maintain two different systems that both
cover an undocumented startup method that I don't even use myself.

As far as private messages, I would ask all participants in this forum
to keep all replies in the open. That's why replying to the list is the
default.  Nothing I do with VirtualGL, TurboVNC, or libjpeg-turbo is
proprietary.  The only way I can make the paltry amount of money I make
maintaining these projects is through funded development and patronage,
both of which hinge on providing features, information, and support in
the open that would normally only be available through a proprietary
product.

DRC

[joa...@verona.se]

"'DRC' via TurboVNC User Discussion/Support"

<turbovn...@googlegroups.com> writes:

> Glad it is working.  The init.d scripts are basically legacy
> functionality that I keep around because some people prefer that
> startup method, but the recommended startup method these days is the
> TurboVNC Session Manager. Upgrading the init.d scripts to support
> systemd is something I want to do eventually, but it's a low
> priority. Also, I would still have to keep the init.d scripts around
> for FreeBSD users.  I would prefer not to have to maintain two
> different systems that both cover an undocumented startup method that
> I don't even use myself.

Where can I read more information about how to configure the session
manager? I dont think I have the correct entry point for the session
manager documentation.

I did seem to understand that to use the session manager I will need to
use the internal ssh manager.

For some reason I cant really get that working, unclear why, I dont
think I have a weird ssh config. Is there some way to debug the internal
ssh client to see where it fails?

I use this atm:

secret-tool lookup turbovnc password|/opt/TurboVNC/bin/vncviewer -AutoPass -ExtSSH=1 -Tunnel=1 genos:1

I use ssh-agent to handle the ssh. I understand from the docs that
AutoPass is not recomended, but what do you think about this use-case
using secret-tool?

Regards
/Joakim

--
Joakim Verona
joa...@verona.se

[DRC]

On 9/3/24 8:27 AM, joa...@verona.se wrote:

Where can I read more information about how to configure the session
manager? I dont think I have the correct entry point for the session
manager documentation.

The User's Guide (https://turbovnc.org/Documentation/Documentation) describes basic Session Manager operation.  '/opt/TurboVNC/bin/vncviewer -?' has more in-depth documentation of the various parameters. You shouldn't really need to set any parameters for it, however.

I did seem to understand that to use the session manager I will need to
use the internal ssh manager.

For some reason I cant really get that working, unclear why, I dont
think I have a weird ssh config. Is there some way to debug the internal
ssh client to see where it fails?

Pass '-loglevel 110' to /opt/TurboVNC/bin/vncviewer.  There are a few limitations of the built-in SSH client at the moment, including lack of direct support for ed25519 keys.  (You can still use such keys via ssh-agent, but you can't pass them directly to the viewer.)  It also doesn't yet support jump hosts, but that's the highest priority feature for TurboVNC 3.2.  (I hope to have that feature ready to test in the 3.2 evolving branch later this month.)

I use this atm:

secret-tool lookup turbovnc password|/opt/TurboVNC/bin/vncviewer -AutoPass  -ExtSSH=1 -Tunnel=1 genos:1

I use ssh-agent to handle the ssh. I understand from the docs that
AutoPass is not recomended, but what do you think about this use-case
using secret-tool?

The Session Manager automatically generates and transmits a one-time password through the SSH connection, so there is no need to use a VNC password with it at all.  Once you authenticate with the SSH server, encryption and authentication with the TurboVNC session are handled automatically.  Thus, if authentication is automatic and password-less when you SSH into the host, then the same should be true when using the TurboVNC Session Manager.  When connecting to a session using the Session Manager, it effectively acts as if you had invoked:

ssh {host} /opt/TurboVNC/bin/vncpasswd -o -display {TurboVNC_session_display} 2>&1 | \
  sed 's/^.*: //g' | \
  /opt/TurboVNC/bin/vncviewer -autopass -tunnel -securitytypes vnc {host}:{TurboVNC_session_display}

You can, however, also set the SessMgrAuto parameter to 0 if you want to use the Session Manager solely for session management and configure encryption and authentication manually.

I looked into enabling the Session Manager for external SSH clients as well (see https://github.com/TurboVNC/turbovnc/issues/148), but there doesn't seem to be a robust way of keeping the SSH session open for an indefinite period of time (while the Session Manager dialog is open in the TurboVNC Viewer) without risking the SSH session remaining open if the viewer aborts unexpectedly.  Thus, I would either have to deal with OpenSSH control socket fragility, or I would have to stipulate that an SSH agent must be used when using the Session Manager with an external SSH client.  (In other words, an SSH session created with the external SSH client would not be persistent until the VNC connection is established.  Until then, the Session Manager would have to re-authenticate every time it needs to run a command on the host.)  Neither is ideal.

[joa...@verona.se]

"'DRC' via TurboVNC User Discussion/Support"
<turbovn...@googlegroups.com> writes:

> On 9/3/24 8:27 AM, joa...@verona.se wrote:
>
> Where can I read more information about how to configure the session
> manager? I dont think I have the correct entry point for the session
> manager documentation.
>
> The User's Guide (https://turbovnc.org/Documentation/Documentation) describes basic Session Manager operation.
> '/opt/TurboVNC/bin/vncviewer -?' has more in-depth documentation of the various parameters. You shouldn't really need to
> set any parameters for it, however.


>
> I did seem to understand that to use the session manager I will need to
> use the internal ssh manager.
>
> For some reason I cant really get that working, unclear why, I dont
> think I have a weird ssh config. Is there some way to debug the internal
> ssh client to see where it fails?

I did make the internal ssh work, by adding a rsa key. Previously I only
had a ed25519 key.

Now I can can ssh using the internal client, but then a 2nd dialog
appears saying "redundant encryption". Is this because I have a vnc
password?

I tried removin the .vnc/passwd file , but the server didnt star then,
so I put it back.



Thanks
/Joakim

--
Joakim Verona
joa...@verona.se

[DRC]

On 9/3/24 4:14 PM, joa...@verona.se wrote:

I did make the internal ssh work, by adding a rsa key. Previously I only
had a ed25519 key.

Now I can can ssh using the internal client, but then a 2nd dialog
appears saying "redundant encryption". Is this because I have a vnc
password?

I tried removin the .vnc/passwd file , but the server didnt star then,
so I put it back.

No, it's because TLSVnc is the default security type, and that security type implements TLS encryption.  But you're using SSH tunneling, which also implements encryption, so you're doubly encrypted.  (I guess I could look into changing the default security type to "VNC" when using SSH tunneling.)  The password dialog turns yellow to warn you of that fact, because redundant encryption can slow performance (and we still have "Turbo" in our name, so performance matters), but the warning won't prevent you from authenticating or connecting.

You can pass '-securitytypes vnc' to /opt/TurboVNC/bin/vncviewer to get rid of the warning (or set SecurityTypes=vnc in ~/.vnc/default.turbovnc), or you can use the TurboVNC Session Manager, which does that automatically by default.