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 <tjare...@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 <tjare...@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 <tjare...@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.couch...@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 <tjare...@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
  
             
 
 
        
  
       
 
 

Reply via email to