I'm using Github. I often push my files to repo using Git Bash. But lately I found out that:
Within my git config, I only set username & email. There is no password field. But I could push & modify the remote repository.
Does it mean that anybody that has even only just my email, that's being used for a Github account, could:
- Set my email in their git config
- Clone my repo to their local directory
- Modify my repo by git push or another command?
CodePudding user response：
No.
Your .gitconfig is not how you're authenticated to GitHub. Most likely you set up SSH auth at some point, by creating a private key on your machine, and adding the public key to your account. No one can push to your repos unless you give them access.
CodePudding user response：
Your user.name and user.email settings affect the stored name-and-email that Git writes into new commits. That's pretty much all they do, unless (as is the case with GitHub) some other system also uses those.
When you run git push or git fetch, your Git software calls up some other Git software via the URL you provide: ssh://[email protected]/... or https://github.com/... for instance. This activates some server instance on GitHub. That server demands authorization credentials. This part is completely out of Git's hands: the part of the GitHub server that's asking for credentials is not part of Git at all (it's part of ssh or Apache/nginx/whatever-web-server).
Their (GitHub's) demand for authorizing credentials arrives at your computer in one of two ways:
- If you're using
ssh://...as the URL, your ssh client supplies the credentials. - If you're using
https://...as the URL, your Git sees a request for authorization (user name and/or password, generally) and invokes a credential helper. Git does not know how to respond to these requests itself! It simply passes the request on to the helper.
HTTPS
Let's address HTTPS servers first. Your helper, assuming you have one (or more) configured, interprets the request and gets information from you and/or files on your computer. This may involve decrypting a stored password or token, or reading a password or token from you, the user; it may or may not involve obtaining a user name in similar fashion. But once the helper says to Git these are the credentials, Git forwards them to the web server. That web server then either permits or denies the connection. If the web server permits the connection, the web server fires up appropriate Git software on GitHub to allow the push or fetch operation to proceed. If not, the software on GitHub—not Git, the other software here that's part of the HTTPS authentication system—denies permission.
The end result is simple enough: you must provide a user name (because GitHub demands one) and a "token" (which Git calls a "password"; a GitHub token and a password are effectively the same thing at this level, but with some minor but important internal technical differences below this level). If you provide a correct token, GitHub will allow access; if not, they won't.
SSH
Let's look at the ssh protocol (very) briefly. This is somewhat similar to the https one, in that ssh will present, to the GitHub ssh server, a user name and "password". However, in the authentication scheme that GitHub (and other public Git server hosting sites) use, the "user name" must always, always be git. So this user name literally cannot identify you, because when I connect to GitHub to access my repositories, I must also claim to be the user git. The "password" is not actually a single password at all, but rather half of a key-pair, consisting of a public key and a private key. The part your computer sends on is the public key, which is designed not to compromise security if it's exposed.
Now, the user named git on GitHub isn't actually a real person. Instead, it's hooked up to a system where, when I present the public key half of my key-pair, GitHub look up that half. They have a huge table where everyone's public key is listed, along with the user name associated with that public key. So simply by sending over some public key, you've claimed to be a particular user.
The thing about the public key, though, is that it's ... well, public. I can spy on your computer and see your public key, without any bad consequences to you. The way this works is that, having presented a public key to GitHub, GitHub will next challenge your (or my) ssh software, sending it some encrypted data (a random number, more or less). If you or I have the private half of this key-pair, we will be able to decrypt it quickly and reply back saying: You sent me this random number. If not, we won't, and our connection will time out.
Once we send back the correct random number, GitHub's ssh server is now satisfied that we not only have claimed to be person X, we really are person X. They now look at the rest of the data in the incoming request, which includes the repository we'd like to access, and check to see if person X is allowed to access the repository. If so, they let the conversation proceed, running their Git software; if not, they send a rejection message.
GitHub authorize, or don't; Git plays almost no part
The end result of all of the above is that the https or ssh server on GitHub decides whether we are who we claim to be, and whether that person is supposed to have access to the repository in the incoming request. If you're using ssh, all of this happens without Git having to get involved at all: it's ssh, not Git, that authenticates you. If you're using https, Git has to relay the user name and "password" (token) requests through to a credential helper, but it's the credential helper that actually authenticates you.
You'll need to make sure your credentials are set up. Since they're not handled by Git itself, regardless of which protocol you use, you'll do that setup outside Git.