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 Thu, 24 Aug 2017 16:26:12 GMT

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