How do I add SSH keys for 'apache' user in Linux?
BACKGROUND
I am trying to add a service hook to github to notify a URL once I push to my repo. I have the following php page set up:
<?php `git pull origin master`;
However I get the following output:
sh: git: Permission denied
This is because the keys I generated for github access were generated by my 'root' user. However when I exectue a command from php it is the 'apache' user that runs it.
The keys therefore do not correspond and permission is denied to pull.
As I cannot switch user from the terminal to generate keys as 'apache', I am not too sure what to do. Can anyone suggest a solution?
You may have to copy the root generated keys in the .ssh directory of your apache user.
Assuming the homedir of apache is /var/www (check /etc/passwd) and the named key is id_rsa-git :
mkdir -p /var/www/.ssh/
cp /root/.ssh/id_rsa-git /var/www/.ssh/id_rsa
No need to copy the public key.
Note : by default the key used are id_rsa or id_dsa. You may change the name of the copied key to match this.
You may also change ownership of the id_rsa key and .ssh directory:
chown -R apache:apache /var/www/.ssh
chmod 0700 /var/www/.ssh
chmod 0600 /var/www/.ssh/id_rsa
As you are root, you can try it sudo -u apache ssh-keygen -t rsa
Just posting the comment of #KitCarrau, under yvan's answer, that worked for me
sudo -u apache ssh-keygen -t rsa
for debian
sudo -u www-data ssh-keygen -t rsa
after this click Enter twice, to skip passphrase
also, it suggests to create the public/private keys in /var/www/.ssh directory, even if I had my www direcotry in /home/my_user/www, that is fine.
The existing answers are either incomplete or insecure. If you put your .ssh directory into the home directory of the apache user (/var/www) then this will also most likely serve the contents of that directory and thus expose your ssh private key to the public web. To prevent this you'd have to configure apache not to serve the .ssh directory but none of the existing answers explains how to do this.
I'd also argue that it is still dangerous to have your .ssh directory be a subdirectory of your publicly served www-root because even if you add a rule to your apache config, upgrading the server or doing unrelated other configurations might override this rule without you noticing.
So here is an answer that puts the key elsewhere, where it is not served by apache by default. There is not even the need to ever become the www-data user as others are struggling with.
First, find out the home directory of our apache user, for example by looking into /etc/passwd and looking for the www-data user or however the apache user of your distribution is called. The home directory is likely /var/www.
Then run (replacing /var/www with the home directory of the apache user on your setup):
$ mkdir "$HOME/www-data.ssh"
$ ssh-keygen -q -t rsa -f "$HOME/www-data.ssh/id_rsa" -N ""
$ chown -R www-data:www-data "$HOME/www-data.ssh"
$ mkdir /var/www/.ssh
$ cat << END > /var/www/.ssh/config
> Host *
> IdentityFile $HOME/www-data.ssh/id_rsa
> END
$ chown -R www-data:www-data /var/www/.ssh
Now your www-data user will use the ssh key in $HOME/www-data.ssh/id_rsa for all its ssh connections and since your $HOME is probably different from /var/www, that directory will not be served. So even without adding any custom rules to apache, users will be able to see your .ssh/config but they will not be able to access the private key it points to. Nevertheless, your www-data user will know how to do it.
I ran into a similar issue and there is one extra snag. In order to ssh using the apache user you also need to edit the /etc/passwd file so that the directive for apache has a shell defined.
In my case I needed to change
apache:x:48:48:Apache:/var/www:/sbin/nologin
to
apache:x:48:48:Apache:/var/www:/bin/bash
To add to #Vincent, if you have SELinux enabled, you'll have to set the context for the new .ssh folder.
On RHEL, add the following to this file: /etc/selinux/targeted/contexts/files/file_contexts.homedirs
/var/www/[^/]*/.+ system_u:object_r:user_home_t:s0
/var/www/[^/]*/\.ssh(/.*)? system_u:object_r:ssh_home_t:s0
And then run the command
# restorcon -Rv /var/www/
I don't know if this will work on redhat (I assume that is what you're running) however, I was able to su to www-data (the apache user for debian) by executing the following:
sudo su www-data
it actually worked shrugs go figure
Related
I have a PHP script application installed on a cloud server.
One of the function is the "PDF Preview", which is currently not working properly.
I contacted the PHP script owner, and he asked me to make sure:
1. dompdf/lib/font/ folder has write permissions (777)
2. the owner of the folder is the Apache user (mostly it is www-data)
For the 1st one, I tried to change the directory permission directly in the FileZilla interface. But it always changes back to 775 after I refresh...
For the 2nd one, I have no idea what it means... I contacted the technical support of my cloud server service. He said it's an App related issue, not server.
Can anyway give me some direction please? Should I use SSH? or anything else?
Really appreciated your help...
Erin
If you have SSH access, it is easier.
1) SSH in and CD into your web directory (likely public_html)
2) run the command chmod -R 777 dompdf/lib/font/
However permission 755 is likely fine...
3) Run ls -l. It will likely look like this:
-rw-r--r-- 1 erin erin 395 Aug 21 2013 index.php
The first 'erin' is the user and the second 'erin' is the group.
There may be other files that have the correct group (such as www or apache). Try and match other files in the public_html directory:
To change the owner: chown apache dompdf/lib/font/
To change the group: chgrp apache dompdf/lib/font/
If you're on shared hosting you might not have access to do this. I'm guessing it's more likely a path or configuration issue than a permissions issue, but give this a shot.
As far as I know you cannot change the owner of a file/directory via FTP. You can via SSH.
The command to change file permissions:
chmod 777 filename.php
To change a directory's permissions:
chmod -R 777 dirname/
To change the owner of a file:
chown www-data filename.php
To change the owner of a directory:
chown -R www-data dirname/
To change the group of a file:
chgrp www-data filename.php
To change the group of a directory:
chgrp -R www-data dirname/
Make sure you are in the file's directory when changing file permissions and ownership with the above commands. Otherwise you'll have to update the path.
If you are updating directories, be sure to be above the directory you wish to update.
Hope this helps.
P. S. To view the current permissions / owner / group of a file or directory, use the ls -la command.
Do not use the database user as the UNIX user. Use www-data.
sudo chown -R www-data:www-data /var/www
There is a difference between the database user and the Apache user. The Apache User is the only one who can actually read the files. The database user is only meant for giving/taking database read/write permissions.
In addition, keep the default permissions from the webapp install. Do not change those, except for the owning user/group. If you are instructed by the webapp, change permissions.
If you are more concerned about security, you could instead run the following commands:
sudo chown -R $USER:www-data /var/www
sudo chmod -R 640 /var/www
This makes the actual files owned by your user, so that only you (and root) can modify them. The reason www-data is referenced is so that Apache can still READ the files, but not actually write to them.
The 640 allows you (the file owner) to read and write, while allowing the www-data group to read files. It also blocks anyone else from possibly reading the file contents.
(The above is only one possible (untested) method. More good ways are available here.)
My PHP runs "exec" under the user "www-data"
my git repository is owned by "admin"
so it cannot access.
If I change ownership to "www-data" it passes the access problem but I can't create SSH keys because www-data is not a "real" user. I don't even know what that is. where is the home folder for such user?
also, when i change the ownership to "www-data" I cannot use git as admin on that machine anymore. gives me error: cannot open .git/FETCH_HEAD: Permission denied
Where is the home fold for user www-data ?
how can I get it to be able to use git with SSH keys set up?
Transferring ownership to www-data is the right decision. I mean www-data is indeed the owner and since it needs full read/write permissions to that folder anyway - do it!.
The following information is at least true for Debian based systems
www-data is a real user. Also it has a home dir. You can find it using:
cat /etc/passwd | awk -F: '/www-data/{print $6}'
On Debian/Ubuntu it is /var/www for example.
To make the github access possible you can create keys for www-data and place them in /var/www/.ssh. !!!Make sure that this folder is not accessible from web!!!. Then create a machine-user on github add use the public key for www-data.
Creating the keys:
sudo -u www-data ssh-keygen -t rsa
Once you are finished, create a new user on github, name it your-app-machine-user (or whatever), copy /var/www/.ssh/id_rsa.puband add it to that github account.
Read access for www-data should work now.
Try: chown -R www-data:www-data .git/
My PHP application and all the files are owned by www-data however I am currently logged in to the server using my username ruser. I'm developing on the same machine so everytime I want to test changes to my php code I have to go back and forth between file owners.
Is this the best practice or is there a different way I can set this up to make my development smoother?
Make your user part of the www-data group, or make the www-data user part of your group. Then give group access to your files:
usermod -a -G www-data yourusername
In terms of best practice, you should be developing on a different machine anyway. Then deploy your code and use scripts to set up whatever secure configuration is right for your project.
There are a few options open to you.
1) You can change all the files to the www-data group while keeping them owned by you
from your site's root directory run:
chmod -R ruser:www-data ./*
2) The best method is to set up an ACL if your distribution supports it: http://bit.ly/Lat25d
3) Or the simplest method (on a dev machine only - don't do this on a live server) is to chmod everything to 777 from the site's root directory
chmod -R 777 ./*
You can change the files to be owned by any user, i.e use the following command: chown username:groupname file.php
Only require Apache to own the files if Apache is going to write to the files or overwrite the files.
So change the ownership to the FTP user to avoid constant ownership changes.
I just moved magento from local to server and Im getting the following error, I was just wondering if someone could help me solve this,
UID of script "/home/.../public_html/index.php" is smaller than min_uid
what I did was to make a database dump and transfer it to server,
create a backup of the all the magento files and transfer and expand to server,
change the core_config table in the database.
Thanks in advance.
That looks like an suPHP issue to me.
Change the user and group of your script to the user running your webserver process. So if you're running an Apache with user www-data for example, change to:
chown www-data:www-data /home/.../public_html/index.php
Or change all your files at once by:
chown -R www-data:www-data /home/.../public_html/
If you're still running into this issue after changing user and group, then your suPHP is probably working with the default min_uid = 100, but the UID of www-data is below this 100.
To fix this you can change the min_uid in suPHP's config to match the UID of www-data:
vi /etc/suphp/suphp.conf
min_uid = <UID of www-data>
If your script is owned by root, you should change the ownership back to yourself:
chown -R user /home/user/public_html
This will change the owner of all of the files contained in /home/user/public_html and all subdirectories to user.
I had same problem, and fixed it with logged in Ftp and uploaded files with cpanel account of this site. Not root or admin account. You must create or edit your files with this account.
What I did to fix this problem:
chown -R user:user /home/dibs/public_html
and made the php files to chmod 700
as far as i am getting just disable the suPHP mode in apache2,
by typing this command on terminal :
sudo a2dismod suphp
if you want to enable it again :
sudo a2enmod suphp
I'm real new to Mac and Apache. I my development machine my website cannot access any files under the web roots /images or /css folders.
The apache log gives the following error:
(13)Permission denied: file permissions deny server access:
The site is hosted up under the 'Sites' folder. I checked in 'Get Info' on this folder and it seems that 'Everyone' has read access. What gives?
Thanks!
The problem is that Apache runs with a user different to the user owner of files, and the Apache's user doesn't have read/write/execute permissions. In my case the user was _www and is member of the _www group.
I solved this issue changing the group of the files to the _www:
Look for the apache's user and group. I used this php script:
<?php
echo exec('whoami') . '<br>';
echo exec('groups') . '<br>';
?>
Login with the user owner of the files.
Add the user owner of files to the _www group.
$ sudo dseditgroup -o edit -a userOwnerOfFiles -t user _www
Change the group of files needed to _www
$ chgrp -R _www path/containing/files
Change file permissions for the group
$ chmod -R g+rwx path/containing/files
This was a tough one for me today. It turned out that I needed to give permissions to the web server to the entire directory tree all the way up to the doc root.
It came up for me today because I'm using a virtual host and storing the files pretty far up a tree in my user directory.
I did not want to recursively change all the thousands of files in my Documents directory so I just chmod ed each folder in the path. In my home directory:
$ chmod 755 Documents
$ chmod 755 Documents/projects
$ chmod 755 Documents/projects/dev
$ chmod 755 Documents/projects/dev/someglamorousclientname/
$ chmod 755 Documents/projects/dev/someglamorousclientname/docroot
Another alternative way of solving this is using extended attributes in MacOSX
chmod +a "_www allow list,read,search,readattr,readsecurity,file_inherit,directory_inherit" /path/to/document_root
I've found 2 things did the trick for me (I was specifically trying to get apache to have access to the Downloads folder):
In System Preferences -> Security & Privacy -> Privacy scroll to Full Disk Access on the left, make sure you unlock at bottom, and then click the + to add an app. Navigate to /usr/sbin and find the executable httpd and add that, making sure it has full disk access enabled. Re-lock the preferences
Right click the particular folder in Finder and choose Get Info, then under Sharing & Permissions, allow access for the "everyone" user (or if you are trying to be more security conscious, perhaps only allow for "_www" user - but I did not test this).
That solved it for me
This method is safe & fast to test, and easy to switch back if it's not working (it won't mess up things even more, which is ofter a problem when fixing these kind of issues:
Locate httpd.conf (you can do it with httpd -V in terminal)
Open this file in Brackets or any text editor
In this file, find:
User _www
Group _www
Change it to
User {your username}
Group staff
Maybe you will have to add something else to your User and Group:
In this httpd.conf file, you can also find a path to your webserver, just search for DocumentRoot. Copy this path, and navigate to it in terminal with cd command, for example: cd /Library/WebServer/Documents
When you are in, do a ls -l. This will give you info about webroot folder ownership. Adjust your User and Group in the httpd.conf regarding this
You can also enter the webroot folder and check the sites ownerships as well with ls -l, and update httpd.conf regarding that.
If this is not working, don't forget to switch back to:
User _www
Group _www