I changed my sshd_config file to set strictmodes to no and then restarted the sshd service.
However, I am getting two different outputs as shown below.
root#localhost httpd]# service sshd stop
Stopping sshd: [ OK ]
[root#localhost httpd]# service sshd start
Starting sshd: [ OK ]
[root#localhost httpd]# sudo cat /etc/ssh/sshd_config | grep StrictModes
#StrictModes no
[root#localhost httpd]# sshd -T | grep strictmodes
strictmodes yes
The most of the configuration files have # as a comment and therefore the options behind it are not used and therefore your server is using its defaults, which is yes. Change the line in your sshd_config to
StrictModes no
and restart the service. It will be applied.
Related
so I've set up "PermitRootLogin no" in /etc/sshd_config and I have restarted the sshd service but the root user can still login via ssh.
Further investigation shows that the run-time config differs from the sshd_config file:
[root#CEBECOM-Hq5AT03 ~]# grep PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin no
[root#CEBECOM-Hq5AT03 ~]# service sshd restart
Redirecting to /bin/systemctl restart sshd.service
[root#CEBECOM-Hq5AT03 ~]# sshd -T |grep -i permitrootlogin
permitrootlogin yes
I also tried to restart the machine but still I can login with root...
Any idea?
Edit: I have some more info.
I found out that I have to put the PermitRootLogin before a Match directive in order for it to work:
# here it works
PermitRootLogin no
Match Group sFTP
ChrootDirectory /sftp/salsftp
ForceCommand internal-sftp
AllowTcpForwarding no
# here it doesn't work
# PermitRootlogin no
I can't find a reason why it behaves like this.
Ah ok I got it. From the sshd_config man page:
Match Introduces a conditional block. If all of the criteria on the
Match line are satisfied, the keywords on the following lines
override those set in the global section of the config file,
until either another Match line or the end of the file
So if I put the PermitRootlogin after the Match this will be considered as part of the Match configuration. Since root is not on the sFTP group then the PermitRootLogin directive was ignored.
I'm embarking on watching my NGINX error.log files at level: warn... probably a silly idea and will cause me to crash my server as I work out any bugs happening, but hey, we're nerds and this is why we're here.
I'm noticing a [warn] and an [emerg] pop up every time I restart my server, which shows:
[warn] 8041#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
[emerg] 8041#0: open() "/run/nginx.pid" failed (13: Permission denied)
The top of my nginx.conf file reads:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
Which to me, shows me a few things.
I'm running NGINX with the user: www-data.
The number of worker processes that are allowed is automatically adjusted.
my PID file/information is being stored in /run/nginx.pid.
The error tells me that NGINX doesn't have permission to access /run/nginx.pid, which led me to see the user permissions for said file.
sudo ls -la /run/nginx.pid
reveals:
-rw-r--r-- 1 root root 5 Jun 18 05:34 /run/nginx.pid
Then trying:
ps -ef | grep nginx
produces:
root 5914 1 0 05:34 ? 00:00:00 nginx: master process /u
www-data 5917 5914 0 05:34 ? 00:00:00 nginx: worker process
scratches head
Now, can somebody out there tell me why, or how the hell NGINX has managed to create the master process with root ownership, and now the worker processes are owned by www-data?
Or more to the point, anybody have some suggestions on what to do about this [emerg] error I'm getting?
My first thought is to just try and change the ownership of the /run/nginx.pid file and see how NGINX likes it, but I kind of feel that even if I do that manually this time, when I restart the server, I'll run into the same problem.
My second thought is maybe there is somewhere else that I define my worker process initiation within NGINX..
Thanks.
EDIT
The contents of the /etc/systemd/system/multi-user.target.wants/nginx.service file are:
[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=/usr/sbin/nginx -s quit
[Install]
WantedBy=multi-user.target
I got the same error on my Centos 7 server today.
nginx.pid" failed (13: Permission denied)
For me, it turned out to be a problem with SELinux. I did the following to make it work again:
systemctl stop nginx
touch /var/run/nginx.pid
chcon -u system_u -t httpd_var_run_t /var/run/nginx.pid
systemctl start nginx
running
ls -Z nginx.pid
should output
-rw-r--r--. root root system_u:object_r:httpd_var_run_t:s0 nginx.pid
In my case I got a
"/usr/local/var/run/nginx.pid" failed (13: Permission denied)
bind() to 0.0.0.0:80 failed (48: Address already in use)
and the working solution was made up of these steps:
stop root process
sudo nginx -s stop
check if process stopped
ps aux | grep nginx
restart process
sudo nginx -s reload
gave me the error
nginx: [error] open() “/usr/local/var/run/nginx.pid” failed (2: No such file or directory)
probabil .pid was started with the wrong root user as I uncommented the line with path to .pid in /usr/local/etc/nginx/nginx.conf and then I commented it back again
to start nginx as a user and not root
brew services start nginx
result at running command
ps aux | grep nginx
youruser 89212 0.0 0.0 4268280 644 s002 S+ 2:46PM 0:00.00 grep nginx
youruser 89179 0.0 0.0 4302204 1776 ?? S 2:45PM 0:00.00 nginx: worker process
youruser 89178 0.0 0.0 4275372 4368 ?? S 2:45PM 0:00.01 nginx: master process /usr/local/opt/nginx/bin/nginx -g daemon off;
And as it can be seen, the nginx process started with the expected user and not as root and the conflict between processes was gone and I could access the PHP application local domain.
For Ubuntu 20.04+
I got the exact same error while I was using sudo systemctl reload nginx
Using sudo service nginx restart instead throws no error
I'm having an application listening on port 8081 and Nginx running on port 8080. The proxy pass statement looks like:
$ cat /var/etc/opt/lj/output/services/abc.servicemanager.conf
location /api/abc.servicemanager/1.0 { proxy_pass http://localhost:8081;}
In nginx.conf, I include this file as:
include /etc/nginx/conf.d/services/*.conf;
The /etc/nginx/conf.d/service is a symlink:
# ll /etc/nginx/conf.d/
lrwxrwxrwx. 1 root root 39 Dec 10 00:19 services -> ../../../var/etc/opt/lj/output/services
This is a CentOS 7.0 SELinux Enabled system. If I setenforce 0, and make it Permissive, I don't see any issues. So the file is in right place and no issues with paths. If SELinux is enforcing, I see the following in audit log:
type=AVC msg=audit(1418348761.372:100930): avc: denied { getattr } for pid=3936 comm="nginx" path="/var/etc/opt/lj/output/services/abc.servicemanager.conf" dev="xvda1" ino=11063393 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=file
I want to know how to enable Nginx to find the conf file without having to disable SELinux.
Worth noting for beginners in SELinux that if your proxied service is running on 8080, you can use the command below without compiling a policy.
$ sudo setsebool httpd_can_network_connect 1 -P
Read about audit2allow and used it to create a policy to allow access to the denied requests for Nginx.
Step 1 involves running audit2allow targeting nginxlocalconf:
$ sudo grep nginx /var/log/audit/audit.log | \
grep denied | audit2allow -m nginxlocalconf > nginxlocalconf.te
Step 2, review results:
$ cat nginxlocalconf.te
module nginxlocalconf 1.0;
require {
type httpd_t;
type var_t;
type transproxy_port_t;
class tcp_socket name_connect;
class file { read getattr open };
}
#============= httpd_t ==============
#!!!! This avc can be allowed using the boolean 'httpd_can_network_connect'
allow httpd_t transproxy_port_t:tcp_socket name_connect;
allow httpd_t var_t:file { read getattr open };
Review steps to activate:
$ sudo grep nginx /var/log/audit/audit.log | grep denied | \
audit2allow -M nginxlocalconf
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i nginxlocalconf.pp
Step 3, active:
$ sudo semodule -i nginxlocalconf.pp
If you have another port or custom port allow it:
Show allow port in http:
semanage port -l | grep http
This is output in my localhost:
http_cache_port_t tcp 8080, 8118, 8123, 10001-10010
http_cache_port_t udp 3130
http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000
pegasus_http_port_t tcp 5988
pegasus_https_port_t tcp 5989
And allow 8081:
semanage port -a -t http_port_t -p tcp 8081
Always prefer changing types to creating custom policies. In this case, Nginx will serve files with the httpd_sys_content_t type. Assuming your files are located in /var/www:
semanage fcontext -a -t httpd_sys_content_t /var/www/*
restorecon -R -v /var/www
I need help figuring out the root cause of this permission denied error. What permissions does nginx need? Why is it so complicated?
the socket API bind() to a port less than 1024, such as 80 as your title mentioned, need root access.
here is "Bind to ports less than 1024 without root access"
and another easier way is to run nginx as root.
If you use a port bigger than 1024 with root privilege, but still got this problem, that's may be caused by SELinux:
Check this port, say 8024, in segange port
sudo semanage port -l | grep http_port_t
If 8024 doesn't exist in the port list, add it into segange port
sudo semanage port -a -t http_port_t -p tcp 8024
###update in 2017.12.22
Sometimes your SELinux is disabled, you need to enforcing it first. Check the status of SELinux by
$ sestatus
More steps can read this wonderful article: https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts
If see this msg after run "nginx -t", you dont have premission run as root "sudo nginx -t"
nginx needs root access. Just use
sudo nginx
next step along with your password
The best solution would be:
1) add user to sudoers ( my user is prod)
usermod -aG sudo prod
2) inside circus ( process manager ) append sudo before nginx executable, mine looks like this:
[watcher:nginx]
cmd = sudo /usr/sbin/nginx
args = -c /home/t/Projects/x_b_11/etc/nginx.conf -p /home/t/Projects/x_b_11
3) and finaly add line into file /etc/sudoers ( my user is prod). This line avoids error (sudo: no tty present and no askpass program specified). Probably need to restart session ( reboot). Enjoy.
prod ALL = NOPASSWD: /usr/sbin/nginx
Ubuntu uses AppArmor and not SELinux. The responses pointing to SELinux may not be that relevant to the OP.
For the others that Googled this: I also encountered this issue on a SELinux-enabled CentOS 7 machine. nginx would not bind port 80 and gave me error 13: permission denied despite having already run
setcap 'CAP_NET_BIND_SERVICE=+ep' /usr/sbin/nginx to allow the service to bind the port with a non-root user.
Temporarily setting SELinux to Permissive (sudo setenforce Permissive) allowed nginx to start. I then ran audit2allow -a which gave me
#============= httpd_t ==============
#!!!! This avc can be allowed using the boolean 'httpd_can_network_connect'
allow httpd_t ntop_port_t:tcp_socket name_connect;
Which meant the solution was to also run:
sudo setsebool -P httpd_can_network_connect on
After which you can set SELinux back to Enforcing (sudo setenforce Enforcing) and restart everything to verify.
I issued a nginx -s stop and after that I got this error when trying to reload it.
[error]: invalid PID number "" in "/var/run/nginx.pid"
That /var/run/nginx/pid file is empty atm.
What do I need to do to fix it?
nginx -s reload is only used to tell a running nginx process to reload its config. After a stop, you don't have a running nginx process to send a signal to. Just run nginx (possibly with a -c /path/to/config/file)
in my case I solved this by starting the service.
sudo /etc/init.d/nginx start
The command above will start the service in Debian/Ubuntu. It will issue an error if there is any problem (like Apache listening in the same port)
After that nginx -s reload will work like a charm
This will clear out the issue on ubuntu 16.04 and above
sudo service nginx stop
you may need to remove the pid file nginx.pid whose location may be defined in file /etc/nginx/nginx.conf look for line like
cat /etc/nginx/nginx.conf | grep pid # see if pid file is defined
this line may live in file /etc/nginx/nginx.conf
pid /run/nginx.pid; # in file /etc/nginx/nginx.conf
if pid file does exist then remove it now
ls -la /var/run/nginx/pid # this file may live elsewhere
ls -la /run/nginx.pid # on Ubuntu 16.04+
after the pid file has been removed lets launch nginx
sudo service nginx start
ps -eaf|grep nginx # confirm its running
sudo nginx -t && sudo nginx -s reload # confirm config is OK
# typical output
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful
sudo service nginx stop # issue stop
ps -eaf|grep nginx # confirm it actually stopped
now sanity has been restored and you are free to launch at will
In the latest version(1.2.0) that I downloaded there is no "-s start" option, it will say
nginx: invalid option: "-s start"
You can start nginx by
sudo /etc/nginx/sbin/nginx
The server will be started and then there wont be any Invalid pid number errors.
To avoid downtime with restarting nginx,
ps aux | grep nginx
PID of nginx master process
echo PID > /var/run/nginx.pid
nginx -s reload
In my case nginx was stopped (crashed I assume). Solved the issue by:
service nginx status
nginx stop/waiting
service nginx start
nginx start/running, process 3535
Then nginx -s reload worked like a charm.
I am using nginx/1.8.0 on trusty.
This happens if the nginx process was stopped manually or was killed.
Check if the process is still running:
sudo lsof -nP -iTCP:<port> | grep LISTEN
I am on mac, and I reinstall the nginx with:
brew reinstall nginx
Then start the service using brew:
brew services start nginx
On CentOS 7 I done it with this:
sudo systemctl start nginx
#Then check all things are OK
sudo systemctl status -l nginx
For anyone who still has issues, in my case, there was an apache2 server that was running.
You can try debugging what went wrong in your nginx machine by executing this command -
systemctl status nginx
This gave me an insight that the port was already in us by apache2 server.
so you can do sudo service apache2 stop and then do sudo service nginx start.
Docker Alpine users should use
nginx
by using that nginx will be start there is no error by
nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
then reload it by
nginx -s reload