SSH username in default values with 3.1 beta2

136 views
Skip to first unread message

Kimmo

unread,
Sep 5, 2023, 2:34:19 AM9/5/23
to TurboVNC User Discussion/Support
Setting default SSH username with

via={user}@{server}

doesn't seem to work with default settings (~/.vnc/default.turbovnc). The same syntax however works with .turbovnc-files. I don't know if this is by design or not. If I could ask for an option I would like to be able to convert Windows username to lowercase and use that as SSH username. Obviously there are more important features to implement before this.

Another minor SSH related issue: You have to put some dummy host into SSH settings before you check "Use VNC server as gateway" in the viewer options. If host is left empty and "Use VNC server as gateway" is checked the SSH username doesn't get used.

Great software with up-to-date features! Especially now with the keyboard mapping!

Best Regards
Kimmo

DRC

unread,
Sep 8, 2023, 5:53:40 PM9/8/23
to turbovn...@googlegroups.com
Oof.  Yeah, the handling of SSH usernames is a bit messed up.  The SSH
username has traditionally been treated as a meta-parameter of sorts. 
It is taken from the Via parameter if it is specified in that parameter
(or its GUI equivalent in the "TurboVNC Viewer Options" dialog), or it
is taken from the Server parameter if it is specified in that parameter
(or its GUI equivalent in the "New TurboVNC Connection" dialog), or it
defaults to the local username if it is unspecified. The SSH username
meta-parameter is stored in a string inside the Params instance, and the
string is set when the Via or Server parameter is set or when the "SSH
user" field is set and "OK" is clicked in the Options dialog.  In prior
versions of TurboVNC, this had the following ramifications, which were
arguably confusing:

- If "Use VNC server as gateway" was checked in the Options dialog, the
"SSH user" field was ignored if the SSH username was specified in the
Server parameter (and/or the "VNC server" field in the Connection dialog.)

- The value of the "SSH user" field was not saved and restored between
invocations of the Options dialog unless the gateway host was also
specified.  This is because, if the gateway host is unspecified, the SSH
username becomes associated with the Server parameter, and the Server
parameter is ephemeral (i.e. it has no default value and is not saved
and restored, although it can be specified in a .turbovnc file or
default.turbovnc.)

IMHO, this behavior is broken, because it violates the implicit contract
whereby everything in the Options dialog is saved (and will be restored
not only on the next invocation of the dialog but also on the next
invocation of the TurboVNC Viewer) when "OK" is clicked.  The
introduction of per-host options in TurboVNC 3.1 further broke the
already broken behavior.  It isn't clear in which cases resetting other
parameters with Options dialog equivalents (Via in particular) should
also reset the SSH username, and apparently the SSH username is being
reset in some cases in which it shouldn't be.

The only clean solution I can think of is to stop treating the SSH
username as a meta-parameter and leave it attached to the parameter in
which it is specified (Via or Server.)  That would have the following
ramifications:

- When using the Tunnel parameter (or checking "Use VNC server as
gateway"), the SSH username would need to be specified in the Server
parameter or the "VNC server" field.  The text in the Connection dialog
and the documentation of the Server parameter would be modified to
clearly indicate this.

- The Options dialog would have a single "Gateway" field that acts just
like the "VNC server" field in the Connection dialog, i.e. the SSH
username would be specified by prefixing user@ to the hostname. 
Checking "Use VNC server as gateway" would disable that field.  New text
in the Options dialog would direct users as to the correct usage of the
"Gateway" field.

That would be a slight feature regression against 3.0.x, but again, the
behavior of 3.0.x and prior was somewhat confusing.

The proposal above would fix both of the issues you report.

The feature you request would be dead simple to implement, just a
one-line modification that makes the LocalUsernameLC parameter affect
the SSH username as well as the User parameter.

DRC

Kimmo

unread,
Sep 11, 2023, 5:15:48 AM9/11/23
to TurboVNC User Discussion/Support
Thanks for your comprehensive answer. Your proposal sounds good to me. If the proposed feature would be a one-line modification, I would use it immediately. 

Thank you so much for great software and dedication for developing it.

-Kimmo

DRC

unread,
Sep 13, 2023, 6:09:45 PM9/13/23
to turbovn...@googlegroups.com

All should be working now, and pre-release builds should be available shortly.  Ultimately I was able to fix the issues more straightforwardly by introducing a new formal parameter (SSHUser) that takes the place of the aforementioned meta-parameter.  Also, LocalUsernameLC now affects the SSH username when it defaults to the local username.

DRC

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/0d593278-19b4-435b-b304-14ec1bb04efcn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages