Hi Nick,
do you know if that topic will ever get addressed somehow?
I'm not quite sure, what I could do to support that.
That was the issue that the IP address of the web session is not
correctly provided in ${GUAC_CLIENT_ADDRESS} when starting e.g. a ssh
session.
kind regards
Tjareson
Am 24.08.2017 um 12:26 schrieb Tjareson:
https://issues.apache.org/jira/browse/GUACAMOLE-369
<https://issues.apache.org/jira/browse/GUACAMOLE-369>
Am 24.08.2017 um 11:49 schrieb Nick Couchman:
As far as NoAuth, I think that's pretty much a closed issue - there's
not really any support for that among the development community. You
might try, instead, using either SSO or LDAP and then using the
${GUAC_USERNAME} and ${GUAC_PASSWORD} tokens to pass through
authentication such that you can avoid the dual-login requirements.
I do understand the frustration there - I've lived the admin side of
things for long enough that I recognize that you want to make the
experience as simple as possible for users, and asking them to login
twice can cause frustration. I also realize that use of SSO or LDAP
modules would require your destination SSH server to use the same
authentication that Guacamole does, and that that's not always
possible, but you can probably work something out, there.
Yeah, probably good to go ahead and log a JIRA issue for the IP issue
you're seeing.
-Nick
On Thursday, August 24, 2017, 11:45:40 AM EDT, Tjareson
<[email protected]> wrote:
Yes, I saw some discussion about the no-auth as well. It's a bit of a
pity that it will be removed.
Even if off-topic here right now: I think in the end it will in fact
make it more confusing for the user. Today I can tell the user "You
only ever type your credentials into the login screen of the
application, never anywhere else." Which makes it clear and easy to
remember and avoids fishing.
Without no-auth, the user has to login either at login screen of
guacamole and/or at the login screen of the application, in case he
or she connects on the internal network directly with a Putty client.
So we are loosing that unique point where to type in login data only.
Is that still under discussion, means is there a point where I can
mention my argument?
Back to the topic: if you could find something where the ip behaviour
could be changed that would be very helpful.
Would it make sense, if I log an issue for that?
I've also checked the option to track down the web ip of a ssh
session with lsof and netstat and all logs, to see who is talking to
whom via which ports. But it always stops where communication is
aggregated in one single process and connections becoming 1:n. (e.g.
nginx)
kind regards
Tjareson
Am 24.08.2017 um 09:02 schrieb Nick Couchman:
A word of caution about no-auth: it is deprecated, no longer
maintained or supported, and will not be available in future releases.
As far as why it's not getting updated, I'm not sure off the top of
my head, except that there's likely a session somewhere in the
Guacamole Servlet code that has the data cached for a particular
user login. I'll see if I can do some debugging on this and figure
out where it's happening and what needs to be done to flush it out.
-Nick
== He has shown you, O man, what is good; And what does the LORD
require of you But to do justly, To love mercy, And to walk humbly
with your God? --Micah 6:8-- ==
On Wednesday, August 23, 2017, 7:16:51 PM EDT, Tjareson
<[email protected]> <mailto:[email protected]> wrote:
By the way: I see the same phenomenon when I'm using no-auth, where
there is no specific user anymore.
If it works proper with no-auth it would have been a solution in my
case already as the application does a proper authentication anyway.
(so currently I'm redirecting all users to a url containing a
default user name and password, so they do not need to authenticate
twice.)
So the not changing ip address in ${GUAC_CLIENT_ADDRESS} remains
kind of a question mark.
Am 23.08.2017 um 17:38 schrieb Nick Couchman:
There may be some buffering done inside the Guacamole code
somewhere - I'm not sure about that. Maybe Mike or James can chime
in and confirm or debunk that?
-Nick
On Wednesday, August 23, 2017, 5:10:19 PM EDT, Tjareson
<[email protected]> <mailto:[email protected]> wrote:
Hi Nick,
that did the trick.
Do you know if there is any setting stopping tomcat7 (or maybe
guacd) from buffering the ip?
Currently I have the odd situation that if I log in from a
different ip address with the same user I see this different ip
address in catalina.out, but the first ip it got after starting
tomcat stays in ${GUAC_CLIENT_ADDRESS}, no matter if I logout the
user before or not.
It looks like that the user session for a particular username in
guacamole gets buffered somewhere.
Only if I restart tomcat then the ip gets updated.
The odd thing is: catalina.out shows always the correct ip and a
restart of guacd doesn't reset this link between username and ip of
first login.
I'm not sure, if the connection between tomcat and guacamole gets
really terminated, when the user logs out, as the user is falling
back on the guacamole login screen only, which would probably
explain that the ip from the first session survives somehow, even
if the same user logs in from a different ip.
kind regards
Tjareson
Am 23.08.2017 um 14:46 schrieb Nick Couchman:
In addition to what you've set up there (which I believe is
correct), you also need to add the remote IP valve to your Tomcat
configuration file. I did this by adding this block of code just
inside the closing </Host> tag in my server.xml file:
<Valve className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="127.0.0.1"
remoteIpHeader="x-forwarded-for"
remoteIpProxiesHeader="x-forwarded-by"
protocolHeader="x-forwarded-proto" />
Please note that you should research and consider the security
implications of enabling this. I dug into it when I added the
functionality for the GUAC_CLIENT_ADDRESS token, but it's been
long enough that I don't recall exactly what the risks are. I
believe that you need to pay particular attention to the value of
"internalProxies" and make sure that you trust the hosts listed as
internal proxies - that is, that someone you don't trust does not
have access to those systems in a way that would allow them to use
the remote IP valve to do something malicious, deceptive, etc.
Obviously this is specific to Tomcat + Nginx - I can't remember
what the steps are for Tomcat + Apache and have never tried it
with any other application server (JBoss, Weblogic, etc.).
-Nick
On Wednesday, August 23, 2017, 2:29:16 PM EDT, Tjareson
<[email protected]> <mailto:[email protected]> wrote:
Hi
the approach as such works in principle, as I get the ip passed
through the ssh connection by just setting ${GUAC_CLIENT_ADDRESS}
as command parameter in the ssh connection settings.
Unfortunately the ip is 127.0.0.1 again. (same with ...HOSTNAME)
My guess is it might be because I'm using nginx as reverse proxy.
Which ip is guacamole using to provide
${GUAC_CLIENT_ADDRESS/HOSTNAME}?
In the proxy setup I have set
|proxy_set_header Host $host; proxy_buffering off;
proxy_http_version 1.1; proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header
Upgrade $http_upgrade; proxy_set_header Connection
$http_connection; proxy_pass http://localhost:8080/; |
Is anyone using the client IP in a similar setup?
kind regards
Tjareson
Am 23.08.2017 um 11:56 schrieb Tjareson:
Hi Nick,
the execute command option sounds like a good idea.
I saw the ${GUAC_CLIENT_ADDRESS} token but wasn't aware that guacd
supports the command parameter for ssh connections.
Usually I start the application after ssh login directly via
/etc/passwd, but by ssh command should work as well, so I can
process the ip as parameter of the application then. I just need
to check then to what extent that would allow users that use ssh
directly to start other applications then.
I'll give that a try, thanks for the hint!
regards
Tjareson
Am 23.08.2017 um 10:36 schrieb Nick Couchman:
Took a look at the available SSH client options, and I do not see
an obvious way to pass through the client hostname/IP/identity to
the server. Here are the two options I see:
- As mentioned before, you can use the Execute Command parameter
to pass through the identity using the token. You'd have to set
up a startup script or something like that, or figure out the
right way to use the execute command option to set a variable and
then launch the shell or whatever application you want to launch
with that variable. This is the only way to do it currently, and
probably the best bet.
- It is possible to set up SSH clients and servers to send
environment variables between the client and server. I would
imagine Guacamole could be tweaked to add this
functionality...but...it seems like a little bit of a corner case
to add, particularly given that you'd have to both configure
Guacamole to have some map of arbitrary environment variables and
values (and sanitize them for security purposes), and, in order
for this to work, the SSH server has to be configured, not just
to allow variables, but with the specific list of variables that
you want to pass through. That's a lot of extra configuration to
allow this behavior - particularly given the fact that you can
just do it on the command line.
-Nick
On Wednesday, August 23, 2017, 9:49:36 AM EDT, Nick Couchman
<[email protected]> <mailto:[email protected]> wrote:
Tjareson,
While RDP currently has an option to pass through the client
name, SSH does not. I need to look and see if there's an easy
way to enable this functionality in Guacamole, but the only thing
I'd suggest today is that you might be able to find a way to use
the "Execute Command" parameter for SSH connections to pass in
that token.
-Nick
On Wednesday, August 23, 2017, 9:34:55 AM EDT, Tjareson
<[email protected]> <mailto:[email protected]> wrote:
Hi,
I'm using an ncurses based database application, which makes use
of the
IP address of the ssh session from which it got used to e.g.
chose the
right printer, rfid reader etc.
This became web enabled now with guacamole and I was wondering if
there
is any easy way to get hold of the IP address of the web session
which
is used to connect via ssh to that application mentioned above.
The setup is like this:
user <-> nginx <-> tomcat <-> guacd <-> ssh <-> ncurses application
All components from nginx to the ncurses application are on the same
server. But of course from the application side it looks always
that the
connection is coming from where tomcat/guacd sits, so 127.0.0.1
in this
case.
I could probably somehow browse through all logs,
/proc/<process-id>/status and netstat to somehow figure out, who is
talking with whom, but I hope there is a more convenient approach
for
this? I found that there is ${GUAC_CLIENT_ADDRESS} but I'm not
sure if
there is any way to hand that over via ssh session.
regards
Tjareson
