1

I've created a reverse proxy for webmin through nginx to run webmin at [site domain]/webmin instead of port 10000 ([site domain]:10000).

When I go to [site domain]/webmin, the login page shows up as you'd expect-- but when I try to login, the login page simply reloads (no error message, no success). The login page has all assets (images, js, etc.) properly loaded.

Looking at /var/webmin/miniserv.log, I'm seeing:
105.23.149.76 - - [26/Jul/2015:14:07:13 -0400] "POST //session_login.cgi HTTP/1.0" 401 2892

Note the 401 (not authorized) error status.

Before I set up the reverse proxy, successful logins looked like this:
145.23.98.124 - - [26/Jul/2015:13:34:38 -0400] "GET /admin/config/session_login.cgi HTTP/1.1" 401 2840 145.23.98.124 - root [26/Jul/2015:13:34:44 -0400] "POST /session_login.cgi HTTP/1.1" 200 871

My system auth log isn't getting pinged by the login attempts, so webmin isn't even making the login call via PEM (it's getting stopped before that).

Does anybody know what could explain this 401 error in my log, or more generally, what might be keeping webmin login from working?

Many thanks!


nginx config:

server {
        listen 443 ssl;
        server_name site.example.com;
        ssl on;

        ssl_certificate [ssl cert].crt;
        ssl_certificate_key [ssl key].key;
        ssl_protocols [ssl protocols];
        ssl_ciphers [ssl ciphers];

        location /webmin {
            proxy_redirect http://127.0.0.1:10000/ https://site.example.com/webmin/;
            proxy_pass http://127.0.0.1:10000/;
            proxy_set_header Host $host:$server_port;
        }
}
  • For what its worth, my configuration is the same as serverfault.com/questions/443482/proxying-webmin-with-nginx (as is my problem, only this fix doesn't work for me). I also found this article helpful and have tried these suggestions: serverfault.com/questions/98987/… – BBB Jul 26 '15 at 18:35
  • If you look at your paths in the example you are giving, the problem appears to lie within the proxy itself. As a side note, this is a security risk that you are opening up. Make sure that you have secure usernames and hardened passwords and keep an eye on your Webmin log. – closetnoc Jul 26 '15 at 22:40
  • Thanks... I'll look more at the proxy, but any suggestions? I just posted the nginx code above for review. Thanks for the note on security... I think I'm good because webmin is behind an internal auth setup, uses good usernames and strong passwords, and two factor auth is enabled. – BBB Jul 27 '15 at 4:05
  • It has been over 12 years since I set-up a proxy- I am a semi-retired core network engineer for the major global telcom networks- still, I have probably forgotten much. I will look into your edits and see if I can find something. It might take me a while to poke around. – closetnoc Jul 27 '15 at 4:11
  • The only quick thing I see is that you may want to try removing the trailing slashes in your proxy settings such as proxy_redirect 127.0.0.1:10000 site.example.com/webmin and proxy_pass 127.0.0.1:10000. Your failed attempt had two // slashes. Worth a try. – closetnoc Jul 27 '15 at 4:16
1

Try this solution, it works for me well:

/etc/webmin/config:

webprefix=/webmin
webprefixnoredir=1
relative_redir=0   # pay attention on this
referer=www.examle.com

/etc/webmin/miniserv.conf:

cookiepath=/webmin

nginx config:

location /webmin/ { 
    proxy_pass http://localhost:10000/;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Do not add proxy_set_header Host $host;, it won't work.

Webmin should be available on http://www.examle.com/webmin/

Source

  • It appears there may be some typos. I am not sure if they are deliberate. Can you double check? Cheers!! – closetnoc Jul 26 '18 at 22:07
0

It sounds like your web browser is naturally caching the problematic login pages and/or the headers returned for the login pages are not correct.

Check the speed of the page load. When you login and press the login button, if the load time is ridiculously fast compared to the first time the login screen has loaded, then you know that the previous page was cached and then being reloaded.

To workaround this problem temporarily, configure your web browser to disable all forms of caching and turn on cookies.

There's also a possibility that cookie values were not used at the time the page is requested after successful login. This results in every user seeing the same content as a guest would.

If you want to go more technical, then look for HTTP headers on each request using an advanced command line tool like CURL or maybe webpagetest.org may help as well, especially with page timings. The most important header to look for is:

Set-Cookie

Once the login button is selected and the correct credentials are used, then the response that is returned back to the browser should come with HTTP headers that contain Set-Cookie to indicate a user is logged in so that the next time a page from the same site is loaded in the same browser, a cookie is sent to the server to indicate the user has already logged in before.

And if you want to increase the chances of server requests being logged from you, just turn off caching for a while and do your testing. You might see a few repeated entries, especially if your pages always contain the same image.

  • Thanks for the reply... good thought, but I don't think that's the issue I'm having. Used private browsing / incognito, and changed the url. It still didn't work. I checked cURL, and this is in the header: – BBB Jul 27 '15 at 4:10
  • Set-Cookie: testing=1; path=/; httpOnly – BBB Jul 27 '15 at 4:10
  • pragma: no-cache Expires: Thu, 1 Jan 1970 00:00:00 GMT – BBB Jul 27 '15 at 4:11
  • Cache-Control: no-store, no-cache, must-revalidate – BBB Jul 27 '15 at 4:11
  • Cache-Control: post-check=0, pre-check=0 – BBB Jul 27 '15 at 4:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.