Geek Answers Handbook

Nginx gives an internal server 500 error after I configured basic auth

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

Here is the html file:

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title></title> </head> <body> "Some shoddy text" </body> </html>

And here is my nginx.conf file:

 user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf; server { listen 80; server_name 192.168.1.30; location / { root /www; index index.html; auth_basic "Restricted"; auth_basic_user_file /etc/users; } } }

I used htpasswd to create two users in the "users" file under / etc (the username is "calvin" password is "Calvin" and the username is "hobbes" password is "Hobbes"). It is encrypted, as follows:

 calvin:$apr1$Q8LGMfGw$RbO.cG4R1riIfERU/175q0 hobbes:$apr1$M9KoUUhh$ayGd8bqqlN989ghWdTP4r/

All files belong to root: root. The IP address of the server is 192.168.1.30, and I refer to this directly in the conf file.

Everything works fine, if I comment out the two auth lines and reload nginx, but if I uncomment them, then I really get the username and password prompts when I try to load the site, but right after that I get the error 500 Internal server error, which seems to be is saved and I have to restart nginx.

Can anyone see what I'm doing wrong here? I had the same behavior in the standard version of Ubuntu 14.04 apt-get version of Nginx (1.4.something), so I do not think that this is the version of nginx.

+10
nginx
source share
7 answers

Not quite the answer to your question when using MD5. However, when this thread appears while searching for an error, I attach it to it.

Similar errors occur when bcrypt used to generate passwords for auth_basic :

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

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

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

Currently, the solution is to generate a new password using md5, which is the default by default.

Edited to address md5 issues that were caused by @EricWolf in the comments:

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

  • Is md5 unsafe?
  • Is md5 still considered secure for single-user authentication?

Of the two issues, speed can be mitigated by using fail2ban , by banning an unsuccessful base authorization, you will make online forced enforcement impractical ( manual ). You can also use long passwords to try to strengthen a bit, as suggested here .

Also, it seems like it's as good as with nginx ...

+24
source share

I had a problem at initial user creation. As a result, the htpasswd file looked like this:

 user: user:$apr1$passwdhashpasswdhashpasswdhash...

After deleting an empty user, everything works fine.

+5
source share

I ran Nginx in a Docker environment and I had the same problem. The reason was that some passwords were generated using bcrypt. I resolved it using nginx:alpine .

+2
source share

I will just embed the htpassword file in "/ etc / nginx". Assuming it is called htcontrol , then ...

sudo htpasswd -c /etc/nginx/htcontrol calvin

Follow the password hint and the file will be in the right place.

 location / { ... auth_basic "Restricted"; auth_basic_user_file htcontrol; }

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

+1
source share

I had the same problem - after checking the log, as suggested by @Drazen Urch, I found that the file had root:root - after changing to forge:forge (I use Forge with Digital Ocean) - the problem disappeared.

+1
source share

Well, just use the correct RFC 2307 syntax:

 passwordvalue = schemeprefix encryptedpassword schemeprefix = "{" scheme "}" scheme = "crypt" / "md5" / "sha" / altscheme altscheme = "x-" keystring encryptedpassword = encrypted password

For example: sha1 for helloworld for admin would be * admin:{SHA}at+xg6SiyUovktq1redipHiJpaE=

I had the same error that I wrote {SHA1} which is against the RFC syntax. When I fixed it, everything worked like a charm. {sha} will not work either. Correct {SHA} .

0
source share

First check the nginx error logs:

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

In my case, I found an 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 changing 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 running the ps command, we can see the nginx workflow supported by the www-data user, I tried chown www-data:www-data/root/temp to make sure www-data can access this file, but it still does not work. Honestly, I'm not very good at Linux file permissions, so I changed it to /etc/apache2/ to fix this at the end. And after the test, you can place the .htpasswd file in other directories that have .htpasswd in /etc (for example, /etc/nginx ).

enter image description here

0
source share

More articles:


All Articles