I set up git and gitolite with some help from members on this forum and using these instructions:
https://github.com/sitaramc/gitolite
In the instructions one of the requirements is:
a dedicated userid to host the repos (in this document, we assume it is 'git'), with shell access ONLY by 'su - git' from some other userid on the same server.
Are these the correct permissions shown below?
sudo chown git /home/git
sudo chmod -R 755 /home/git
...or are there more appropriate settings to provide necessary security and functionality?
Yes and no:
For /home/git, 700 would work too if you want something "more secure".
But you don't have to protect everything the same way within the git homedir, especially the .ssh directory.
The main point is to avoid '+gw' and '+ow' on /home/git itself: if 'group' or 'others' are writable, ssh won't work (the ssh daemon will refuse to consider /home/git/.ssh content)
See "Creating SSH keys for Gerrit and Hudson" as an example of appropriate ssh protections.
I created the Gitolite hosting user as below on Fedora. Other distributions have similar options in the adduser command
useradd \
--comment ‘git hosting user’ \
--user-group \
--system \
--shell /bin/bash \
--create-home \
--home-dir /home/git git
On Fedora, this command creates a system account git with local password locked. The default option for the useradd command when --password option isn’t supplied is to disable the password.
As I understand, this would give the hosting user an interactive non-login shell like so:
sudo su - git
NB: This question was put out a while ago, but I had the same question when I went about installing Gitolite (and didn't find an answer). I figured it out (or so, I think). So here it is.
Related
Starting point:
Ubuntu 20.04
Gitolite (/home/git/)
Webspace /var/www/webspace (usually owned by www-data:www-data)
Git user (in www-data group and also tried without beeing in group)
I want to update the webspace as git user with post-receive to a www-data directory. I had it archived before I installed Gitolite, but it doesn't seem to work the same way as it did before (or I am missing something). To make it clear: post-receive is executed after pushing (which it's normally not on Gitolite) ... was a hard time too to archive that.
Edit: To make it clear: I want to archive that Git and www-data can access and modify the same files.
What Ive tried:
chmod 777 -R /var/www/webspace (after this git can access but nginx returns with 403?)
Adding Git-User to www-data group
chown www-data:git -R /var/www/webspace
chown git:www-data -R /var/www/webspace
chown git:git -R /var/www/webspace
chown www-data:www-data -R /var/www/webspace (with and without git inside group)(with and without 777)
Executing post-receive manually (Operation not permitted)
Executing post-receive manually as root (well ... works of course, but thats not the point)
... maybe also some steps more which Im maybe missing rn
What Ive noticed so far:
On the contrary to Git, Gitolite checks the repo out with -rw------ (If i remember correctly), maybe that is why its not working with gitolite but with Git
The code (not that it would be important, but just to list everything):
post-receive
#!/bin/sh
GIT_WORK_TREE=/var/www/webspace git checkout -f
Maybe Im just missing something, but please help me.
Try and follow "adding other (non-update) hooks" in order for Gitolite to call the relevant post-receive hook.
add this line in the rc file, within the %RC block, if it's not already present, or uncomment it if it's already present and commented out:
LOCAL_CODE => "$ENV{HOME}/local",
put your hooks into that directory, in a sub-sub-directory called "hooks/common":
# log on to gitolite hosting user on the server, then:
cd $HOME
mkdir -p local/hooks/common
cp your-post-receive-hook local/hooks/common/post-receive
chmod +x local/hooks/common/post-receive
run gitolite setup to have the hooks propagate to existing repos (repos created after this will get them anyway).
Add user (git in my case) to group of webspace (www-data for me)
sudo usermod -a -G www-data git
If you were logged in as user logout to reload the group.
logout
#or
exit
#or
CTRL+A+D
(If you want to recheck the group login as this user and type "groups" to see the groups the user is in)
Make sure the webspace is owned by the correct group. For me:
sudo chown www-data:www-data -R /var/www/webspace
(If you want to recheck this you can go in the directory and type "ls -g")
In my case I had to modify my "post-receive" a bit, because the permissions were always -rw----- after checking out, so here is my "post-receive":
#!/bin/sh
GIT_WORK_TREE=/var/www/webspace git checkout -f #default line to checkout
chmod -R a+r /var/www/webspace #added by me because of permission issues
For convenience I had my "post-receive" in the repo directory (/home/git/repositories/repo/hooks/post-receive). The docs tell you to create a new folder (/home/git/local/specific-hooks/repo/post-receive (but they tell to name it on your own))
*All paths, names, groups and permissions written above only apply to me. They may differ for you installation.
What really solved my problem:
Logout after you change groups
Change permission (chmod) in post-receive
I am trying to build a Vagrant box (CentOS) that will be provisioned by an install.sh shell script. This script will do several things, the first of which, involves creating the correct directory structure under /opt so that my service can be installed there and do other things, like writing logs there, as well.
So my Vagrant project (so far) consists of:
my-app-vagrant/
Vagrantfile
install.sh
Where install.sh looks like:
mkdir /opt/myapp
mkdir /opt/myapp/bin # Where we will install binary to (later in this script)
mkdir /opt/myapp/logs # Where the binary will write logs to
Now the binary does not need elevated privileges in order to run (it is configured via command-line arguments where to write logs to). However I simply want it to live under /opt with the above directory structure, at least for this particular machine.
The problem is that /opt is owned by root. Which means I need to run these mkdirs with sudo, provide the script the password for sudo, and then tweak directory permissions so that when the app runs, it has permission to both run and to write logs to my intended destination (which again, is /opt/myapp/logs). So I tweaked install.sh to look like this:
mkdir /opt/myapp
mkdir /opt/myapp/bin
mkdir /opt/myapp/logs
chmod -R 777 /opt/myapp # Now when the app runs as a normal non-privileged user, we can run + write logs
And I know that I can provide a password to the script via echo <rootPswd> | sudo -S sh install.sh (where <rootPswd> is the correct root password).
Now I'm trying to figure out how to get this running/working correctly when Vagrant is provisioning the VM.
My Vagrant file looks like:
Vagrant.configure(2) do |config|
config.vm.provision "shell", path: "install.sh"
config.vm.box = "centos7"
config.vm.box_url = "https://github.com/tommy-muehle/puppet-vagrant-boxes/releases/download/1.1.0/centos-7.0-x86_64.box"
config.vm.network "private_network", ip: "10.0.1.2"
config.vm.provider "virtualbox" do |vb|
vb.memory = "2048"
end
end
But what I'm stuck on is: how do I extend the whole "echo <rootPswd> | sudo -S sh install.sh"-concept to Vagrant? According to their docs there is a privileged option that I might be able to use, but it is set to true by default anyways.
But nowhere in their docs do they explain how/where to provide the sudo password that should be used (at least from what I have been able to find so far).
So I ask:
How do I provide the sudo password for a Vagrant VM's shell provisioner's installation script?; and
Where can I find out what the sudo password even if, given the base Vagrant box that I'm trying to use?
Turns out that (for almost all Vagrant boxes) the vagrant user is listed in /etc/sudoers with ALL=(ALL) NOPASSWD:ALL permissions, which instructs Linux to not ask that user for a "sudo password", ever.
Hence, you don't need to supply your privileged user with a sudo password.
While smeeb's answer is the case even to this day, it doesn't quite answer the question. Really there are different ways to do this depending on the provisioner you are using. For example, in Ansible you can use ask_become_pass to be asked for the password prior.
With the shell provisioner you won't have any helpers outside of those Ansible provide. If privileged doesn't do it for you then you'd probably need to just sudo manually.
To do this you can use the following:
echo "mypassword" | sudo -S command
Take heed though, doing this on something throwaway will mean you will have traces in your history of that password.
root#jupiter:/home/jupiter/projects# git clone
ssh://git#demo.jupiter.com/diffusion/TD/transcend.git Cloning into
'transcend'... sudo: sorry, a password is required to run sudo
fatal: Could not read from remote repository.
I have set up the SSHfollowing the manual.
I also have the conduit ping returning the correct message:
root#demo:~# echo {} | ssh git#demo.jupiter.com conduit conduit.ping
{"result":"demo.jupiter.com","error_code":null,"error_info":null}
Below is my visudo file for reference.
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
### User privilege specification
root ALL=(ALL:ALL) ALL
git ALL=(ALL:ALL) ALL
git ALL=(root) SETENV: NOPASSWD: /usr/local/bin/git-upload-pack, /usr/local/bin/git-receive-pack
### Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
### Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
In this answer I've found that you should be careful defining multiple entries for a user in the sudoers file. Your second entry overrides your first entry for the git user, and that first entry does not have a NOPASSWD: directive.
I also had the same problem, and using only the below value in the sudoers file for the git user fixed the problem:
git ALL=(ALL) NOPASSWD: ALL
This suggests that the git user is trying to use sudo for commands other than just git-upload-pack and git-receive-pack.
It may also be the case that you have more than 1 of these commands in your PATH and the git user finds the commands from another location.
From the same page, but further down https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/#troubleshooting-ssh
You should test these commands on the phabricator server ( I've changed them from the documented ones to fit your environment)
$ su git
$ sudo -E -n -u root -- /usr/local/bin/git-upload-pack
If everything works you will receive
usage: git upload-pack [--strict] [--timeout=<n>] <dir>
Also have you made sure to set the phd.user? This would be 'root' in your case
And make sure Defaults requiretty is commented out in your visudo file.
Hope it works for you, as phabricator is an excellent tool.
I just ran across this and quickly noticed it was due to me not paying attention when setting up the sudoers file. In order to fix this you can run the following commands.
$ which git-upload-pack
$ which git-receive-pack
Make sure that the paths that are output are the same as the ones you have listed in your sudoers file. No password is required but only when running the binary at those specific locations.
After using the exactly sudoers config described on https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/ I was able to fix the error:
$ vi /etc/sudoers.d/root
root ALL=(root) SETENV: NOPASSWD: ALL
If a root user is running a bash script that configure some stuff on machine for a user. The script would configure a git repository and an ssh key for password-less github communication, then it would clone the repository.
This will only happens once.
I'm new to bash, how would I do this?
My solution so far (this script is run as root):
USERNAME="vagrant"
HOMEDIR="/home/$USERNAME"
apt-get update -y
apt-get install git -y
cp id_rsa* $HOMEDIR/.ssh #copying predefined keys
su -c "eval `ssh-agent -s` ssh-add $HOMEDIR/.ssh/id_rsa" $USERNAME
chmod 400 $HOMEDIR/.ssh/id_rsa
cat $HOMEDIR/.ssh/id_rsa.pub > $HOMEDIR/.ssh/known_hosts
This doesn't work because the key is not being added, I get the error:
Could not open a connection to your authentication agent.
With a root user that has no login on a remote host, and /root/.ssh does not exist, I can interactively ssh in with:
su - $USERNAME -c "ssh $USERNAME#<remotehost>"
It reads USERNAME's ~/.ssh/known_hosts file (or prompts for verification). If correct keys exist in USERNAME's ~/.ssh it uses them. When done, there is still no /root/.ssh, i.e. this is completely done as USERNAME, not root.
Likewise with git cloning:
su - $USERNAME -c "git clone remoteuser#host:/path/to/repo"
Just be careful of quoting. If you want a variable dereferenced at the time you run su, use double quotes. If you want a variable dereferenced after su has handed off to the user's shell, use single quotes. Example:
su - myuser -c "echo $HOME"
/root
su - myuser -c 'echo $HOME'
/home/myuser
I have a .sh file (lets say adduser.sh) that is executed via a cronjob that contains the commands to create an FTP user.
The adduser.sh file looks like so...
#!/bin/bash
mkdir /var/www/vhosts/domain/path;
useradd -d /var/www/vhosts/domain/path -ou <uid> -g <group> -s /bin/false <username>;
echo <password> | passwd <username> --stdin;
Now here is my problem. If I run it directly through SSH using...
sh adduser.sh
...no problems and it works as intended.
But if I let the cronjob run it the directory is created but the user is not added.
What gives?
As it stands, there is an alternative to useradd known as adduser. In Debian or Ubuntu, adduser is a perl script and performs sequential functions like create the user using adduser, assign it to a group, create home directory etc.
As per adduser man page-
adduser and addgroup are friendlier front ends to the low level tools
like useradd, groupadd and usermod programs, by default choosing
Debian policy conformant UID and GID values, creating a home directory
with skeletal configuration, running a custom script, and other
features.
In Fedora, RedHat, and CentOS, adduser is just a symbolic link to useradd.
[root#hobbit ~]# which /usr/sbin/adduser
lrwxrwxrwx 1 root root 7 2012-09-20 20:20 /usr/sbin/adduser -> useradd
If you are on any on the above OS then you can try adduser redirect 2> to a add_user.log file and check the file to see if something goes wrong.
I have resolved this simply adding /usr/bin/ to the useradd function.
#!/bin/bash
mkdir /var/www/vhosts/domain/path;
/usr/bin/useradd -d /var/www/vhosts/domain/path -ou <uid> -g <group> -s /bin/false <username>;
echo <password> | passwd <username> --stdin;
Thanks everyone for helping me get on the right track. Hope this helps someone out there.