We've recently set up Gitolite server. All seems well. I can connect to it without a problem.
A new user has been set up, he's on a Mac and trying to use SourceTree. The only way I could get him to connect was for him to attempt to ssh to the server and I typed in the password (exited afterwards). Without that the system kept asking for a password for that server.
Is this normal behaviour?
How do non-sysadmin users gain access to gitolite?
Gitolite is based on forced command, which means non-interactive session.
So:
no password should ever be entered (assuming here non-password protected private key).
(as detailed in "how gitolite uses ssh").
no "non-sysadmin" should ever gain access to gitolite server itself.
So all he should need is a public key stored in ~/.ssh (making sure both his home and .ssh aren't group or world writable), registered in gitolite-admin/keys and published on the gitolite server .ssh/authorized_keys file.
From there, as mentioned in "Sourcetree and Gitolite":
If you are cloning a remote git repository, you need to tab out of the Source path/ URL field to activate the clone button.
The url will be validated at that point.
The url needs no special syntax working with gitolite, and even respects the host entries in your ssh conf file. So in my case a url of gitolite:workrepo is sufficient.
Related
I would like to store Git credentials for git pulls permenantly on a linux machine, and git credential.helper doesn't work ( I think because I'm not using SSH ) - I get that error "Fatal: could not read password for 'http://....': No such device or address". Given that I'm not the administrator of the repository and only HTTP is allowed for authentication, and fortunately I don't care about the safety of the password. What can I do to put the git pull command in a bash file and avoid prompting the user for password?
I hope there is a way around it.
Two things wrong with this question:
Most repositories such as GitHub require HTTPS. Even if you try to clone over
HTTP, it just switches it on the backend to HTTPS and pushes require it as
well.
Pulls don’t require a password, unless it’s a private repo. Like #1, since
you’ve given no info about your repo it’s hard to comment further on this.
Now, what I do is this:
git config --global credential.helper store
Then the first time you push it will ask for your credentials. Once you’ve
entered them they are stored in ~/.git-credentials. Note that they are stored
in plain text, you have been advised.
I'm assuming that your repository requires authentication for pulls, or else git wouldn't ask you for a password for the pull.
The recommended way to bypass the user password prompt is to create an SSH key on that machine, add the public key to the git server, then use the SSH url for the remote instead of the HTTP/S url. But since you specifically said:
I don't care about the safety of the password
you can actually just specify the password inline for the git pull like this:
git pull http://username:password#mygithost.com/my/repository
I am trying to setup my git workflow (to deploy automatically my node.js app when I push).
I have tried multiple things and end up doing this : http://toroid.org/ams/git-website-howto
I managed to make this method work but I have one problem left :
I am in the list of authorized_keys of my git and root users so I can login via SSH to these users.
But when I do a git pull, my computer tries to ssh using its current user to the server. That means that it searches on my server a user which has the same login as my local one (which doesn't exist)
If I am logged locally as root, it connect as root to the distant server and works. Otherwise, it tries a user that doesn't exist there and doesn't work.
Not sure if I explained this well... Sorry if this is not. Anyway if anyone know how to fix this and make me able to use git without having to create a distant user for each people of my team it would be cool :)
Oh and my client is OS X and server Ubuntu
I’m not entirely sure if I understood you correctly, but you can set the username directly when specifying the URL of the remote.
For example on most Git hosting sites, you are supposed to use the user git when connecting via SSH. This allows them to create only a single user they have to maintain while putting all authorization details behind that.
So a usual remote URL on GitHub for example looks like this: git#github.com:user/repository. This is the long form of ssh://git#github.com/user/repository.
So when you set your remote, when cloning, or afterwards, just include your username there and Git will use it when connecting via SSH:
git clone git#myserver:/path/to/repository
I have gitolite installed. I'm able to administer it fine. I've added a few new repos, and a few pub keys. Installed as 'git#domain.com' and a repo added for a user as repo.git.
Does it have to be git#domain.com:repo.git to access, or is there a way to indicate the user in the url?
Possibly something like user#domain.com:repo.git or git.domain.com/user/repo.git for example?
No, it has to be git#domain.com because the user is always the same: the git account you are using to install and administer gitolite on your server.
The actual user is deduced from the public key you are using when making your ssh call.
If you registered that key with the user.pub file representing said public key named after the user's login, then gitolite will be able to identify you.
For more, see "how gitolite uses ssh".
If you look in the authorized_keys file, you'll see entries like this (I chopped off the ends of course; they're pretty long lines):
command="[path]/gitolite-shell sitaram",[more options] ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA18S2t...
command="[path]/gitolite-shell usertwo",[more options] ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArXtCT...
First, it finds out which of the public keys in this file match the incoming login.
Once the match has been found, it will run the command given on that line; e.g., if I logged in, it would run [path]/gitolite-shell sitaram.
So the first thing to note is that such users do not get "shell access", which is good!
When gitolite-shell gets control, it looks at the first argument ("sitaram", "usertwo", etc) to determine who you are. It then looks at the SSH_ORIGINAL_COMMAND variable to find out which repository you want to access, and whether you're reading or writing.
Now that it has a user, repository, and access requested (read/write), gitolite looks at its config file, and either allows or rejects the request.
I have the following setup:
A server (centOS) with git and a repository for a project on the same server.
What I need to do is to be able to pull from the repository without being asked for password (because is annoying).
Note: I am logged as root when I pull.
Can anyone help me with that?
There are a few options, depending on what your requirements are, in particular your security needs. For both HTTP and SSH, there is password-less, or password required access.
HTTP
==============
Password-Less
Useful for fetch only requirements, by default push is disabled. Perfect if anonymous cloning is the intention. You definitely shouldn't enable push for this type of configuration. The man page for git-http-backend contains good information, online copy at http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html. It provides an example of how to configure apache to provide this.
User/password in .netrc or url embedded
Where .netrc files are using in the form:
machine <hostname> login <username> password <password>
And embedded urls would be in the form:
http://user:pass#hostname/repo
Since git won't do auth for you, you will need to configure a webserver such as apache to perform the auth, before passing the request onto the git tools. Also keep in mind that using the embedded method is a security risk, even if you use https since it is part of the url being requested.
If you want to be able to pull non-interactive, but prevent anonymous users from accessing the git repo, this should be a reasonably lightweight solution using apache for basic auth and preferably the .netrc file to store credentials. As a small gotcha, git will enable write access once authentication is being used, so either use anonymous http for read-only, or you'll need to perform some additional configuration if you want to prevent the non-interactive user from having write access.
See:
httpd.apache.org/docs/2.4/mod/mod_auth_basic.html for more on configuring basic auth
www.kernel.org/pub/software/scm/git/docs/git-http-backend.html for some examples on the apache config needed.
SSH
==============
Passphrase-Less
Opens up for security issues, since anyone who can get a hold of the ssh private key can now update the remote git repo as this user. If you want to use this non-interactively, I'd recommend installing something like gitolite to make it a little easier to ensure that those with the ssh private key can only pull from the repo, and it requires a different ssh key pair to update the repo.
See github.com/sitaramc/gitolite/ for more on gitolite.
stromberg.dnsalias.org/~strombrg/ssh-keys.html - for creating password less ssh keys:
May also want to cover managing multiple ssh keys: www.kelvinwong.ca/2011/03/30/multiple-ssh-private-keys-identityfile/
Passphase protected
Can use ssh-agent to unlock on a per-session basis, only really useful for interactive fetching from git. Since you mention root and only talk about performing 'git pull', it sounds like your use case is non-interactive. This is something that might be better combined with gitolite (github.com/sitaramc/gitolite/).
Summary
==============
Using something like gitolite will abstract a lot of the configuration away for SSH type set ups, and is definitely recommended if you think you might have additional repositories or need to specify different levels of access. It's logging and auditing are also very useful.
If you just want to be able to pull via http, the git-http-backend man page should contain enough information to configure apache to do the needful.
You can always combine anonymous http(s) for clone/pull, with passphrase protected ssh access required for full access, in which case there is no need to set up gitolite, you'll just add the ssh public key to the ~/.ssh/authorized_keys file.
See the answer to this question. You should use the SSH access instead of HTTPS/GIT and authenticate via your SSH public key. This should also work locally.
If you're using ssh access, you should have ssh agent running, add your key there and register your public ssh key on the repo end. Your ssh key would then be used automatically. This is the preferred way.
If you're using https access, you one would either
use a .netrc file that contains the credentials or
provide user/pass in the target url in the form https://user:pass#domain.tld/repo
With any of these three ways, it shouldn't ask for a password.
I am using git-svn to develop code that is hosted on a SVN+SSH repository. I do not have to input my ssh password on the server every time I dcommit/update/rebase, so I assume it is cached somewhere.
Where are my credentials saved? Inside the .git directory, or globally in some dot-file in my home directory?
I ask because my git repository is public-readable on my home directory (we have a homes-are-readable policy in our laboratory), and I am afraid that this might leak my ssh credentials to all the lab.
Thanks.
As noted in Does Git-Svn Store Svn Passwords?, they are stored in ~/.subversion, so as long as your home directory itself is not public readable you shouldn't have a problem (though as I've just read your last line a bit more thoroughly, you may have a problem).
Have you configured your SSH server to use key-based authentication? It's likely that your private key (password protected or not) is in ~/.ssh/id_rsa or ~/.ssh/id_dsa (the public key being the .pub file associated with them). You should definitely protect those directories, although, in most cases, ssh won't even let it work if they're readable by someone else (other than root).