On Thu, Mar 29, 2018 at 3:19 AM, Mike Jumper <mike.jum...@guac-dev.org>
wrote:

> On Sun, Mar 25, 2018 at 1:26 PM, Nick Couchman <nick.e.couch...@gmail.com>
> wrote:
>
> > I was looking at some possible ways to implement changes needed for
> > GUACAMOLE-527, dealing with SSH known hosts, and one of the possible
> routes
> > would be to add a parameter to the guacd configuration file to specify
> the
> > path to a known_hosts file that could then be pulled in for the SSH
> > protocol.  The issue I'm running into is that it seems like the parsing
> and
> > availability of configuration items in the guacd configuration file only
> > exists in the src/guacd code and isn't necessarily (easily) available to
> > each of the protocols.  Am I missing something here, or would other work
> > need to be done to allow for configuration parameters in the guacd config
> > file to be used by the protocol-specific code?
> >
> >
> There's no central configuration API for protocols like there is for
> extensions to the webapp, but regardless, I'm not sure this would be the
> best approach. Pulling connection-specific values from a configuration file
> on the server running guacd doesn't jibe well with the careful separation
> of concerns between the webapp (which needs to be aware of the nature of
> the connections) and guacd (which blindly serves the whims of the webapp).
> I could also see this potentially backfiring for larger deployments with a
> cluster of guacd nodes behind a balancer.
>
>
Okay, good to know.  I wasn't sure that the SSH server fingerprints really
fell into the "connection-specific value" category, though - in general,
you're trying to make sure that the guacd host trusts the SSH clients.  I
think we have similar behavior with guacd + RDP + TLS or guacd + VNC + TLS,
where the trust of the TLS certificate is based on the certificates
installed on the machine where guacd is running, correct?  It seems like
adding support for a "known_hosts" file, either (by default) in the home
directory or in a location specified by the admin in the guacd config file
is a natural extension of this.


> What about passing the key fingerprint as a connection parameter?
>
>
This is definitely an option, and I was looking at both doing this and the
known_hosts route, above.  The only issue that I've run into, here, is
that, depending on the type of host, there are three possible types of
known host fingerprints (RSA1, RSA, and DSA), and I haven't yet found a
good way to automatically detect the type based on the fingerprint (libssh2
doesn't seem to support this), which means this turns into two connection
parameters - one for specifying the host key type, and one for specifying
the fingerprint.  Still doable, and we can have the type value default to
RSA, which is the most common, but it'd be nice to find some way to
automate the detection.

A final method would be to have the connection provide a configuration
value for the location of a known_hosts file, which is kind of a merge of
the two ideas - it's still be provided by the connection, just specified as
a location on the system running guacd - in my mind, similar to know things
like session recording and RDP drive redirection work.

-Nick

Reply via email to