Nginx - Password Protect Not Working - nginx

I have followed instructions and still I cant password protect my site. This is what my app-nginx.config looks like:
server {
listen 80;
server_name Server_Test;
auth_basic "Restricted";
auth_basic_user_file /usr/local/nginx/conf/htpasswd;
...
}
Where am I going wrong? I copied and pasted this right from a tutorial site.

Make sure Nginx can access the password file. Paths for the auth_basic_user_file are relative to the directory of nginx.conf. So if your nginx.conf is located in /usr/local/nginx you can change your directive to:
auth_basic_user_file conf/htpasswd;
and the file must be readable.
This file should be readable by workers, running from unprivileged
user. E. g. when nginx run from www you can set permissions as:
chown root:nobody htpasswd_file
chmod 640 htpasswd_file
-- from http://wiki.nginx.org/HttpAuthBasicModule

Just made my nginx server to work, and even configured it to protect my root folder access. I'd like to share my findings with you and on the way also give a good and working answer to the question in this page.
As a new user to nginx (Version 1.10.0 - Ubuntu).
The first problem I've got was to know the file locations, so here are the critical locations:
Know your locations:
Main folder location: /etc/nginx
Default site location: /var/www/ or even /ver/www/html/ (inside the html folder will be the index.html file - hope you know what to do from there.)
Configuration files:
Main configuration file: /etc/nginx/nginx.conf
Current site server conf: /etc/nginx/sites-enabled (upon first installation there is a single file there that is called default, and you'll need to use sudo to be able to change it (for example:
sudo vi default)
Add password:
So, now that e know the players (for a static out-of-the-box site anyway) let's put some files in the 'html' folder and let's add password protection to it.
To setup a password we need to do 2 things:
create a passwords file (with as many users as we want, but I'll settle with 1).
Configure the current server ('default') to restrict this page and use the file in 1 to enable the password protection.
1. Let's create a password:
The line I'd like to use for this is:
sudo htpasswd -c /etc/nginx/.htpasswd john (you'll get a prompt to enter and re-enter the password) of you can do it in a single line here:
sudo htpasswd -c /etc/nginx/.htpasswd john [your password]
I'll explain each part of the command:
sudo htpasswd - do it using higher permission.
-c - for: create file (to add another user to an existing user skip this argument)
/etc/nginx/.htpasswd - the name of the file created
('.htpsswd' in the folder /etc/nginx)
john is the name of the user (to enter in the prompted 'user' field)
password is the needed password for this specific user name. (when prompted..)
Usually the htpasswd command won't work for you, so you'll have to install it's package:
Use: sudo apt-get install apache2-utils (if it fails try using sudo apt-get update and try again)
2. Let's configure the server to use this file for authentication
Let's use this line to edit the current (default) server conf file:
sudo vi /etc/nginx/sites-enabled/default (You don't have to use 'vi' but I like it..)
The file looks like this after removing most of the comments (#)
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
}
We'll need to add two lines inside the block the location ('/' points to the root folder of the site) so it'll look like this:
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;
}
I'll explain these new lines:
auth_basic "Restricted Content"; - defines the type of access management
auth_basic_user_file /etc/nginx/.htpasswd; - defines the file we've created (/etc/nginx/.htppasswd) as the passwords file for this authentication.
Let's restart the service and enjoy a password protected site:
sudo service nginx restart
Voila - enjoy...
Here are some more great tutorials for this:
Very good explanation
Another goo tutorial

Related

how to add/override a new nginx configuration file?

I have a somedomain.com.conf file under /etc/nginx/sites-available in linux (RHEL). if i want to host a web app/site, do i just edit the same file or create a new configuration file for nginx? I edited this file and it works, but trying to find the right way to do this. is the convention , create a new config file for each site/app, you host?
server {
listen 80;
server_name mysite.com;
charset utf-8;
root /var/www/mysite-folder;
index index.html index.htm;
location / {
root /var/www/mysite-folder;
try_files $uri /index.html;
}
}
I thought the RHEL-based systems doesn't make use of that sites-enabled/sites-available mechanism at all (in opposite to Debian-based distros). Of course, the most common approach is to use a separate files for each hosted domain name (maybe including the subdomains). All those files are being included from the top level configuration file /etc/nginx/nginx.conf at the http context level; the Debian packages usually have
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
lines in that file while RHEL packages usually have only the single
include /etc/nginx/conf.d/*.conf;
line. As you can see files in the sites-enabled directory may be named any way while files in the conf.d directory should have the .conf extension to be included (and you can rename it so something like <donain>.off to temporary exclude from nginx configuration). What directory to use for your vhost configuration is up to you (I personally prefer to use /etc/nginx/conf.d/ since it is a more universal way). There is a big Difference in sites-available vs sites-enabled vs conf.d directories thread on this subject on ServerFault (the whole question is more suited for ServerFault rather that StackOverflow; please next time ask this kind of question there).

Configure Nginx to proxy pass to Gunicorn (working when I visit IP, not working when I visit domain name)

I am trying to configure Nginx to proxy pass to Gunicorn.
My django project can be found at /home/justin/project/jobzumo
Start by creating and opening a new server block in Nginx’s sites-available directory:
sudo nano /etc/nginx/sites-available/jobzumo
Within this file I've entered the following:
server{
listen 80;
server_name 142.93.184.125;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/justin/project;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
}
When I go to 142.93.184.125 I see the default django rocket ship, so I think that means everything is working. However, when I go to 'jobzumo.com' (associated domain), I see the default 'Welcome to nginx!' page.
I know I have both the IP and domain name in my ALLOWED_HOSTS settings and have pointed the domain nameservers at my server. So, do I need to add this domain to this file? The tutorial I was following said either or should do the job. If adding the domain to this file is not what I have to do, can you mention that, so at least I know I'll have to start looking elsewhere. Thanks for any help.
You probably still have the default site in available sites in nginx which is causing the issue. I just had the same problem and the following two commands solved the issue:
sudo unlink /etc/nginx/sites-enabled/default
sudo service nginx restart
if you stopped your gunicorn daemon you might need to restart it and then run the second command above it should do the trick.

Serve static content through subdomain in nginx

I have some slate docs as website and would like to serve them on the internal server, through a subdomain as follows: internal-docs.mysite.com. For the record, accessing mysite.com shows the "nginx is running propertly" page.
I've created a config file with following path and name: /etc/nginx/sites-available/internal-docs.mysite.com:
server {
listen 80;
server_name internal-docs.mysite.com;
root /var/www/docs-internal;
index index.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
error_page 404 /404.html;
}
And of course, I've put the files in /var/www/docs-internal. And then I made a symlink to the uppershown config file in the /etc/nginx/sites-enabled dir:
internal-docs.mysite.com -> ../sites-available/internal-docs.mysite.com
Then I reload nginx -s reload but "this site can't be reached" error is what I get when accessing the URL.
The setup and configuration look correct to me (according to the guidelines I've followed), so that's why I'm in a dead end, sort of...
It seems you forgot the Listen directive. Try the following:
server {
listen 80;
server_name internal-docs.mysite.com;
root /var/www/docs-internal;
index index.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
error_page 404 /404.html;
}
If that does not work, check:
That Nginx user has read permission to the site content. For example if your Nginx user is www and you have root access, do the following:
# su www
$ cat /var/www/docs-internal/index.html
If that fails, ensure the location has correct ownership and permissions. Note that for a user to be able to browser a directory, that directory must have the execute bit for that user or user group.
That Nginx user has read permission on file ../sites-available/internal-docs.mysite.com. For example if your Nginx user is www and you have root access, do the following:
# su www
$ cat /etc/nginx/sites-available/internal-docs.mysite.com
If that fails, ensure that the config files have correct ownership. Note: normally Nginx master process is run by root, and that process spawns sub-processes run as Nginx user, so permissions on config files are unlikely to be the problem.
That maybe your config file name should end with ".conf" (on my server I have the following line: include conf.d/*.conf; so it will NOT load any conf file ending with ".com".
That Nginx tries to load files in ../sites-available/ in its main config file. Maybe it does not and looks instead in the conf.d directory (the default).
That you can do a ping and nslookup on the subdomain. If you cannot, then you have to fix that first (DNS, firewall...).
For the sake of others - the configuration I wrote was correct, and my problem was in 2 things:
I had to remove the listen 80 directive, since there is another configuration file already, that specifies that nginx should listen on port 80. One should not tell nginx twice to listen on the same port, even if it's in two separate configuration files
Permissions on the /var/www/docs-internal folder. Opening a folder requires x (execute) permissions, while opening a file requires r (read) perm. I had to provide the according permissions to all the folders in this hierarchy, so that the content could be open globally (from everyone), which is basically accessing it from the browser.

DSM6 : Configure Nginx for Wordpress permalinks (avoid 404)

With the Synology DSM6 update, we have now to use Nginx instead of Apache. By default Nginx configuration don't allow wordpress permalinks (generate 404).
I read the idea was to transform the /uri in /?p=$uri and put this configuration in the "location" section of the server nginx config.
Where to put this configuration in DSM6 exactly ?
Have you tried the user config? Just copy your working:
/etc/nginx/app.d/server.webstation-vhost.conf
to:
/usr/local/etc/nginx/sites-enabled/httpd-vhost.conf-user
and rename the server.webstation-vhost.conf to server.webstation-vhost.conf.old or something and restart nginx (nginx -s reload)
Or better yet, remove your virtual host(s) from webstation. Only thing is you need to manually update your SSL certs when they expire instead of using the web interface.
Actually, you can add custom directives easily, without modifying the DSM behavior.
Take a look at the content of /usr/local/etc/nginx/sites-enabled/httpd-vhost.conf-user, to see where the custom configuration has to be stored:
server {
[...]
server_name NAME
[...]
include /usr/local/etc/nginx/conf.d/778943ad-0dc4-40ae-bb7f-7b2285e3203b/user.conf*;
}
Then, you just have to create the file /usr/local/etc/nginx/conf.d/778943ad-0dc4-40ae-bb7f-7b2285e3203b/user.conf.wordpress-permalink with the following content:
location /{
try_files $uri $uri/ /index.php?$args;
}
and restart nginx:
synoservicecfg --restart nginx
It will not break the future DSM update (since it is a supported customization)

How to configure .ebextensions for nginx location directive?

I want to configure my staging environment in Elastic Beanstalk to always disallow all spiders. The nginx directive would look like this:
location /robots.txt {
return 200 "User-agent: *\nDisallow: /";
}
I understand that I would want to create a file under the .ebextensions/ folder, such as 01_nginx.config, but I'm not sure how to structure the YAML inside it such that it would work. My goal is to add this location directive to existing configuration, not have to fully replace any existing configuration files which are in place.
There is an approach which uses the more recent .platform/nginx configuration extension on Amazon Linux 2 (as opposed to older AMIs).
The default nginx.conf includes configuration partials in two locations of the overall nginx.conf file. One is immediately inside the http block, so you can't place additional location blocks here, because that's not syntactically legal. The second is inside the server block, though, and that's what we need.
This second location's partial files are included from a special sub-directory, .platform/nginx/conf.d/elasticbeanstalk. Place your location fragment here to add location blocks, like so:
# .platform/nginx/conf.d/elasticbeanstalk/packs.conf
location /packs {
alias /var/app/current/public/packs;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
I wanted to do the same thing. After a lot of digging, I found 2 ways to do it:
Option 1. Use an ebextension to replace the nginx configuration file with your custom configuration
I used this option because it is the simplest one.
Following the example given by Amazon in Using the AWS Elastic Beanstalk Node.js Platform - Configuring the Proxy Server - Example .ebextensions/proxy.config, we can see that they create an ebextension that creates a file named /etc/nginx/conf.d/proxy.conf. This file contains the same content as the original nginx configuration file. Then, they delete the original nginx configuration file using container_commands.
You need to replace the Amazon example with the contents of your current nginx configuration file. Note that the nginx configuration files to be deleted in the containter command must be updated too. The ones I used are:
nginx configuration file 1: /opt/elasticbeanstalk/support/conf/webapp_healthd.conf
nginx configuration file 2: /etc/nginx/conf.d/webapp_healthd.conf
Therefore, the final ebextension that worked for me is as follows:
/.ebextensions/nginx_custom.config
# Remove the default nginx configuration generated by elastic beanstalk and
# add a custom configuration to include the custom location in the server block.
# Note that the entire nginx configuration was taken from the generated /etc/nginx/conf.d/webapp_healthd.conf file
# and then, we just added the extra location we needed.
files:
/etc/nginx/conf.d/proxy_custom.conf:
mode: "000644"
owner: root
group: root
content: |
upstream my_app {
server unix:///var/run/puma/my_app.sock;
}
log_format healthd '$msec"$uri"'
'$status"$request_time"$upstream_response_time"'
'$http_x_forwarded_for';
server {
listen 80;
server_name _ localhost; # need to listen to localhost for worker tier
if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2})") {
set $year $1;
set $month $2;
set $day $3;
set $hour $4;
}
access_log /var/log/nginx/access.log main;
access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;
location / {
proxy_pass http://my_app; # match the name of upstream directive which is defined above
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /assets {
alias /var/app/current/public/assets;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
location /public {
alias /var/app/current/public;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
location /robots.txt {
return 200 "User-agent: *\nDisallow: /";
}
}
container_commands:
# Remove the default nginx configuration generated by elastic beanstalk
removeconfig:
command: "rm -f /opt/elasticbeanstalk/support/conf/webapp_healthd.conf /etc/nginx/conf.d/webapp_healthd.conf"
Once you deploy this change, you have to reload the nginx server. You can connect to your server using eb ssh your-environment-name and then run sudo service nginx reload
Option 2. Use an ebextension to modify the nginx configuration file generator, so that it includes your custom locations in the final nginx configuration file
The second option is based on this post: jabbermarky's answer in Amazon forums
He explains this method very well in his answer, so I encourage you to read it if you want to implement it. If you are going to implement this answer, you need to update the location of the nginx file configuration generator.
Note that I have not tested this option.
In summary, he adds a shell script to be executed before the nginx configuration file is generated. In this shell script, he modifies the nginx configuration file generator to include the server block locations he wants in the generated nginx configuration file. Finally, he adds a file containing the locations he wants in the server block of the final nginx configuration file.
It seems that the mentioned approaches dont work anymore. The new approach is to place nginx .conf files into a subfolder in .ebextensions:
You can now place an nginx.conf file in the .ebextensions/nginx folder to override the Nginx configuration. You can also place configuration files in the .ebextensions/nginx/conf.d folder in order to have them included in the Nginx configuration provided by the platform.
Source
This does not require a restart of nginx either as Elastic Beanstalk will take care of that.
Mmmmm! .ebextensions!
You're probably easiest off creating a shell script to change your configuration, and then running that. Don't really know nginx, but try something along the lines of:
files:
"/root/setup_nginx.sh" :
mode: "000750"
owner: root
group: root
content: |
#!/bin/sh
# Configure for NGINX
grep robots.txt <your_config_file> > /dev/null 2>&1
if [ $? -eq 1 ] ; then
echo < EOF >> <your_config_file>
location /robots.txt {
return 200 "User-agent: *\nDisallow: /";
}
EOF
# Restart any services you need restarting
fi
container_commands:
000-setup-nginx:
command: /root/setup_nginx.sh
I.e. first create a schell script that does what you need, then run it.
Oh, and be careful there are no tabs in your YAML! Only spaces are allowed... Check the log file /var/log/cfn_init.log for errors...
Good luck!
For version Amazon Linux 2 use this path on your bundle and zip this foldes together
.platform/nginx/conf.d/elasticbeanstalk/000_my_custom.conf
This is what's working for me:
files:
"/etc/nginx/conf.d/01_syncserver.conf":
mode: "000755"
owner: root
group: root
content: |
# 10/7/17; See https://github.com/crspybits/SyncServerII/issues/35
client_max_body_size 100M;
# SyncServer uses some http request headers with underscores
underscores_in_headers on;
# 5/20/21; Trying to get the load balancer to respond with a 503
server {
listen 80;
server_name _ localhost; # need to listen to localhost for worker tier
location / {
return 503;
}
}
container_commands:
01_reload_nginx:
command: pgrep nginx && service nginx reload || true
To fix this - you need to wrap your configuration file. You should have, if you're using Docker, a zip file (mine is called deploy.zip) that contains your Dockerrun.aws.json. If you don't - it's rather easy to modify, just zip your deploy via
zip -r deploy.zip Dockerrun.aws.json
With that - you now need to add a .platform folder as follows:
├── .platform
│   └── nginx
│   └── conf.d
│   └── custom.conf
You can name your custom.conf whatever you want, and can have as many files as you want. Inside custom.conf, you simply need to place the following inside
client_max_body_size 50M;
Or whatever you want for your config. With that - modify your zip to now be
zip -r deploy.zip Dockerrun.aws.json
And deploy. Your Nginx server will now respect the new command
This is achievable using .ebextension config files, however I'm having difficulty kicking nginx to restart after a change to its configuration files.
# .ebextensions/nginx.config
files:
"/etc/nginx/conf.d/robots.conf":
mode: "000544"
owner: root
group: root
content: |
location /robots.txt {
return 200 "User-agent: *\nDisallow: /";
}
encoding: plain
Now, I've done similar to add a file to kick the nginx tyres, however for some odd reason it's not executing:
"/opt/elasticbeanstalk/hooks/appdeploy/enact/03_restart_nginx.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
. /opt/elasticbeanstalk/containerfiles/envvars
sudo service nginx restart
ps aux | grep nginx > /home/ec2-user/nginx.times.log
true
encoding: plain

Resources