Re: guacamole cannot use yum-version of mariadb-java-client under RockyLinux9 (but 8 is fine)
Wow - fast answer there Mike - thanks! We'll keep a copy of the RockyLinux8 version around then On Mon, Jan 16, 2023 at 10:17 AM Michael Jumper wrote: > On Sun, Jan 15, 2023, 1:04 PM Jason Haar wrote: > >> ... >> Error querying database. Cause: java.sql.SQLException: No suitable >> driver found for jdbc:mysql://127.0.0.1:3306/guacamole >> ... >> After messing around for some time I thought to try >> replacing mariadb-java-client.jar file with the RockyLinux8 version and >> that fixed the problem. Rocky8 has mariadb-java-client-2.7.1-2.el8 and >> Rocky9 has mariadb-java-client-3.0.3-1.el9 >> > > This is because MariaDB Connector/J 3.x has dropped support for the > "jdbc:mysql:" URI format, now requiring that code using the driver either > use "jdbc:mariadb:" or explicitly specify a "permitMysqlScheme" attribute: > > > https://mariadb.com/kb/en/about-mariadb-connector-j/#jdbcmysql-scheme-compatibility > > The "JDBCHelper" class from MyBatis Guice that we've been using uses > "jdbc:mysql:" for both the MySQL and MariaDB versions of the driver, hence > the failure. Code changes on either our side or within MyBatis would be > needed to be compatible with 3.x. > > The 2.x version of the driver should work perfectly. > > - Mike > > -- Cheers Jason Haar CyberSecurity Manager, Trimble Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
guacamole cannot use yum-version of mariadb-java-client under RockyLinux9 (but 8 is fine)
Hi there [summary: mariadb-java-client rpm in RockyLinux9 doesn't work, but if you copy mariadb-java-client.jar from RockyLinux8 it does. So is this a Rocky9 bug or something specific to guacamole?] We have a scripted guacamole installer for RockyLinux8 to use the "Redhat supported" rpm-based java/tomcat/mariadb/guacd rpms - and then just layer guacamole-server (as the only non "yum" app) on top of that. We use a range of extensions and rely on the JDBC mariadb connector. As it's scripted, all the extensions we use end up in the "extensions/" dir, and the JDBC connector in the "lib/" directory, configs are auto-generated, etc. Anyway, this all works fine on Rocky8, but we're trying to replace it with Rocky9 and ran into a problem. It all comes up, but the SQL calls all fail - with the infamous Error querying database. Cause: java.sql.SQLException: No suitable driver found for jdbc:mysql://127.0.0.1:3306/guacamole Packet sniffer shows not even a single port 3306 packet - so this error is happening earlier (ie cannot be database channel related). And yes we do have "mysql-driver: mariadb" in guacamole.properties After messing around for some time I thought to try replacing mariadb-java-client.jar file with the RockyLinux8 version and that fixed the problem. Rocky8 has mariadb-java-client-2.7.1-2.el8 and Rocky9 has mariadb-java-client-3.0.3-1.el9 Has anyone else run into this? It must be a bug - but I'm not sure it's because there's a bug in mariadb-java-client-3.0.3-1.el9, or that guacamole-1.4.0 doesn't support "v3" yet? Thanks -- Cheers Jason Haar CyberSecurity Manager, Trimble Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: Does Guacamole support PKI/Smartcard authentication for RDP (instead of username/password)?
- I'm not a very good one, and it isn't what I spend most of my > time doing - I'm a systems engineer/admin and IT Manager by day. My > contributions are pretty limited as compared to some of the other folks who > spend their time on the project, but I wrote the RADIUS extension when I > needed it enough in my #DayJob that I was willing to invest time in > brushing up on my Java skills and working with the other developers to get > the code to the point where it could be included in the project. > > > > > > > > -Nick > > - > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: sshd error not exposed to client
This is a good opportunity for me to bring up several gotchas I had
I'm running a new fully patched CentOS-7 system with standard repo installs
of apache-2.4.6, tomcat-7, guacd and with the WAR file from
guacamole-1.1.0, along with the jdbc-mysql, header and quickconnect
extensions.
Apache is configured with mod_auth_mellon (SAML) and uses a header to pass
the username to guacamole-auth-header, and the reverse-proxy part is
configured as
ProxyPass http://127.0.0.1:8080/guacamole/ flushpackets=on
ProxyPass http://127.0.0.1:8080/guacamole/
ProxyPassReverseCookiePath /guacamole/ /
Header set Connection Upgrade
Header set Upgrade %{HTTP_UPGRADE}e
ProxyPass ws://127.0.0.1:8080/guacamole/websocket-tunnel
ProxyPassReverse ws://127.0.0.1:8080/guacamole/websocket-tunnel
ProxyPassReverseCookiePath /guacamole/ /
You will notice the WebSocket headers - I had real difficulties getting
websocket to work - even though mod_proxy_wstunnel is loaded - so I
hard-wired those two headers in and that seemed to fix things.
As far as your "only admins should edit connections" comment goes, yeah I
know that is how guacamole intends to do things, but "CoronaVirus". I am
doing this as a POC with the intention to allow arbitrary staff remote
access from their personal/home computers to their workstations - so I'm
testing giving all users "create new connections" privs (because they would
also use it to access Cloud systems that can only be accessed from work
IPs, etc). Frankly it's not looking like a workable option, it's one thing
to expect "guacamole admins" to have good working knowledge of the product,
but not hundreds of engineers and other "normal" staff.
Also, I think there'd need to be more global control over what is available
in the "Connection" options. eg remove references to recording to disk or
sharing drives, globally ignoring cert validation would be needed for
quickconnect, etc. Great product - but I think I'm pushing beyond its
target market
On Sat, Mar 14, 2020 at 12:04 PM Mike Jumper
wrote:
> On Fri, Mar 13, 2020 at 3:26 PM Jason Haar wrote:
>
>> This is a CentOS7 system running the downloaded install of
>> guacamole-1.1.0 - but using the yum install guacd
>> (guacd-1.1.0-1.el7.x86_64). Even if I have an older version, the error msg
>> you see (Log in failed. Please reconnect and try again) is also misleading.
>> No amount of reconnecting is going to fix this :-)
>>
>
> In your specific case, perhaps not. In general, the expectation would be
> that entering invalid credentials could be resolved by reconnecting and
> entering the correct credentials, or by the administrator resolving
> whatever transient configuration issue is preventing credentials from being
> accepted. Guacamole has an error code for invalid credentials which
> produces that message, however there is no distinct error code for "your
> credentials are invalid, but also the server will never accept any of that
> type of credentials and reconnecting is pointless".
>
> There is an error code for when the remote desktop server is refusing the
> connection. That might be more appropriate for the case that the server is
> refusing to accept the credentials provided, but it does still advise the
> user to try again.
>
> Shouldn't that error literally be what guacd was reporting in the logs?
>> Way more useful to the end-user
>>
>
> No, that level of specific internal details shouldn't normally be exposed
> to the end-user. It needs to be exposed to the administrator, hence being
> logged, but the full nature of internal failures should not be exposed to
> users that wouldn't normally be aware of those failures.
>
>
>> Oh yeah, it is behind an apache reverse proxy - so maybe that changes the
>> error message?
>>
>
> Not changing it per se, but it might be causing it. Can you share your
> Apache configuration? Also, what browser and version is being used when
> this occurs?
>
> In general, connection-specific error messages are passed through
> Guacamole-specific status codes via the Guacamole protocol, independent of
> the HTTP or WebSocket transport. The connection stability warning is
> distinct from those messages in that it's produced on the client side,
> based on whether the HTTP or WebSocket tunnels detect possible connection
> instability.
>
> - Mike
>
>
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: sshd error not exposed to client
This is a CentOS7 system running the downloaded install of guacamole-1.1.0 - but using the yum install guacd (guacd-1.1.0-1.el7.x86_64). Even if I have an older version, the error msg you see (Log in failed. Please reconnect and try again) is also misleading. No amount of reconnecting is going to fix this :-) Shouldn't that error literally be what guacd was reporting in the logs? Way more useful to the end-user Oh yeah, it is behind an apache reverse proxy - so maybe that changes the error message? On Fri, Mar 13, 2020 at 8:18 AM Mike Jumper wrote: > On Thu, Mar 12, 2020 at 12:39 AM Jason Haar > wrote: > >> Hi there >> >> I just tried using guacamole-1.1.0 to log into an AWS Linux virtual. Type >> username and password, hit ENTER, pause and "the network connection appears >> unstable". >> >> I then looked at the guacd logs and see this >> >> guacd[13051]: Password and keyboard-interactive authentication are not >> supported by the SSH server >> >> This all makes sense. By default AWS Linux doesn't allow passwords - so >> indeed it should have failed. But as an end-user, that "network error" msg >> is confusing. >> >> Can that error be better exposed to the user? So they don't end up >> bashing their heads wondering what's going on? ie why can't the user see >> that sshd error message. >> > > Testing this myself against a build of 1.1.0, I don't see this behavior. > The message you note from guacd is logged, as would be expected, however > the error presented to the user is: > > "Log in failed. Please reconnect and try again." > > I'm not sure why you would be seeing the unstable network warning instead, > so it's worth figuring out why that is happening in your case, but it's > definitely not the intent. The intent is the above message. > > - Mike > > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
sshd error not exposed to client
Hi there I just tried using guacamole-1.1.0 to log into an AWS Linux virtual. Type username and password, hit ENTER, pause and "the network connection appears unstable". I then looked at the guacd logs and see this guacd[13051]: Password and keyboard-interactive authentication are not supported by the SSH server This all makes sense. By default AWS Linux doesn't allow passwords - so indeed it should have failed. But as an end-user, that "network error" msg is confusing. Can that error be better exposed to the user? So they don't end up bashing their heads wondering what's going on? ie why can't the user see that sshd error message. Thanks! -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
