Can't access SIAB behind a reverse-proxy about shellinabox

[GoogleCodeExporter]

I guess that a possible solution would be using the -p option to make SIAB 
listen on 
the same port number used by the web server. 

But unfortunately, this approach would only work if the web server and SIAB are 
running on different systems, which isn't always possible.

Original comment by [email protected] on 27 Jul 2009 at 2:24

[GoogleCodeExporter]

Additional information:

After running tshark, this is what i got:

<- GET /login HTTP/1.1..Host: myhost.com:8888..User-Agent: Mozilla5.0

-> HTTP/1.1 302 Found..Content-Length: 0..Content-Type: text/html..Location: 
http://
myhost.com:4200/login/

(Note that in this case i was using a web sever listening on 8888 and 
redirecting /
login to localhost:4200)

Original comment by [email protected] on 27 Jul 2009 at 2:40

[GoogleCodeExporter]

If you use a reverse proxy in front of ShellInABox, you have to let the proxy 
do the
encryption. How else would it be able to look into the session and decide where 
the
URL points to? After all, the whole point of encryption is that nobody can look 
at
the traffic -- not even your own proxy.

You then have to tell ShellInABox to run in plain-text mode when talking to the
proxy. That's what the "-t" option is for. And if you use "-t", you probably 
also
want "--localhost-only", so that only your reverse proxy connects directly to 
the
ShellInABox daemon.

Alternatively, you can always open that port on your firewall. It really 
depends on
whether you prefer your proxy or ShellInABox to do the encryption.

Original comment by [email protected] on 27 Jul 2009 at 3:22

• Changed state: WontFix

[GoogleCodeExporter]

Ok, that's a very good point. You're probably 100% right, and i should have 
thought 
about that before reporting. 

So let's take SSL/TLS sessions out of the equation for a while, and let's run 
SIAB 
with the -t option to disable the encryption completely. After restarting the 
daemon, this is what ps shows:

/usr/bin/shellinaboxd -q --background=/var/run/shellinaboxd.pid -c /var/lib/
shellinabox -p 4200 -u shellinabox -g shellinabox --no-beep -s 
/login:root:root:/:/
bin/login --localhost-only -t

Now, if i go to http://myhost.com/login, the result is the same as before. That 
is, 
the browser gets redirected to http://myhost.com:4200/login, which it can't 
access.

After repeating the experiment and capturing the traffic, this is the reply 
from 
SIAB:

HTTP/1.1 302 Found..Content-Length: 0..Content-Type: text/html..Location: 
http://
myhost.com:4200/login/

From this we can tell that the reverse proxy is indeed working (the incoming 
request 
reached shellinabox on the expected port), and SIAB is replying with a location 
header that points to port 4200.

Anyway, let's take the reverse proxy out of the equation too, and let's try 
with a 
plain and simple port forwarding rule from port 80 to port 4200. After trying 
that 
approach, i get the same result. 

Once again, i might be missing something embarassingly obvious here, and if 
that's 
the case, i sincerely apologize for the inconvenience.


Best regards,
Alex

Original comment by [email protected] on 27 Jul 2009 at 4:23

[GoogleCodeExporter]

I think, I see what you are doing. You have ShellInABox installed on "/login". 
It 
needs to tell the browser that this is a "directory" and there are resources 
underneath it, so it redirects the browser to "/login/". I bet, if you went to 
http://myhost.com/login/ everything would work just fine.

Ideally, you should configure your proxy so that it generates URLs with the 
appropriate number of slashes, when it forwards the request.

Often, it is easier to get this right, if you use the default "-s" line, as 
that 
forces you to think about the appropriate rewriting rules in the proxy 
configuration 
file.

BTW, it is often better to write "-s /:LOGIN" instead of "-s 
/:root:root:/:/bin/login". The "login" daemon has special calling conventions 
and 
ShellInABox knows about that, if you use the magic "LOGIN" keyword.

Original comment by [email protected] on 27 Jul 2009 at 4:53

[GoogleCodeExporter]

Let me know if the latest version of the code in SVN (rev 152) works better for 
you. I 
moved all the URL redirection code into JavaScript. In principle, this should 
make it 
more robust against subtle configuration problems with reverse proxies.

Original comment by [email protected] on 27 Jul 2009 at 6:31

• Changed state: Fixed

[GoogleCodeExporter]

Hi, i've just installed r152 and i can confirm that:

- It's working fine with a reverse proxy handled by lighttpd (running SIAB with 
the -
t option), and now a trailing slash is appended to the URL if it wasn't 
present. 

- It's working fine with a port forwarding rule (for example, 8888 -> 4200), 
with or 
without the -t option (this wasn't working with r149, so i think that the 
latest 
changes solved this issue)

BTW, thanks for the "-s /:LOGIN" tip.

Original comment by [email protected] on 27 Jul 2009 at 7:58