Getting following error in NGINX server, Using LetsEncrypts free SSL Certificate.
2016/06/23 19:53:13 [warn] 5013#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2016/06/23 19:53:13 [emerg] 5013#0: BIO_new_file("/etc/letsencrypt/live/abc/fullchain.pem") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/abc/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)
Both problems have one root cause.
This error usually happens, when you try to start nginx with non-root user. You could try to start as root or under sudo.
Looks like you have permission on your pem file, which not allow nginx to read it when you start it from non-root user, you could try to change file permission or start nginx as root or under sudo.
Hello I also had the same similar issue.
setenforce 0
It was solved this way.
If your chmod and chown is all correct on the file, this is probably because you copied a file into a folder - maybe home folder (say) - then mv'd the file into position for NGINX. SeLinux remembers the original file creation location and applies the rights wherever the file is mv'd to - to reset the SeLinux permissions to the current location/file permissions use
restorecon filename
This usually sorts it
If you run nginx worker process from www-data user, it needs just set rights on /etc/letsencrypt/ folder:
chown -R www-data:www-data /etc/letsencrypt/
chmod -R 755 /etc/letsencrypt/
It should works
In my case(Oracle Linux 8), similar issue resolved after changing contexts of .pem files.
$ chcon -t httpd_sys_content_t *.pem
In my case, I solved it by copying the files to the /etc/ssl/certs/ folder and changing the path in nginx.conf
Related
Problem
I am confused about rsync daemon and permissions. Unfortunately I cannot figure out why I get
rsync: opendir "/." (in share) failed: Permission denied (13) and
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1650) [generator=3.1.2].
Obviously, by searching the web and looking into the manpage of rsync / rsyncd.conf I was not able to solve this issue.
Setup
Here is my /etc/rsyncd.conf owned by root with 644 permissions:
log file = /var/log/rsyncd.log
[share]
comment = data
path = /path/to/data
uid = root
gid = root
read only = false
auth users = syncuser
secrets file = /etc/rsyncd.secrets
Note, /path/to/data is owned by root with 755 permissions (though random user or syncuser is also not working).
Besides, /etc/rsyncd.secrets has 600 permissions and is owned by root (I also tried 400 though same issue)
syncuser:passwd
To start the service (on CentOS7)
sudo systemctl start rsyncd
A first test as a random user on the host machine running the daemon, (also running with sudo or as syncuser has no effect)
rsync user#host::
returns share data showing that the configuration is fine?!
However
rsync user#host::share
leads to the errors mentioned above.
Tries
Playing with chmod (777) and chown (root:root, random user:user, syncuser:syncuser) of /path/to/data was not changing anything. Moreover I varied uid and gid to nobody but also without success.
Running above rsync command on an actual client, from which I want to ultimately copy data to the host is of course also failing.
So what am I missing here? Any hints are of course highly appreciated.
could you check SELinux?
If it is enforced, the directory /path/to/data need to be labeled correctly.
For example,
chcon -R -t public_content_t /path/to/data
My server uses Let's Encrypt to get its TLS certificate to serve over HTTPS.
I'm electing to use the standard net/http package over Apache or nginx, so I used the webroot installation method, and it placed the cert files in /etc/letsencrypt/live/mysite.
The issue is that the live directory is only accessible by the root user. My golang program requires the certs in this directory to function and serve over HTTPS.
However for obvious reasons I'm not running my program as the root user.
So that leads me to wonder: how do I access these files without having to insecurely run my web server as root permanently?
You have few options:
sudo chown -R your-user /etc/letsencrypt/live/mysite
Or
sudo cp -a /etc/letsencrypt/live/mysite ./ssl/ && sudo chown -R your-user ./ssl/
Or
Use a container for your app and copy your app and the certs to it, and since it will be running as root inside the container, it won't matter.
So I just recently downloaded Apache server with all of its files (httpd, apr, apr-util, pcre) following the instructions dictated here: http://httpd.apache.org/docs/2.4/install.html
However, after set-up, when I tried to start my Apache server, which is located in my usr/local/bin/, I was prompted with this message:
[allen#allen-lnx ~]$ /usr/local/bin/apachectl start
(13)Permission denied: AH00091: httpd: could not open error log file /usr/local/logs/error_log.
AH00015: Unable to open logs
After some research, I have found that I need to edit my httpd.conf file, which I did so earlier to allow for the correct ServerName and Listen options. However, I am unsure as to how to edit my conf file to allow for access to the "logs" directory.
Notably, the command will run when I use the "sudo" command, but I would prefer to not always use that since it seems like a work around.
Any help would appreciated. Thanks!
Edit: I've actually noticed that I may have two httpd.conf files, which is proving to be a little troublesome. The other one is located in my root /etc/ directory (etc/httpd/conf/httpd.conf). I think my modified question now is... which one should I be keeping? Is the /etc/ version the one that is built in, as indicated by faff's comment below?
Current Solution: I figured I would just accept the fact that I need to use sudo when editing this file since I need to be root. I might change it later so that I'm always running as root, but for now, sudo will suffice.
This looks like an issue with he filesystem permissions. Make sure the /usr/local/logs/ directory exists and is writeable by the user you're running Apache as.
If you don't want to have your logs directory writeable by normal user, you can create the log file:
sudo touch /usr/local/logs/error_log
And then change the owner of the file to the correct user:
sudo chown allen /usr/local/logs/error_log
Assuming you want to run Apache as the user allen.
If you want to change the location of Apache logfile, look for the ErrorLog directive in your httpd.conf file (you will have to add it if it's not there):
ErrorLog path/to/logfile
For everyone that is using SELinux, if you deleted the folder or come across similar problems you may need to do several things.
Re-link the folder with ln -s /var/log/httpd /etc/httpd/logs
By default logs are kept under the var folder but are referenced in the /etc/httpd/logs folder
Apply SELinux security permissions with chcon system_u:object_r:httpd_config_t:s0 /etc/httpd/logs
And of course run everything as admin
Changing SELinux security policy to permissive fixed my problem.
Before fix my SELinux worked with enforced mode:
$ sestatus -v
sestatus -v
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 30
I changed security policy in SELinux configuration file and in the system.
#/etc/selinux/config
SELINUX=permissive
# In terminal set SELinux to run in permissive mode.
$ setenforce 0
After fix my SELinux worked with enforced mode:
$ sestatus -v
SELinux status: enabled
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 30
For those who are stuck with the SElinux policies, I was able to do it by creating a custom policy
Basically I wanted to move the /var/log/httpd to my own directory under /r/
So I run the following
semanage fcontext -a -t httpd_sys_content_t "/r/www(/.*)?"
semanage fcontext -a -t httpd_log_t "/r/logs(/.*)?"
restorecon -Rv /z/logs/
restorecon -Rv /z/www/
service httpd restart
# worked
I am trying to connect to a Centos 6.3 Server using an SSH Key so I can run a script remotely without it asking for a password everytime. I have followed the following instructions:
Login to the server using the normal ssh command and password one time so the server adds your computer to the known hosts
In your computer using cygwin-terminal generate the keys and leave the passphrase blank:ssh-keygen -t rsa
Now set permissions on your private key and ssh folder:chmod 700 ~/.ssh & chmod 600 ~/.ssh/id_rsa
Copy the public key (id_rsa.pub) to the server, login to the server and add the public key to the authorized_keys list: cat id_rsa.pub >> ~/.ssh/authorized_keys
Once you've imported the public key, you can delete it from the server. Set file permissions on the server: chmod 700 ~/.ssh & chmod 600 ~/.ssh/authorized_keys
Retart the ssh daemon on the server: service sshd restart
Test the connection from your computer:ssh root#198.61.220.107
But when I try to ssh to the remote server it is still asking me for the password. The .ssh folder was not created on the server so I had to created myself. Any ideas of what might be happening? did I miss something? Is there another way to set up the keys?
Well it turns out I had stupidly changed the owner of the /root directory when I was setting up the server so since this is where the /.ssh directory was for the user I was trying to loggin with (root) it was denying access to that directory because it belonged to another user.
Dec 10 16:25:49 thyme sshd[9121]: Authentication refused: bad ownership or modes for directory /root
I changed the owner back to root and that did it.
chown root /root
Thanks guys for you help.
Apparently this is a known bug. The suggested solution doesn't actually work, but I found that this would on a CentOS 6.2 system at work:
chmod 600 .ssh/authorized_keys
chmod 700 .ssh
Althogh OP had found a solution, I would like to record my solution of similar problem in the hope that it will be helpful to those who google similar problem and reach this answer.
The reason of my issue is that the .ssh directory in the user's home folder on CentOS server was not set a proper mode after being created by useradd command.
In addition, I need to manually set .ssh folder mode by following commands:
chmod g-w /home/user
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/authorized_keys
Other answers are generic, note that Centos 6 uses selinux. selinux can deny access to the authorised_keys file despite correct permissions and ownership
From the known issues in Centos 6 Release Notes:
Make sure that you setup correctly the selinux context of the public key if you transfer it to a CentOS 6 server with selinux
enabled. Otherwise selinux might forbid access to the
~/.ssh/authorized_keys file and by matter of consequence key
authentication will not work. In order to setup the correct context
you can use:
restorecon -R -v /home/user/.ssh
ssh-copy-id from CentOS 6 is aware of selinux contexts and the previous workaround is not needed.
I have installed apache webserver apache in linux ,I used following code to upload a file, but i get permission denied
scp -i adjmp.pem index.html ec2-user#ec2-50-17-88-33.compute-1.amazonaws.com:/var/www/html/hi
How can i upload a file to EC2 ?
You most likely need to change the filesystem permissions. This is usually done using the chmod command. You may also need to modify file ownership (using the chown command).
If you need help with the exact steps, you can provide the output of the following two commands and I will try to help:
sudo ls -al /var/www/html/hi
id