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
On 9/11/23 5:15 AM, Kimmo wrote:
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
lauantai 9. syyskuuta 2023 klo 0.53.40 UTC+3 DRC kirjoitti:
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
On 9/5/23 2:34 AM, Kimmo wrote:
> 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
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/0d593278-19b4-435b-b304-14ec1bb04efcn%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/0d593278-19b4-435b-b304-14ec1bb04efcn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/c1f2998c-9153-588a-74d8-28384963e920%40virtualgl.org.
