[OT] Re: limit login attempts

2022-01-04 Thread Piviul

Il 05/01/22 08:28, Piviul ha scritto:

Il 04/01/22 19:17, sam g ha scritto:

Hello,

I'm sure I'm asking a silly question but where would be this 
Guacamole log file where the login failed attempts are written?
I tried but I don't see anything in my 
/var/log/tomcat9/*localhost_access_log*.2022-01-04.txt or in 
/var/log/tomcat9/*localhost_access_log*.2022-01-04.txt .
With a "*systemctl status tomcat9*" I can see some "*WARN 
o.a.g.r.auth.AuthenticationService - Authentication attempt from 
a.b.c.d for user "zzzf" failed.*"
In my debian buster guacamole logs are sent to tomcat, so I can find 
failed logs in /var/log/tomcat/catalina.out
I add that after installing fail2ban you have enable it; in my debian 
buster I have added the file /etc/fail2ban/jail.d/guacamole.conf:


$ cat /etc/fail2ban/jail.d/guacamole.conf
[guacamole]
enabled = true

and then I updated the failregex to discover failed login attempt in 
/etc/fail2ban/filter.d/guacamole.conf. My failregex is:
failregex = ^.*WARN  o\.a\.g\.r\.auth\.AuthenticationService - 
Authentication attempt from  for user "[^"]*" failed\.$


Then look into /var/log/fail2ban.log to see if all is working as expected

Piviul


Re: limit login attempts

2022-01-04 Thread Piviul

Il 04/01/22 19:17, sam g ha scritto:

Hello,

I'm sure I'm asking a silly question but where would be this Guacamole 
log file where the login failed attempts are written?
I tried but I don't see anything in my 
/var/log/tomcat9/*localhost_access_log*.2022-01-04.txt or in 
/var/log/tomcat9/*localhost_access_log*.2022-01-04.txt .
With a "*systemctl status tomcat9*" I can see some "*WARN 
o.a.g.r.auth.AuthenticationService - Authentication attempt from 
a.b.c.d for user "zzzf" failed.*"
In my debian buster guacamole logs are sent to tomcat, so I can find 
failed logs in /var/log/tomcat/catalina.out


Piviul


Re: guacamole-client manual compilation

2022-01-04 Thread Piviul

Il 04/01/22 18:54, Piviul ha scritto:
I'm trying to add freeradius authentication to a guacamole-client 
installed on a debian buster. [...]

probably the log I sent lack of some important information...

This is the output sent on the standard error and attached you can find 
the log generated on the standard output:

# mvn package -Plgpl-extensions > guacamole-client.log
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
com.google.inject.internal.cglib.core.$ReflectUtils$1 
(file:/usr/share/maven/lib/guice.jar) to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of 
com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further 
illegal reflective access operations

WARNING: All illegal access operations will be denied in a future release


Please do you know where is the problem? I have to open a bug report? 
Can you successfully compile the guacamole-client?


Best regards

Piviul
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] guacamole-client   [pom]
[INFO] guacamole-common   [jar]
[INFO] guacamole-ext  [jar]
[INFO] guacamole-common-js[pom]
[INFO] guacamole  [war]
[INFO] extensions [pom]
[INFO] guacamole-auth-duo [jar]
[INFO] guacamole-auth-header  [jar]
[INFO] guacamole-auth-jdbc[pom]
[INFO] guacamole-auth-jdbc-base   [jar]
[INFO] guacamole-auth-jdbc-mysql  [jar]
[INFO] guacamole-auth-jdbc-postgresql [jar]
[INFO] guacamole-auth-jdbc-sqlserver  [jar]
[INFO] guacamole-auth-jdbc-dist   [pom]
[INFO] guacamole-auth-json[jar]
[INFO] guacamole-auth-ldap[jar]
[INFO] guacamole-auth-quickconnect[jar]
[INFO] guacamole-auth-sso [pom]
[INFO] guacamole-auth-sso-base[jar]
[INFO] guacamole-auth-sso-cas [jar]
[INFO] guacamole-auth-sso-openid  [jar]
[INFO] guacamole-auth-sso-saml[jar]
[INFO] guacamole-auth-sso-dist[pom]
[INFO] guacamole-auth-totp[jar]
[INFO] guacamole-auth-radius  [jar]
[INFO] guacamole-example  [war]
[INFO] guacamole-playback-example [war]
[INFO] 
[INFO] ---< org.apache.guacamole:guacamole-client >
[INFO] Building guacamole-client 1.4.0   [1/27]
[INFO] [ pom ]-
[INFO] 
[INFO] --- apache-rat-plugin:0.13:check (validate-licenses) @ guacamole-client ---
[INFO] Enabled default license matchers.
[INFO] Will parse SCM ignores for exclusions...
[INFO] Parsing exclusions from /root/guacamole-client-1.4.0/.gitignore
[INFO] Finished adding exclusions from SCM ignore files.
[INFO] 71 implicit excludes (use -debug for more details).
[INFO] Loading excludes from file /root/guacamole-client-1.4.0/.ratignore, using character set UTF-8
[INFO] 9 explicit excludes (use -debug for more details).
[INFO] 32 resources included (use -debug for more details)
[INFO] Rat check: Summary over all files. Unapproved: 1, unknown: 1, generated: 0, approved: 9 licenses.
[INFO] 

Delayed sftp downloads

2022-01-04 Thread Brad Saxton

I have Guacamole 1.3.0 installed and have a number of SSH connections defined 
with SFTP enabled. SFTP file uploads work without issue. SFTP file downloads 
work BUT the downloads only begin after disconnecting from the host session. 
This occurs regardless of whether the download is initiated via double clicking 
in the file browser panel or via guacctl. This has been tried via every browser 
type I have.

Is this expected behaviour or is there a configuration setting that I have 
missed somehow?

Thanks very much in advance for any guidance anyone can provide.

Brad

--

Brad Saxton
Senior System Administrator
Infrastructure Team
Brock University | Information Technology Services
Niagara Region | 1812 Sir Isaac Brock Way | St. Catharines, ON, Canada L2S 3A1
brocku.ca | T 905-688-5550 x4761 | F 905-688-4191


Re: Upgrade forces IPv6?

2022-01-04 Thread Hankins, Jonathan
I ran into this. On my system (debian) there are 2 entries for localhost in
/etc/hosts, one with 127.0.0.1 and one with ::1. I had no guacd.conf file.
My guacamole.properties had guacd-hostname set to "localhost". The sysctl
for ipv6 bindv6only was at the default of 0 (false).

My connections had "localhost" under the guacd proxy settings.

Guacd was apparently resolving localhost as ::1 but the web app was trying
to connect to "::127.0.0.1" which would fail since guacd was not
binding to 127.0.0.1.

I believe this is related to the changes from GUACAMOLE-1190, but I have
seen someone else ask about it on the list and I suspect others are hitting
this too. We don't use IPv6 (at least, not intentionally) so I wasn't up to
speed on things, and it caught me by surprise and took me a while to
un-confuse myself.

The solution that worked for me was setting guacd-hostname to 127.0.0.1 in
guacamole.properties, bind_host to 127.0.0.1 in guacd.conf, and leaving my
connections set to "localhost". I'm on tomcat9 and I suspect there's
something at play there that's causing guacd to resolve localhost to ::1
but the tunnel code in the web app to resolve it to 127.0.0.1, at least on
my system.

On Tue, Jan 4, 2022, 12:57 PM Brad Saxton  wrote:

> 
> Just in case someone has an answer for this or runs into the same problem.
>
> I upgraded a working instance of 1.3.0 to 1.4.0. Recompiled and installed
> guacd. Removed old extensions and copied the 1.4.0 versions in their place.
> Replaced the guacamole.war file and remove the old guacamole webapps
> directory. Started tomcat and guacd.
>
> Logging in to the web interface works and available connections are shown
> (ssh in my case). Attempts to use any connections results in an internal
> error. Log shows:
>
>  ERROR o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request
> failed: java.net.ConnectException: Connection refused (Connection refused)
>
> Things are configured (same as before - no changes to config files) to
> have guacd run on the standard port 4822 and guacd is definitely listening
> on that port BUT as it turns out, it is only listening on the IPv6
> interface.
>
> If I completely disable IPv6, which on Red Hat 7 is done with adding to
> the end of /etc/sysctl.conf:
>net.ipv6.conf.all.disable_ipv6 = 1
>net.ipv6.conf.default.disable_ipv6 = 1
>
> and rebooting.
>
> Now things work since guacd now binds to the IPv4 interface.
>
> Any chance there is a configuration setting to force binding to IPv4 even
> if IPv6 is available?
>
> Thanks
> Brad
>
>
> --
>
> Brad Saxton
> Senior System Administrator
> Infrastructure Team
> Brock University | Information Technology Services
> Niagara Region | 1812 Sir Isaac Brock Way | St. Catharines, ON, Canada
> L2S 3A1
> brocku.ca | T 905-688-5550 x4761 | F 905-688-4191
>

-- 
This e-mail is intended only for the recipient and may contain confidential 
or proprietary information. If you are not the intended recipient, the 
review, distribution, duplication or retention of this message and its 
attachments are prohibited. Please notify the sender of this error 
immediately by reply e-mail, and permanently delete this message and its 
attachments in any form in which they may have been preserved.


Upgrade forces IPv6?

2022-01-04 Thread Brad Saxton

Just in case someone has an answer for this or runs into the same problem.

I upgraded a working instance of 1.3.0 to 1.4.0. Recompiled and installed 
guacd. Removed old extensions and copied the 1.4.0 versions in their place. 
Replaced the guacamole.war file and remove the old guacamole webapps directory. 
Started tomcat and guacd.

Logging in to the web interface works and available connections are shown (ssh 
in my case). Attempts to use any connections results in an internal error. Log 
shows:

 ERROR o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: 
java.net.ConnectException: Connection refused (Connection refused)

Things are configured (same as before - no changes to config files) to have 
guacd run on the standard port 4822 and guacd is definitely listening on that 
port BUT as it turns out, it is only listening on the IPv6 interface.

If I completely disable IPv6, which on Red Hat 7 is done with adding to the end 
of /etc/sysctl.conf:
   net.ipv6.conf.all.disable_ipv6 = 1
   net.ipv6.conf.default.disable_ipv6 = 1

and rebooting.

Now things work since guacd now binds to the IPv4 interface.

Any chance there is a configuration setting to force binding to IPv4 even if 
IPv6 is available?

Thanks
Brad


--

Brad Saxton
Senior System Administrator
Infrastructure Team
Brock University | Information Technology Services
Niagara Region | 1812 Sir Isaac Brock Way | St. Catharines, ON, Canada L2S 3A1
brocku.ca | T 905-688-5550 x4761 | F 905-688-4191


Re: limit login attempts

2022-01-04 Thread sam g
 Hello,
I'm sure I'm asking a silly question but where would be this Guacamole log file 
where the login failed attempts are written?I tried but I don't see anything in 
my /var/log/tomcat9/localhost_access_log.2022-01-04.txt or in 
/var/log/tomcat9/localhost_access_log.2022-01-04.txt .
With a  "systemctl status tomcat9" I can see some " WARN  
o.a.g.r.auth.AuthenticationService - Authentication attempt from a.b.c.d for 
user "zzzf" failed."

Thanks,Sam
Le mardi 4 janvier 2022, 10:23:09 UTC+1, Mike Jumper  a 
écrit :  
 
 On Mon, Jan 3, 2022, 23:26 Vieri  wrote:

Hi,

I believe this question has already been asked, but I can't seem to find an 
answer in the docs or mailing list archives.

My Guacamole login mechanism uses LDAP (AD server). Now, I could configure the 
AD server to  disable user accounts after 3 login attempts.
However, I'm wondering of Guacamole itself has a way to limit user login 
attempts.


Not within Guacamole itself, but within the Guacamole server:
If you install fail2ban and configure it to recognize the invalid login 
messages in the Guacamole logs, then brute-force login attempts are 
automatically blocked at the firewall level.
- Mike


  

guacamole-client manual compilation

2022-01-04 Thread Piviul
I'm trying to add freeradius authentication to a guacamole-client 
installed on a debian buster. I have downloaded the source code and run 
the command:

# mvn clean package -Plgpl-extensions
[...]
[INFO] stopped 
o.e.j.s.h.ContextHandler{/webjars,file:/root/guacamole-client-1.4.0/}
[INFO] stopped 
o.e.j.s.h.ContextHandler{/classpath,file:/root/guacamole-client-1.4.0/}
[INFO] stopped 
o.e.j.s.h.ContextHandler{/,file:/root/guacamole-client-1.4.0/}
[INFO] stopped 
o.e.j.s.h.ContextHandler{/spec,file:/root/guacamole-client-1.4.0/}
[INFO] stopped 
o.e.j.s.h.ContextHandler{/src,file:/root/guacamole-client-1.4.0/}
[INFO] 


[INFO] Reactor Summary for guacamole-client 1.4.0:
[INFO]
[INFO] guacamole-client ... SUCCESS [ 
22.031 s]
[INFO] guacamole-common ... SUCCESS [ 
24.661 s]
[INFO] guacamole-ext .. SUCCESS [ 
18.390 s]
[INFO] guacamole-common-js  FAILURE 
[01:01 min]

[INFO] guacamole .. SKIPPED
[INFO] extensions . SKIPPED
[INFO] guacamole-auth-duo . SKIPPED
[INFO] guacamole-auth-header .. SKIPPED
[INFO] guacamole-auth-jdbc  SKIPPED
[INFO] guacamole-auth-jdbc-base ... SKIPPED
[INFO] guacamole-auth-jdbc-mysql .. SKIPPED
[INFO] guacamole-auth-jdbc-postgresql . SKIPPED
[INFO] guacamole-auth-jdbc-sqlserver .. SKIPPED
[INFO] guacamole-auth-jdbc-dist ... SKIPPED
[INFO] guacamole-auth-json  SKIPPED
[INFO] guacamole-auth-ldap  SKIPPED
[INFO] guacamole-auth-quickconnect  SKIPPED
[INFO] guacamole-auth-sso . SKIPPED
[INFO] guacamole-auth-sso-base  SKIPPED
[INFO] guacamole-auth-sso-cas . SKIPPED
[INFO] guacamole-auth-sso-openid .. SKIPPED
[INFO] guacamole-auth-sso-saml  SKIPPED
[INFO] guacamole-auth-sso-dist  SKIPPED
[INFO] guacamole-auth-totp  SKIPPED
[INFO] guacamole-auth-radius .. SKIPPED
[INFO] guacamole-example .. SKIPPED
[INFO] guacamole-playback-example . SKIPPED
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time:  02:07 min
[INFO] Finished at: 2022-01-04T14:50:14+01:00
[INFO] 

[ERROR] Failed to execute goal 
com.github.searls:jasmine-maven-plugin:2.2:test (default) on project 
guacamole-common-js: The jasmine-maven-plugin encountered an exception:
[ERROR] org.openqa.selenium.remote.UnreachableBrowserException: Could 
not start a new session. Possible causes are invalid address of the 
remote server or browser start-up failure.
[ERROR] Build info: version: '2.53.1', revision: 
'a36b8b1cd5757287168e54b817830adce9b0158d', time: '2016-06-30 19:26:09'
[ERROR] System info: host: 'guacamoletest', ip: '127.0.1.1', os.name: 
'Linux', os.arch: 'amd64', os.version: '5.4.157-1-pve', java.version: 
'11.0.13'

[ERROR] Driver info: driver.version: PhantomJSDriver
[ERROR] at 
org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:665)
[ERROR] at 
org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:249)
[ERROR] at 
org.openqa.selenium.remote.RemoteWebDriver.(RemoteWebDriver.java:131)
[ERROR] at 
org.openqa.selenium.remote.RemoteWebDriver.(RemoteWebDriver.java:144)
[ERROR] at 
org.openqa.selenium.phantomjs.PhantomJSDriver.(PhantomJSDriver.java:115)
[ERROR] at 
org.openqa.selenium.phantomjs.PhantomJSDriver.(PhantomJSDriver.java:104)
[ERROR] at 
com.github.searls.jasmine.driver.WebDriverFactory.createPhantomJsWebDriver(WebDriverFactory.java:149)
[ERROR] at 
com.github.searls.jasmine.driver.WebDriverFactory.createWebDriver(WebDriverFactory.java:68)
[ERROR] at 
com.github.searls.jasmine.mojo.TestMojo.createDriver(TestMojo.java:258)
[ERROR] at 
com.github.searls.jasmine.mojo.TestMojo.executeSpecs(TestMojo.java:228)
[ERROR] at 
com.github.searls.jasmine.mojo.TestMojo.run(TestMojo.java:196)
[ERROR] at 
com.github.searls.jasmine.mojo.AbstractJasmineMojo.execute(AbstractJasmineMojo.java:423)
[ERROR] at 
com.github.searls.jasmine.mojo.TestMojo.execute(TestMojo.java:183)
[ERROR] at 

Re: [ANNOUNCE] Apache Guacamole 1.4.0

2022-01-04 Thread Piviul

Il 04/01/22 12:07, Mike Jumper ha scritto:
According to the above, it's listening on IPv6 localhost. If Java is 
resolving localhost to the IPv4 address, then that would explain why 
the connection fails.


Try manually overriding the bind host for guacd to 127.0.0.1 
:


https://guacamole.apache.org/doc/gug/configuring-guacamole.html?highlight=bind_host#configuring-guacd 


That's seems to solve my problem!

Thank you very much Mike!

Piviul


Re: [ANNOUNCE] Apache Guacamole 1.4.0

2022-01-04 Thread Mike Jumper
On Tue, Jan 4, 2022, 02:46 Piviul  wrote:

> Il 04/01/22 10:17, Mike Jumper ha scritto:
>
> On Tue, Jan 4, 2022, 00:34 Piviul  wrote:
>
>> [2022-01-04 09:08:35] [info] 09:08:35.687
>> [https-openssl-nio-8443-exec-2] ERROR
>> o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket tunnel
>> to guacd failed: java.net.ConnectException: Connection refused
>> (Connection refused)
>> [2022-01-04 09:08:35] [info] 09:08:35.778
>> [https-openssl-nio-8443-exec-1] ERROR o.a.g.s.GuacamoleHTTPTunnelServlet
>> - HTTP tunnel request failed: java.net.ConnectException: Connection
>> refused (Connection refused)
>>
>
> This means guacd is not running or is not listening on the expected
> address.
>
> but guacd seems to work correctly:
>
> # systemctl status guacd.service
> ...
> Jan 04 08:51:22 guacamoletest systemd[1]: Started LSB: Guacamole proxy
> daemon.
> Jan 04 08:51:22 guacamoletest guacd[186]: Listening on host ::1, port 4822
>
> guacd seems to be running... please can you help me to verify if guacd is
> listening on the expected address?
>

According to the above, it's listening on IPv6 localhost. If Java is
resolving localhost to the IPv4 address, then that would explain why the
connection fails.

Try manually overriding the bind host for guacd to 127.0.0.1:

https://guacamole.apache.org/doc/gug/configuring-guacamole.html?highlight=bind_host#configuring-guacd

- Mike


Aw: Re: Fetch API-token not working in 1.4.0

2022-01-04 Thread michael böhm
Hello Mike,

 

you were perfectly right.

 

When I add the Content-Type header, I can fetch the token via Python:

 

#

 

response = requests.post(api_url, data="" headers={"Content-Type":"application/x-www-form-urlencoded"})

 

#

 

Thanks for your quick help.

 

Michael


Gesendet: Dienstag, 04. Januar 2022 um 11:03 Uhr
Von: "Mike Jumper" 
An: user@guacamole.apache.org
Betreff: Re: Fetch API-token not working in 1.4.0




On Tue, Jan 4, 2022, 01:36 michael böhm  wrote:



Hello everyone

 

I upgraded to 1.4.0 and since then I cannot fetch the API token using this example Python code:

 

##

 


#!/usr/bin/python3

import sys
import json
import requests
import os

 

guac_host = "127.0.0.1"
guac_port = "8080"
guac_api_base = "http://{}:{}/guacamole/api/".format(guac_host, guac_port)
guac_username = "guacadmin"
guac_password = "***PASSWORD***"

 

os.environ['NO_PROXY'] = '127.0.0.1'

 

def get_guac_api_token(guac_username, guac_password):
    api_url = "{0}tokens".format(guac_api_base)
    text_body = "username={0}={1}".format(guac_username, guac_password)
    response = requests.post(api_url, data="">

 

    if not response.status_code == 200:
    print(response.status_code)
    print(response.content)
    print("Error acquiring guacamole api-token. Aborting")
    return(None)

 

    json_response = response.content.decode()
    json_response = json.loads(json_response)
    return json_response["authToken"]

 

api_token = get_guac_api_token(guac_username, guac_password)

 

if api_token is None:
    exit(1)

 

##

 

Output is:

 


500
b'{"message":"Unexpected internal error","translatableMessage":{"key":"APP.TEXT_UNTRANSLATED","variables":{"MESSAGE":"Unexpected internal error"}},"statusCode":null,"expected":null,"type":"INTERNAL_ERROR"}'
Error acquiring guacamole api-token. Aborting

 

 

Has there anything changed from 1.3.0 where everything is working fine?






 

Not directly, but a number of dependencies were upgraded, including Jersey. It's possible the newer Jersey is more strict in its request handling.

 

If you can throw up a packet capture to see the actual content of the request, I would compare that against the request sent by the browser during login to see where the difference lies.

 

My guess is that you are missing a header in the Python code, presumably "Content-Type: application/x-www-form-urlencoded".

 

- Mike

 

 






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



Re: [ANNOUNCE] Apache Guacamole 1.4.0

2022-01-04 Thread Piviul

Il 04/01/22 10:17, Mike Jumper ha scritto:
On Tue, Jan 4, 2022, 00:34 Piviul > wrote:


[2022-01-04 09:08:35] [info] 09:08:35.687
[https-openssl-nio-8443-exec-2] ERROR
o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket
tunnel
to guacd failed: java.net.ConnectException: Connection refused
(Connection refused)
[2022-01-04 09:08:35] [info] 09:08:35.778
[https-openssl-nio-8443-exec-1] ERROR
o.a.g.s.GuacamoleHTTPTunnelServlet
- HTTP tunnel request failed: java.net.ConnectException: Connection
refused (Connection refused)


This means guacd is not running or is not listening on the expected 
address.

but guacd seems to work correctly:

# systemctl status guacd.service
* guacd.service - LSB: Guacamole proxy daemon
   Loaded: loaded (/etc/init.d/guacd; generated)
   Active: active (running) since Tue 2022-01-04 08:51:22 CET; 2h 
43min ago

 Docs: man:systemd-sysv-generator(8)
    Tasks: 1 (limit: 154592)
   Memory: 15.1M
   CGroup: /system.slice/guacd.service
   `-186 /usr/local/sbin/guacd -p /var/run/guacd.pid

Jan 04 08:51:22 guacamoletest systemd[1]: Starting LSB: Guacamole 
proxy daemon...
Jan 04 08:51:22 guacamoletest guacd[161]: Guacamole proxy daemon 
(guacd) version 1.4.0 started
Jan 04 08:51:22 guacamoletest guacd[155]: Starting guacd: guacd[161]: 
INFO:    Guacamole proxy daemon (guacd) version 1.4.0 started

Jan 04 08:51:22 guacamoletest guacd[155]: SUCCESS
Jan 04 08:51:22 guacamoletest systemd[1]: Started LSB: Guacamole proxy 
daemon.

Jan 04 08:51:22 guacamoletest guacd[186]: Listening on host ::1, port 4822
guacd seems to be running... please can you help me to verify if guacd 
is listening on the expected address?


No, there are no incremental changes that would need to be layered 
like that. You can go directly from any 1.x release to any other 1.x 
release.

very good, thank you very much.

Piviul


Re: Fetch API-token not working in 1.4.0

2022-01-04 Thread Mike Jumper
On Tue, Jan 4, 2022, 01:36 michael böhm  wrote:

> Hello everyone
>
> I upgraded to 1.4.0 and since then I cannot fetch the API token using this
> example Python code:
>
> ##
>
> #!/usr/bin/python3
> import sys
> import json
> import requests
> import os
>
> guac_host = "127.0.0.1"
> guac_port = "8080"
> guac_api_base = "http://{}:{}/guacamole/api/".format(guac_host, guac_port)
> guac_username = "guacadmin"
> guac_password = "***PASSWORD***"
>
> os.environ['NO_PROXY'] = '127.0.0.1'
>
> def get_guac_api_token(guac_username, guac_password):
> api_url = "{0}tokens".format(guac_api_base)
> text_body = "username={0}={1}".format(guac_username,
> guac_password)
> response = requests.post(api_url, data=text_body.encode("utf-8"))
>
> if not response.status_code == 200:
> print(response.status_code)
> print(response.content)
> print("Error acquiring guacamole api-token. Aborting")
> return(None)
>
> json_response = response.content.decode()
> json_response = json.loads(json_response)
> return json_response["authToken"]
>
> api_token = get_guac_api_token(guac_username, guac_password)
>
> if api_token is None:
> exit(1)
>
> ##
>
> Output is:
>
> 500
> b'{"message":"Unexpected internal
> error","translatableMessage":{"key":"APP.TEXT_UNTRANSLATED","variables":{"MESSAGE":"Unexpected
> internal
> error"}},"statusCode":null,"expected":null,"type":"INTERNAL_ERROR"}'
> Error acquiring guacamole api-token. Aborting
>
>
> Has there anything changed from 1.3.0 where everything is working fine?
>

Not directly, but a number of dependencies were upgraded, including Jersey.
It's possible the newer Jersey is more strict in its request handling.

If you can throw up a packet capture to see the actual content of the
request, I would compare that against the request sent by the browser
during login to see where the difference lies.

My guess is that you are missing a header in the Python code, presumably
"Content-Type: application/x-www-form-urlencoded".

- Mike


Fetch API-token not working in 1.4.0

2022-01-04 Thread michael böhm
Hello everyone

 

I upgraded to 1.4.0 and since then I cannot fetch the API token using this example Python code:

 

##

 


#!/usr/bin/python3

import sys
import json
import requests
import os

 

guac_host = "127.0.0.1"
guac_port = "8080"
guac_api_base = "http://{}:{}/guacamole/api/".format(guac_host, guac_port)
guac_username = "guacadmin"
guac_password = "***PASSWORD***"

 

os.environ['NO_PROXY'] = '127.0.0.1'

 

def get_guac_api_token(guac_username, guac_password):
    api_url = "{0}tokens".format(guac_api_base)
    text_body = "username={0}={1}".format(guac_username, guac_password)
    response = requests.post(api_url, data="">

 

    if not response.status_code == 200:
    print(response.status_code)
    print(response.content)
    print("Error acquiring guacamole api-token. Aborting")
    return(None)

 

    json_response = response.content.decode()
    json_response = json.loads(json_response)
    return json_response["authToken"]

 

api_token = get_guac_api_token(guac_username, guac_password)

 

if api_token is None:
    exit(1)

 

##

 

Output is:

 


500
b'{"message":"Unexpected internal error","translatableMessage":{"key":"APP.TEXT_UNTRANSLATED","variables":{"MESSAGE":"Unexpected internal error"}},"statusCode":null,"expected":null,"type":"INTERNAL_ERROR"}'
Error acquiring guacamole api-token. Aborting

 

 

Has there anything changed from 1.3.0 where everything is working fine?

 

Thanks and best wishes

 

Michael


 


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



Re: limit login attempts

2022-01-04 Thread Mike Jumper
On Mon, Jan 3, 2022, 23:26 Vieri  wrote:

> Hi,
>
> I believe this question has already been asked, but I can't seem to find
> an answer in the docs or mailing list archives.
>
> My Guacamole login mechanism uses LDAP (AD server). Now, I could configure
> the AD server to  disable user accounts after 3 login attempts.
> However, I'm wondering of Guacamole itself has a way to limit user login
> attempts.
>

Not within Guacamole itself, but within the Guacamole server:

If you install fail2ban and configure it to recognize the invalid login
messages in the Guacamole logs, then brute-force login attempts are
automatically blocked at the firewall level.

- Mike


Re: [ANNOUNCE] Apache Guacamole 1.4.0

2022-01-04 Thread Mike Jumper
On Tue, Jan 4, 2022, 00:34 Piviul  wrote:

> Il 04/01/22 06:53, Piviul ha scritto:
> > Hi Nick, thank you very much; there is a way to know the version I
> > have installed? I think I have the 1.1 version of guacamole on a
> > debian buster...
> ok, I can confirm, I have the 1.1 version. Now I have compiled the
> server, replaced the client and replaced the extensions but i get the
> following error when I try to connect to an rdp connection:
> [2022-01-04 09:08:35] [info] 09:08:35.687
> [https-openssl-nio-8443-exec-2] ERROR
> o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket tunnel
> to guacd failed: java.net.ConnectException: Connection refused
> (Connection refused)
> [2022-01-04 09:08:35] [info] 09:08:35.778
> [https-openssl-nio-8443-exec-1] ERROR o.a.g.s.GuacamoleHTTPTunnelServlet
> - HTTP tunnel request failed: java.net.ConnectException: Connection
> refused (Connection refused)
>

This means guacd is not running or is not listening on the expected address.

Do you think that it is better to upgrade from 1.1 to 1.4 upgrading one
> release at time i.e. 1.1->1.2 and then 1.2->1.3 and finally 1.3->1.4?
>

No, there are no incremental changes that would need to be layered like
that. You can go directly from any 1.x release to any other 1.x release.

- Mike


Re: [ANNOUNCE] Apache Guacamole 1.4.0

2022-01-04 Thread Piviul

Il 04/01/22 06:53, Piviul ha scritto:
Hi Nick, thank you very much; there is a way to know the version I 
have installed? I think I have the 1.1 version of guacamole on a 
debian buster...
ok, I can confirm, I have the 1.1 version. Now I have compiled the 
server, replaced the client and replaced the extensions but i get the 
following error when I try to connect to an rdp connection:
[2022-01-04 09:08:35] [info] 09:08:35.687 
[https-openssl-nio-8443-exec-2] ERROR 
o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket tunnel 
to guacd failed: java.net.ConnectException: Connection refused 
(Connection refused)
[2022-01-04 09:08:35] [info] 09:08:35.778 
[https-openssl-nio-8443-exec-1] ERROR o.a.g.s.GuacamoleHTTPTunnelServlet 
- HTTP tunnel request failed: java.net.ConnectException: Connection 
refused (Connection refused)


Do you think that it is better to upgrade from 1.1 to 1.4 upgrading one 
release at time i.e. 1.1->1.2 and then 1.2->1.3 and finally 1.3->1.4?


Piviul

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



Re: compile warning

2022-01-04 Thread Piviul

Il 04/01/22 08:26, Mike Jumper ha scritto:

[...]
Please don't do this - the warning is there for a reason. The proper 
solution is not to bypass the warning with that flag, but to install a 
stable release of FreeRDP.
done, I have installed the freerdp  from backports and recompiled the 
guacamole server and now the process seems to be compiled correctly.


Have a great day

Piviul

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