Source tree won't forget user ID/ssh key

[configman]

I'm just getting started with Source Tree and was thinking it was a pretty good client until I ran into this problem for which there doesn't appear to be a similar question already;

I'm setting up a new git server using ssh access with gitolite as the server side management tool. I managed to create the gitolite-admin repo, check it out using the gitolite admin users key to my own machine. i then made what I thikn is a mistake; I added my personal ssh key (public) with the name id_rsa and also added this key to source tree.

now when I try to pull from the remote repo (or do anything else with it) I get an error message saying that access is denied to id_rsa. I've removed the local repository for the gitolite-admin by asking source tree to remove the book mark and the disk files. I;ve removed all the ssh keys from the source tree options page but still everytime i try to clone the gitolite-admin repository I get a failure message that says access is denied to the id-rsa user.

How does one get source tree to use the correct key for access to the repository and forget the old user id and key? More generally, what is the process for management of multiple user IDs in source tree?

Thanks

Damon jebb

[stevestreeting · Accepted solution]

The location of id_rsa for the purposes of actually performing authentication is actually the domain of ssh (OpenSSH in this case - I assume you're talking about the Mac version).

The default key location is ~/.ssh/id_rsa. SourceTree doesn't actually specify the location of the key, it's just derived from OpenSSH's own defaults. You'd keep the private key local (that's id_rsa), and upload the public version of it to your server, to the ~/.ssh/authorized_keys file.

OpenSSH is picky about the permissions of your local private key, because it's important for it not to be visible to others. If you have the permissions set too openly on ~/.ssh/id_rsa then OpenSSH won't let you use it. The correct permissions are set like this:

chmod 600 ~/.ssh/id_rsa

Your public key can be more open (typically id_rsa.pub) because you share this with other people.

On the subject of using multiple keys, I generally advise people not to do it unless they really have a serious need to have different identities in different keys. id_rsa is used by default, but you can create other keys and use the ~/.ssh/config file to specify which ones to use in different circumstances - here's some more info on that: http://www.cyberciti.biz/faq/force-ssh-client-to-use-given-private-key-identity-file/. But again, I'd advise not doing this if you can help it - personally I've never needed more than one key and I've worked on a lot of projects.

[edmechem]

I found a solid answer - quick fix, detailed explanation, and steps (add LaunchAgent) to keep it from happening again - here: https://stackoverflow.com/questions/47804813/how-do-you-keep-sourcetree-ssh-from-forgetting-your-ssh-keys-i-have-to-manuall

[configman]

Thanks Steve. I have finally got my head around this now and realise that git and source tree are just calling open ssh. I tried the ~/.ssh/config file to set the key that is used for this but what was actually confusing me was that when I added my key to the gitolite configuration it was called id_rsa.pub from which gitolite created a user called id_rsa. It was gitolite that is recognising my key and then calling me 'id_rsa'. I needed to make a copy of my public key file with damon.pub to be able to call myself 'damon' when connecting to the repository.

I'm not sure I can get away with a single identity file as it will mean going back to other locations and updating the file to my id_rsa one, but I will certainly try to keep the number of keys to a minimum.

Thanks

Damon Jebb

[stevestreeting]

One point on this - it's perfectly OK to have multiple public keys in your authorized_keys file on servers, while still having a single key on each client. I do this occasionally so I have the public key relating to my primary ID allowing me in, but also a secondary public key which I might have on another server, so I can ssh between the 2. This lets me partition up what keys I'm using so that I can revoke the access of one key without the other - I keep my main private key very secure, only on local physical machines and I don't want to upload that one to a server just so I can ssh across boxes. But each ssh client only has one key, it just might be a different one if it's on a machine I don't 100% physically control.