I have tried to check several SO questions and answers but still unable to resolve my concern. The scenario is this:
User A with Git Account A git cloned repo to freshly installed server.
Because of this, the git account that was registered on the server was User A.
(If I understood it correctly. please correct me if I am wrong in this part)
Now I would like to use User B with Git Account B as commiter/puller/pusher to the server.
What I tried was to change the user and email with the following command:
git config --global user.name "userb"
git config --global user.email "userb#gmail.com"
git config --local user.name "userb"
git config --local user.email "userb#gmail.com"
git config user.name "userb"
git config user.email "userb#gmail.com"
On 3 separate occasions. Still unable to resolve my concern. I can see the updated user and email with command git config --list, git config user.name and git config user.email so I know that the value did change.
If this is not possible, I am also considering to remove the accounts all together and enter the user/email and password when pulling/pushing without removing the git history.
You are doing the wrong thing. You are trying to change the user name used to mark your commits, instead you have to reset your git user account credentials.
Under Linux issue git config --unset credential.helper, under Windows remove the credentials by the Windows Credentials Manager.
User A with Git Account A git cloned repo to freshly installed server.
Because of this, the git account that was registered on the server was User A.
No. There are two common / standard transport mechanisms that a Git client (like git clone) will use to talk to a Git server:
https: the client provides a user name and additional authentication data (password, token, whatever); or
ssh: the client provides a public key; the server looks up the public key to determine who the client claims to be,1 and challenges the client with a task that can only be completed by someone holding the corresponding private key, so that if the client does complete the task, the claim must have been accurate.
These mechanisms are provided not by Git itself, but by some sort of access wrapper: a web server, or an sshd.
At this point, the client is authenticated to the server, and only now does Git itself actually enter the picture. The server's Git software hands to the client every commit in the server's repository (so that the client has all the commits), and shows to the client all the branch names (which the client then changes into remote-tracking names, so that the client has all the commits and no branches at all). Then the client disconnects from the server, creates one branch in the new Git repository, and is done.
The only thing retained here is the URL that the client used to reach the server. This URL is retained in the Git repository the client just created. Unless the server keeps logs (via its web server and/or sshd),2 the server now has no record at all of the client.
The next time the client needs to talk to the server, the client provides the URL, which it has saved conveniently under the short name origin.3 This URL may contain a user name, especially if you used an https:// URL.
So: check the URL, using git remote -v, to find out which protocol you are using and whether, if that protocol is https://, there is a user name embedded in the URL. If so, you can edit or remove that user name. If not, and the URL is an https:// URL, proceed with Antonio Petricca's answer. If the URL is an ssh:// one, look into ssh authentication.
1On some servers, the user logs in using their own account, but for the usual GitHub, GitLab, and Bitbucket setups, the user provides the generic user name git. Hence the server has to use this public-key trick to figure out who the user is claiming to be.
2Most servers do keep logs, but that's up to the server, and they're used at most for auditing and security. It does not affect future attempts to connect to the server, unless, e.g., the people running the server find your connection alarming and block it.
3You can choose some other name, but there is no reason to do that, and presumably you did not.
Related
I created a brand new github account and then a new repository.
Also, I created a github token.
Locally on my mac, I run a
git push
and the first time I had to enter username and github-token.
After that, it seems terminal never asks for username or password/token.
Then I logged in into my ec2 server and did the same:
git clone myrepo
username: my_username
passowrd: my_token
And I was able to get the code.
After that, each time I make a pull in my ec2 server, it always prompts for username/password.
So for some reason mac stores credentials but aws doesn't.
It seems you need some application?
I had a look at this:
https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git
But it seems there is no available version for my ec2? What I understand it uses its own linux distro, called Amazon Linux 2. So the question is: is there a credential manager for aws ec2?
Have you following the instruction?
Link: https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#gits-built-in-credential-cache
Git's built-in credential cache
Available on: Windows, macOS, Linux
export GCM_CREDENTIAL_STORE=cache
# or
git config --global credential.credentialStore cache
This credential store uses Git's built-in ephemeral in-memory
credential cache. This helps you reduce the number of times you have
to authenticate but doesn't require storing credentials on persistent
storage. It's good for scenarios like Azure Cloud Shell or AWS
CloudShell, where you don't want to leave credentials on disk but also
don't want to re-authenticate on every Git operation.
By default, git credential-cache stores your credentials for 900
seconds. That, and any other options it accepts, may be altered by
setting them in the environment variable GCM_CREDENTIAL_CACHE_OPTIONS
or the Git config value credential.cacheOptions. (Using the --socket
option is untested and unsupported, but there's no reason it shouldn't
work.)
export GCM_CREDENTIAL_CACHE_OPTIONS="--timeout 300"
# or
git config --global credential.cacheOptions "--timeout 300"
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
We are using git with gitolite and sometimes my users change there names with
git config --global user.name
so I would like to see some more details in the log to find out if someone has change the name setting but is still the same workstation (ssh key). Anyway to do this?
IMO, the ssh keys in commit messages will be a complete overkill. You don't want your commit messages to look up completely screwed some x days later, just because each of them contain different ssh keys.
You should have a look at git notes to supplement your commits with additonal information. In the notes, you can add the committer's Username and other environment variables.
Worst case, you can add the ssh keys in git notes, though I am not sure how that stops malicious users who currently fake commits in some other user's name from trying to hack around and get hold of some other user's ssh keys.
More importantly, if developers are doing this in complicity with each other, the ssh keys will be completely insufficient.
Assuming you are on linux, you can get the username using
printenv | grep USER
You can similarly choose other details you need from the environment that you need to put into the git note.
Next, you can write a post-commit hook which automatically adds all this information post every commit.
In the gitolite 3.x you can IIRC add a VREF constraint that committer (or author) matches SSH key used, or HTTP auth user (I guess it uses the username part of user.email, or whole of user.email).
Though this is discouraged as a pre-receive hook (i.e. block), you can set up post-receive hook instead to log and compare committers with auth usernames.
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
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.