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.
Related
I'm using Mac. I used ps -ef | grep nginx which returned the following result.
$ ps -ef | grep nginx
0 74428 1 0 3:44PM ?? 0:00.01 nginx: master process nginx -c /usr/local/etc/nginx/nginx.conf
-2 74483 74428 0 3:47PM ?? 0:00.00 nginx: worker process
501 75545 75489 0 4:31PM ttys003 0:00.00 grep nginx
Does it mean the Nginx is running? Is there any other reliable way to check if Nginx is running?
Additionally, does nginx restart automatically every time the machine restarts?
If you installed nginx with Homebrew, you can use:
brew services info nginx
You will get a similar output:
nginx (homebrew.mxcl.nginx)
Running: ✔
Loaded: ✔
Schedulable: ✘
User: user
PID: 78476
The output you provided shows that nginx is indeed running on your Mac.
The first line with the user "root" (0) and process ID "74428" is the master process for nginx.
The second line with the process ID "74483" is a worker process.
The last line is the "grep nginx" command you used to find the nginx processes.
Question 1: Is Nginx running?
Yes, the output you get indicates that Nginx is currently running on your mac.
The first line in the output shows the master process with PID 74428 and the second line shows a worker process with PID 74483.
Question 2: Other ways to find out if Nginx is running.
Use the command nginx -t which will test the configuration files for syntax errors.
If the configuration is valid, it will display the message "nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful."
Using the command netstat -an | grep 80 to check if a process is listening on port 80, which is the default port for Nginx.
Using the command lsof -i :80 to check if any process is using port 80.
By using the command sudo nginx -s status that will give you the status of Nginx.
Third party tools like Nagios (open-source).
Question 3: Does nginx restart automatically every time the machine restarts?
By default, Nginx does not automatically start at boot time on macOS, so it will not automatically restart after a machine restart. You can use launchd or launchctl to set up Nginx as a service so that it starts automatically on boot.
If you wish to do so. 2 ways.
Create a launchd plist file and use launchctl command to load it.
Create a plist file called nginx.plist in the directory /Library/LaunchDaemons/ with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>nginx</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/nginx</string>
<string>-g</string>
<string>daemon off;</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>UserName</key>
<string>_www</string>
<key>GroupName</key>
<string>_www</string>
<key>StandardErrorPath</key>
<string>/var/log/nginx/error.log</string>
<key>StandardOutPath</key>
<string>/var/log/nginx/access.log</string>
</dict>
</plist>
Yoiu might have to change the path inside the element.
Load the plist file using the launchctl command :
sudo launchctl load /Library/LaunchDaemons/nginx.plist
Use the command "launchctl list | grep nginx" to verify that Nginx is running.
To remove the plist file and stop Nginx from starting automatically on boot:
sudo rm /Library/LaunchDaemons/nginx.plist
If you have used Homebrew to install Nginx you could you the following commands
brew services info nginx // status answer to question 2
brew services start nginx // start Nginx
brew services enable nginx // configure Nginx to start automatically on boot
brew services list // verify that Nginx is set to automatically run on boot
brew services stop nginx // stop Nginx
brew services disable nginx // remove the service so not to run Nginx on boot
ps aux | grep nginx
nginx -t to test for config files
sudo lsof -i :80. (check for ngnix in the list using grep command)
sudo service nginx status
I'm setting up our Gitlab server and it works well when I disabled the seLinux.
How to fix the configuration of the seLinux to allow the gitlab work?
Environmnt:
CentOS 7.4.1708 and update all packages.
Gitlab 10.5.2
nginx 1.13.10
I've installed Gitlab and nginx and followed this link to configure to make the Gitlab work with installed nginx:
https://docs.gitlab.com/omnibus/settings/nginx.html#using-a-non-bundled-web-server
When I clicked the link to the Gitlab, I could not reach there and I found error message in /var/log/nginx/error.log:
2018/04/05 11:39:27 [crit] 4092#4092: *3 connect() to unix:/var/opt/gitlab/gitlab-workhorse/socket failed (13: Permission denied) while connecting to upstream, client: xx.xx.xx.xx, server: localhost, request: "POST /gitlab/api/v4/jobs/request HTTP/1.1", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/socket:/gitlab/api/v4/jobs/request", host: "xx.xx.xx.xx"
After I changed the seLinux to 'permissive' mode, it worked well as expected.
And in the /var/log/audit/audit.log file, I found the message:
type=AVC msg=audit(1522905628.444:872): avc: denied { write } for pid=12407 comm="nginx" name="socket" dev="dm-2" ino=8871 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=sock_file
Then I tryed to follow the instruction below:
https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache#selinux-modifications
but I cannot see the files/directories in it.
setsebool -P httpd_can_network_connect on
setsebool -P httpd_can_network_relay on
setsebool -P httpd_read_user_content on
semanage -i - <<EOF
fcontext -a -t user_home_dir_t '/home/git(/.*)?'
fcontext -a -t ssh_home_t '/home/git/.ssh(/.*)?'
fcontext -a -t httpd_sys_content_t '/home/git/gitlab/public(/.*)?'
fcontext -a -t httpd_sys_content_t '/home/git/repositories(/.*)?'
EOF
restorecon -R /home/git
git user's home directory is /var/opt/gitlab instead of /home/git
/var/opt/gitlab directory has no gitlab directori or repositories directory.
How can I configure the seLinux to work with my environment?
I'm currently figuring this out. The documentation is a mix of old and new info and lacks distinction between the standard and "Omnibus" install. The problem is they don't label their socket file properly to allow access by Nginx. I've had success running this after every time I run gitlab-ctl reconfigure:
chcon -t httpd_var_run_t /var/opt/gitlab/gitlab-workhorse/socket
And also don't forget these bits of setup:
usermod -aG git,gitlab-www nginx
chmod g+rx /var/opt/gitlab/
chown git:git /var/opt/gitlab
As well, I couldn't get Nginx to start with the provided config; I had to create a proxy cache directory:
mkdir /usr/share/nginx/proxy_cache
restorecon -vFR /usr/share/nginx
chown nginx /usr/share/nginx/proxy_cache/
Just had this issue myself (I'm even also using a CentOS server) and was able to solve it using the command posted by miken32
chcon -t httpd_var_run_t /var/opt/gitlab/gitlab-workhorse/socket
In my case I installed the Omnibus gitlab-ce package using the docs provided by Gitlab
Afterwards I followed the instructions for Using a non-bundled web-server. If you read carefully you'll notice the 5. Download the right web server configs paragraph that contains a link GitLab recipes repository.
Follow this link and you will find the configs for multiple different web server including the ones for nginx. Be careful since within the nginx web server directory you will be redirected to the GitLab official repository again...
Download the required config (with or without SSL etc.) into the /etc/nginx/conf.d/ directory (this is special for at least CentOS). Carefully inspect the downloaded file since you will need to modify it with correct paths for the Omnibus package.
Also don't forget to give nginx access to git group as mentioned in the documentation. I'm not sure if really necessary but my nginx user is also member of the gitlab-www group.
After all this I was still unable to launch the gitlab site. The browser just showed up with the 502 error page.
The /var/log/nginx/gitlab-error.log showed a permission denied error for the workhorse socket which lead me to this page and can be solved (at least in my case) with the command provided by miken32.
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.
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.
So I want to be able to cap:deploy without having to type any passwords. I have setup all private keys so I can get to the remote servers fine, and am now using svn over ssh, so no passwords there.
I have one last problem, I need to be able to restart nginx. Right now I have sudo /etc/init.d/nginx reload. That is a problem b/c it uses the capistrano password, the one I just removed b/c I am using keys. Any ideas on how to restart nginx w\out a password?
I just spent a good hour looking at sudoer wildcards and the like trying to solve this exact problem. In truth, all you really need is a root executable script that restarts nginx.
Add this to the /etc/sudoers file
username hostname ALL=NOPASSWD: /path/to/script
Write script as root
#! /bin/bash
/bin/kill -HUP `cat /var/run/nginx.pid`
Make the script executable
Test.
sudo /path/to/script
There is a better answer on Stack Overflow that does not involve writing a custom script:
The best practice is to use /etc/sudoers.d/myusername
The /etc/sudoers.d/ folder can contain multiple files that allow users
to call stuff using sudo without being root.
The file usually contains a user and a list of commands that the user
can run without having to specify a password.
Instructions:
In all commands, replace myusername with the name of your user that you want to use to restart nginx without sudo.
Open sudoers file for your user:
$ sudo visudo -f /etc/sudoers.d/myusername
Editor will open. There you paste the following line. This will allow that user to run nginx start, restart, and stop:
myusername ALL=(ALL) NOPASSWD: /usr/sbin/service nginx start,/usr/sbin/service nginx stop,/usr/sbin/service nginx restart
Save by hitting ctrl+o. It will ask where you want to save, simply press enter to confirm the default. Then exit out of the editor with ctrl+x.
Now you can restart (and start and stop) nginx without password. Let's try it.
Open new session (otherwise, you might simply not be asked for your sudo password because it has not timed out):
$ ssh myusername#myserver
Stop nginx
$ sudo /usr/sbin/service nginx stop
Confirm that nginx has stopped by checking your website or running ps aux | grep nginx
Start nginx
$ sudo /usr/sbin/service nginx start
Confirm that nginx has started by checking your website or running ps aux | grep nginx
PS: Make sure to use sudo /usr/sbin/service nginx start|restart|stop, and not sudo service nginx start|restart|stop.
Run sudo visudo
Append with below lines (in this example you can add multiple scripts and services after comma)
# Run scripts without asking for pass
<your-user> ALL=(root) NOPASSWD: /opt/fixdns.sh,/usr/sbin/service nginx *,/usr/sbin/service docker *
Save and exit with :wq
Create a rake task in Rails_App/lib/capistrano/tasks/nginx.rake and paste below code.
namespace :nginx do
%w(start stop restart reload).each do |command|
desc "#{command.capitalize} Nginx"
task command do
on roles(:app) do
execute :sudo, "service nginx #{command}"
end
end
end
end
Then ssh to your remote server and open file
sudo vi /etc/sudoers
and the paste this line (after line %sudo ALL=(ALL:ALL) ALL)
deploy ALL=(ALL:ALL) NOPASSWD: /usr/sbin/service nginx *
Or, as in your case,
deploy ALL=(ALL:ALL) NOPASSWD: /etc/init.d/nginx *
Here I am assuming your deployment user is deploy.
You can add here other commands too for which you dont require to enter password. For example
deploy ALL=(ALL:ALL) NOPASSWD: /usr/sbin/service nginx *, /etc/init.d/mysqld, /etc/init.d/apache2