Nginx gives an Internal Server Error 500 after I have configured basic auth

Question

I am trying to do basic auth on Nginx. I have version 1.9.3 up and running on Ubuntu 14.04 and it works fine with a simple html file.

Here is the html file:

Answer 1

I will just stick the htpassword file under "/etc/nginx" myself. Assuming it is named htcontrol, then ...

sudo htpasswd -c /etc/nginx/htcontrol calvin

Follow the prompt for the password and the file will be in the correct place.

location / {
    ...

    auth_basic "Restricted";
    auth_basic_user_file htcontrol;
}

or auth_basic_user_file /etc/nginx/htcontrol; but the first variant works for me

Answer 2

Not really an answer to your question as you are using MD5. However as this thread pops up when searching for the error, I am attaching this to it.

Similar errors happen when bcrypt is used to generate passwords for auth_basic:

htpasswd -B <file> <user> <pass>

Since bcrypt is not supported within auth_basic ATM, mysterious 500 errors can be found in nginx error.log, (usually found at /var/log/nginx/error.log), they look something like this:

*1 crypt_r() failed (22: Invalid argument), ...

At present the solution is to generate a new password using md5, which is the default anyway.

Edited to address md5 issues as brought up by @EricWolf in the comments:

md5 has its problems for sure, some context can be found in the following threads

• Is md5 considered insecure?
• Is md5 still considered secure for single use authentications?

Of the two, speed issue can be mitigated by using fail2ban, by banning on failed basic auth you'll make online brute forcing impractical (guide). You can also use long passwords to try and fortify a bit as suggested here.

Other than that it seems this is as good as it gets with nginx...

Answer 3

First, check out your nginx error logs:

tail -f /var/log/nginx/error.log

In my case, I found the error:

[crit] 18901#18901: *6847 open() "/root/temp/.htpasswd" failed (13: Permission denied),

The /root/temp directory is one of my test directories, and cannot be read by nginx. After change it to /etc/apache2/ (follow the official guide https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/) everything works fine.

===

After executing the ps command we can see the nginx worker process maintained by the user www-data, I had tried to chown www-data:www-data /root/temp to make sure www-data can access this file, but it still not working. To be honest, I don't have a very deep understanding on Linux File Permissions, so I change it to /etc/apache2/ to fix this in the end. And after a test, you can put the .htpasswd file in other directories which in /etc (like /etc/nginx).

Answer 4

I too was facing the same problem while setting up authentication for kibana. Here is the error in my /var/log/nginx/error.log file

2020/04/13 13:43:08 [crit] 49662#49662: *152 crypt_r() failed (22: Invalid argument), client: 157.42.72.240, server: 168.61.168.150, request: “GET / HTTP/1.1”, host: “168.61.168.150”

I resolved this issue by adding authentication using this.

sudo sh -c "echo -n 'kibanaadmin:' >> /etc/nginx/htpasswd.users"
sudo sh -c "openssl passwd -apr1 >> /etc/nginx/htpasswd.users"

You can refer this post if you are trying to setup kibana and got this issue.

https://medium.com/@shubham.singh98/log-monitoring-with-elk-stack-c5de72f0a822?postPublishedType=repub

Answer 5

I had goofed up when initially creating a user. As a result, the htpasswd file looked like:

user:
user:$apr1$passwdhashpasswdhashpasswdhash...

After deleting the blank user, everything worked fine.

Answer 6

In my case, I had my auth_basic setup protecting an nginx location that was served by a proxy_pass configuration.

The configured proxy_pass location wasn't returning a successful HTTP200 response, which caused nginx to respond with an Internal Server Error after I had entered the correct username and password.

If you have a similar setup, ensure that the proxy_pass location protected by auth_basic is returning an HTTP200 response after you rule out username/password issues.