<div dir="ltr"><div><div><div>Got it Francis !!<br><br>server {<br>                listen 2001 ssl;<br><br>                ssl_certificate /etc/nginx/ssl/nginx.crt;<br>                ssl_certificate_key /etc/nginx/ssl/nginx.key;<br><br>                location / {<br>                                        auth_basic 'Restricted';<br>                                        auth_basic_user_file /home/20da689b45c84f2b80bc84d651ed573f/.htpasswd;<br><br>                                        if ($remote_user =  "20da689b45c84f2b80bc84d651ed573f") {<br>                                                proxy_pass <a href="https://127.0.0.1:2000">https://127.0.0.1:2000</a>;<br>                                        }<br><br>                }<br>        }<br><br><br><br></div>Love you !!! :P :P<br><br><br></div>Thanks and Regards,<br></div>Ajay<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 9, 2017 at 6:16 PM, Ajay Garg <span dir="ltr"><<a href="mailto:ajaygargnsit@gmail.com" target="_blank">ajaygargnsit@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Francis.<br><br></div>Thanks a ton for your suggestions.<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sun, Apr 9, 2017 at 5:58 PM, Francis Daly <span dir="ltr"><<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Apr 09, 2017 at 05:27:31PM +0530, Ajay Garg wrote:<br>
<br>
Hi there,<br>
<br>
</span><span>> Unfortunately, our backen-service(s) (on port 2000 in the example) is<br>
> ssh-reverse-tunnel, having two layers of machines behind them. The<br>
> terminating-node for sure cannot be changed.<br>
<br>
</span>"In general", reverse-proxying to a different part of the url hierarchy<br>
needs back-end support. In the specific case of your system, maybe it<br>
does not need anything special. Only you can tell.<br>
<span><br>
> Looking at your explanations, I guess then we will have to open a port for<br>
> every service.<br>
> So, for example, port 2001 for proxying to service running on ssh-tunnel at<br>
> 2000,<br>
<br>
</span>You could.<br>
<br>
Or, you could have nginx listening on public:2000 and proxy_pass'ing<br>
to local:2000, so you don't have to remember the public/private port<br>
mappings.<br>
<br>
Or you could have nginx listening on one port, and have multiple server{}<br>
blocks, so that userA connects to <a href="http://A.example.com" rel="noreferrer" target="_blank">A.example.com</a> which proxy_pass'es<br>
to local:2000; and userB connects to <a href="http://B.example.com" rel="noreferrer" target="_blank">B.example.com</a> which proxy_pass'es<br>
to local:2002.<br></blockquote><div><br></div></span><div>I doubt I would be allowed to do this, since we would be using a fixed IP (instead of the costly multiple DNS-addresses).<br><br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or, you could (potentially) have nginx listening on one port, with one<br>
server{} block, where anyone who authenticates as userA is proxy_pass'ed<br>
to local:2000 and anyone who authenticates as userB is proxy_pass'ed<br>
to local:2002.<br></blockquote><div><br></div></span><div>I would be very much interested if this case is possible.<br></div><div>Kindly let know how to do the proxy-routing based upon credentials.<br><br></div><div>This will really solve our last core issue (opening multiple ports), while preserving all the feature-sets.<br><br></div><div>So, will be grateful to hear back from you on how to implement this :)<br><br><br></div><div>Once again, thanks a ton for the speedy, detailed responses !!<br><br><br></div><div>Thanks and Regards,<br></div><div>Ajay<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In each of those cases, the reverse-proxying is not to a different part<br>
of the url hierarchy, so the original concern does not apply.<br>
<br>
Each case has its own costs and benefits, regarding future maintenance<br>
within nginx and external to nginx. All can work. Only you can decide<br>
which suits you best.<br>
<span><br>
> That brings me to my last question as per<br>
> <a href="http://mailman.nginx.org/pipermail/nginx/2017-April/053448.html" rel="noreferrer" target="_blank">http://mailman.nginx.org/piper<wbr>mail/nginx/2017-April/053448.<wbr>html</a>. If there<br>
> isn't an issue with opening multiple nginx-listening-ports to the public,<br>
> then I guess we are done.<br>
<br>
</span>Until you exhaust resources on your system, nginx does not care how many<br>
listening ports it opens.<br>
<br>
Good luck with it,<br>
<div class="m_-3137141841089971138HOEnZb"><div class="m_-3137141841089971138h5"><br>
        f<br>
--<br>
Francis Daly        <a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a><br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailm<wbr>an/listinfo/nginx</a><br>
</div></div></blockquote></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div class="m_-3137141841089971138gmail_signature" data-smartmail="gmail_signature">Regards,<br>Ajay<br></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Regards,<br>Ajay<br></div>
</div>