guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tjareson <tjare...@gmx.de>
Subject Re: IP of web session for ssh connection
Date Mon, 13 Nov 2017 22:29:21 GMT

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 
>> <tjareson@gmx.de> 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 
>>> <tjareson@gmx.de> <mailto:tjareson@gmx.de> 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 
>>>> <tjareson@gmx.de> <mailto:tjareson@gmx.de> 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 
>>>>> <tjareson@gmx.de> <mailto:tjareson@gmx.de> 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 
>>>>>> <nick.couchman@yahoo.com> <mailto:nick.couchman@yahoo.com>
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 
>>>>>> <tjareson@gmx.de> <mailto:tjareson@gmx.de> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>


Mime
View raw message