更改 github 用于克隆和访问 GitHub 上的存储库的 ssh 密钥

Question

I need to change which ssh key GitHub uses to clone and access repos on my local machine.

For example, it is defaulting to use /c/Users/xxx.xxx/.ssh/id_ed25519. But I need it to use /c/Users/xxx.xxx/.ssh/id_rsa_github

Is there some way to change that configuration?

Answer 1

There is—but first, we should straighten out your question. It's not GitHub that uses an ssh key. It's ssh that uses an ssh key. So the place to look is ssh's configuration .

Some ssh configuration details are OS-dependent, but virtually all ssh implementations will use a hidden .ssh folder (directory) in your home directory (folder). In this .ssh , you will find several ordinary files:

• known_hosts contains a list of fingerprints for hosts you've connected to before.
• authorized_keys , if it exists, contains a list of keys that someone can use to log in to your machine (if your machine allows logins at all).
• id_rsa and id_rsa.pub contain the default private and public keys for RSA encryption.
• id_ed25519 and id_ed25519.pub contain the default private and public keys for ED25519 encryption.
• config contains your personal ssh configuration. This is the file you want to adjust.

The config file consists mainly of sets of lines, with a line-set starting with a Host line. The Host line defines which name(s) the subsequent lines apply to. So to make things apply to the command:

ssh github.com

for instance, you might write Host github.com as a line.

Underneath the Host line (and normally indented further as a visual clue) you will add more configuration lines, such as:

    User git
    IdentityFile ~/.ssh/id_rsa_github
    IdentitiesOnly yes

The User git line, if present, sets the default user name . This is optional but saves you from having to type in git@ in front of github.com .

The IdentityFile line gives the path name of a key (key-pair, really: one file is normally named whatever.pub and the other whatever ) to be used with this host. Since you say you want id_rsa_github used, that's the name we'll give here; the ~/.ssh/ tells ssh to find this in the .ssh directory. (You can use backwards slashes on Windows, but forwards ones are easier to type, and work everywhere , so that's what I would do and what I show here.)

The IdentitiesOnly yes line is important, though often not crucially so: it tells ssh that, despite however many keys it may find on a "key ring" (eg, provided via an SSH Agent, using ssh-add ), you want any attempt to open a lock on github.com to use only this one particular key . The reason this is important has to do with the way ssh works on GitHub.

How ssh public key authentication works with GitHub

Whenever you ask to log in on GitHub—whether with https or ssh, in a browser or because Git is literally running ssh so as to access a repository on GitHub—you must provide two (or sometimes more) pieces of information to GitHub:

• Who do you claim to be?
• What proof do you have that you are this person?

When using https, this is pretty straightforward, because you send over a user name to say who you claim to be, and then an authorization token (basically a fancied-up password) to prove that you are that person. When using ssh, however, you are required to claim that you are a guy named git at the ssh level. You don't send your actual user name here!

Instead, to provide the user name , GitHub keeps a giant table of user-name-and-public-keys. Having provided the name git , GitHub now demand, via their ssh server, a public key. Your ssh code hunts around for all the public keys that it could possible use on this "door lock". Maybe there's only one key, in the file you've named. Maybe there are hundreds of keys, on an OSX Keychain, or in an SSH Agent, or in a Windows Keychain, or whatever: there are a lot of possibilities.

Your ssh will begin offering public keys, one at a time, from the allowed list, until GitHub recognize one of these. That public key has a user name attached to it, inside a table over on GitHub. They then say: Okay, I see you're claiming to be _____ (fill in the blank), now prove it. Here's a secret challenge that you can reply to if and only if you have the private key too. Your ssh then uses your private key to decrypt the challenge, and respond correctly, and now they know you hold both keys and therefore are the person you claimed to be.

But who did you claim to be? You claimed to be the person whose public key got used . If you have more than one public key that could work , you've just claimed to be one of those several identities. Is that the identity you wanted? If so, great! If not, bad!

The IdentitiesOnly line tells ssh that it should only try the public key(s) listed on these lines . That way you can have two or more public keys on GitHub, one for a work identity for instance and one for personal projects, and you control which of these public keys get offered.

(To make the multiple identities work, you simply define more than one Host : you might define a Host gh-work and a Host gh-home for instance. But we'll leave that for other questions.)