Re: SSH failed: no matching host key type found

[Yang Yang]

Thank you very much for the clarification, Nick! I’m going to upgrade libssh2 
to the latest.

Thanks,
Yang

> On May 6, 2022, at 07:28, Nick Couchman  wrote:
> 
> On Thu, May 5, 2022 at 6:54 PM Michael Jumper  > wrote:
> On Sun, May 1, 2022 at 12:36 AM Yang Yang  wrote:
> Hi Nick,
> 
> I found that only ssh-rsa and ssh-dss are mentioned in ssh_agent.c 
> ,
>  does that mean other algorithms are currently not supported?
> 
> No, ssh_agent.c only deals with SSH agent forwarding support which is not in 
> play here. For authentication with an SSH server, any key format supported by 
> the libssh2 library present on the system can be used.
> 
> 
> Also, if you're using Ubuntu with libssh2 1.8.0, you probably don't have 
> support for some of the host key algorithms, According to their change log, 
> 1.9.0 introduced support for ECDSA and ED25519 key support, so you'll 
> probably need to bump up the version of libssh2. It's pretty easy to build 
> manually, so shouldn't be too difficult, or find a distribution that includes 
> it by default.
> 
> -Nick

Re: SSH failed: no matching host key type found

[Nick Couchman]

On Thu, May 5, 2022 at 6:54 PM Michael Jumper  wrote:

> On Sun, May 1, 2022 at 12:36 AM Yang Yang 
> wrote:
>
>> Hi Nick,
>>
>> I found that only ssh-rsa and ssh-dss are mentioned in ssh_agent.c
>> ,
>> does that mean other algorithms are currently not supported?
>>
>
> No, ssh_agent.c only deals with SSH agent forwarding support which is not
> in play here. For authentication with an SSH server, any key format
> supported by the libssh2 library present on the system can be used.
>
>
Also, if you're using Ubuntu with libssh2 1.8.0, you probably don't have
support for some of the host key algorithms, According to their change log,
1.9.0 introduced support for ECDSA and ED25519 key support, so you'll
probably need to bump up the version of libssh2. It's pretty easy to build
manually, so shouldn't be too difficult, or find a distribution that
includes it by default.

-Nick

Re: SSH failed: no matching host key type found

[Michael Jumper]

On Sun, May 1, 2022 at 12:36 AM Yang Yang  wrote:

> Hi Nick,
>
> I found that only ssh-rsa and ssh-dss are mentioned in ssh_agent.c
> ,
> does that mean other algorithms are currently not supported?
>

No, ssh_agent.c only deals with SSH agent forwarding support which is not
in play here. For authentication with an SSH server, any key format
supported by the libssh2 library present on the system can be used.

- Mike

Re: VNC uses weird Keyboard-Layout

[Michael Jumper]

On Mon, May 2, 2022 at 6:47 AM Matti Kaupenjohann <
matti.kaupenjoh...@fh-dortmund.de> wrote:

> Hi,
>
> before upgrading to 1.4.0 and after fixing the ip connection problem in
> 1.4.0 for our setup, I ran into an issue with a vnc connection. I
> initial hoped the upgrade may fix it but it doesn't.
>
> I have a VM installed headless via KVM and virttools on a ubuntu system.
> I setted the VM up with graphics using vnc and listen to 0.0.0.0. This
> setup made it possible to use tigervnc from any system which is inside
> our network. The usage of togervnc workes perfectly fine and also the
> german keyboard layout is beeing recognized with no issue. But if I
> setup a connection to this system in guacamole the keyboard layout
> begins with weird stuff. First I thought oh some vnc translation errors
> and the system uses now british/us qwerty. Instead some very weird
> layout is used. With [ALT GR] I am possible to achieve a lot of unicode
> chars, which normaly are not printed out over the letter keys. I also
> tested with the on screen keyboard which is still qwertz with the same
> result.


This is because KVM cannot implement keyboard in the same way that a normal
VNC server would:

VNC accepts key events in the form of keysyms, which are layout
independent. If you type "z", the VNC server handles it as "z" and
preserves the key's identity, even if the keyboard layouts of local and
remote systems do not match. Guacamole follows this same approach.

KVM, on the other hand, is required by its own nature to transform these
into hardware scancodes to emulate the keyboard connected to the VM. These
scancodes represent key location, not identity, so there will be unexpected
behavior if the OS inside the VM is actually configured to use a different
layout from what KVM expects.

For example, if the VM is configured within KVM to use a US Qwerty layout,
but the OS within the VM is configured to use Qwertz:

1. User types "z" while using Guacamole.
2. Guacamole sends "z" to the Guacamole server.
3. The Guacamole server sends "z" to the VNC server (KVM).
4. KVM translates that "z" to a scancode that's essentially equivalent to
"the second key in the fourth row".
5. The OS within the VM receives the scancode, but handles it as "y"
because that's the key at that location according to the OS' configured
layout.

- Mike

Re: Guacamole 1.4.0 problem using SAML authentication

[Michael Jumper]

On Sat, Apr 9, 2022 at 2:50 AM Vieri  wrote:

> ...
> >> The 1.4.0 release tightened SAML request validation.
> >>
> >> Rather than leverage your reverse proxy to rewrite the path from
> "/guacamole" to "/", I would recommend just reploying the webapp at the
> desired path to begin with, and
> >>reconfiguring your reverse proxy accordingly. The webapp can be deployed
> directly at "/" by renaming the .war file to "ROOT.war".
>
> So with that in mind, one cannot have more than one backend on the reverse
> proxy?
>

Sure you can. You just need to make sure that the webapp's .war file
matches the path that you've specified when you registered the webapp
with your SAML IdP. If the path that the webapp is served at by Tomcat
doesn't match the publicly-visible path, then SAML validation will fail.

- Mike

Re: RDP virtual printing (PDF) fails on second try

[Vieri]

FWIW I can confirm that the problem is fixed with the latest GIT version of 
guacamole-server.

Thanks,

Vieri

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org