I have the following use case: I would like to be able to push to [email protected]:gitolite-admin
using the private key of user gitolite-admin
, while I want to push to [email protected]:some_repo
using 'my own' private key. AFAIK, I can't solve this using ~/.ssh/config
, because the user name and server name are identical in both cases. As I mostly use my own private key, I have that defined in ~/.ssh/config
for [email protected]
. Does anyone know of a way to override the key that is used for a single git
invocation?
(Aside: gitolite distinguishes who is doing the pushing based on the key, so it's not a problem, in terms of access, ownership and auditing, that the user@server string is identical for different users.)
To specify which private key should be used for connections to a particular remote host, use a text editor to create a ~/. ssh/config that includes the Host and IdentityFile keywords. Once you save the file, SSH will use the specified private key for future connections to that host.
Login to github.com and bring up your account settings by clicking the tools icon. Select SSH Keys from the side menu, then click the Add SSH key button. Name your key something whatever you like, and paste the contents of your clipboard into the Key text box. Finally, hit Add key to save.
SSH keys are stored in the ~/. ssh folder.
Even if the user and host are the same, they can still be distinguished in ~/.ssh/config
. For example, if your configuration looks like this:
Host gitolite-as-alice HostName git.company.com User git IdentityFile /home/whoever/.ssh/id_rsa.alice IdentitiesOnly yes Host gitolite-as-bob HostName git.company.com User git IdentityFile /home/whoever/.ssh/id_dsa.bob IdentitiesOnly yes
Then you just use gitolite-as-alice
and gitolite-as-bob
instead of the hostname in your URL:
git remote add alice git@gitolite-as-alice:whatever.git git remote add bob git@gitolite-as-bob:whatever.git
You want to include the option IdentitiesOnly yes
to prevent the use of default ids. Otherwise, if you also have id files matching the default names, they will get tried first because unlike other config options (which abide by "first in wins") the IdentityFile
option appends to the list of identities to try. See: https://serverfault.com/questions/450796/how-could-i-stop-ssh-offering-a-wrong-key/450807#450807
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With