I made the grave mistake of upgrading a working installation. Who'd expect a regression bug in something as fundamental as authentication?
HTTPS authentication was working fine for a *private* Github repo. Doesn't now for pull requests. Yet works well enough to download all hunk details of the remote commit that it won't process.
Tried deleting the relevant file in ~/Library/Application Support/Sourcetree, deleting the keychain entry, and re-entering the password when prompted. Even repeating the process after deleting and re-adding the account in Preferences | Accounts. No dice.
In the end, I had to switch to SSH to get things working again, but that was not without annoyances.
I realize you have a competing service to Github, but authentication should really be more robust than it seems here.
Hi Richard,
I understand that you had some trouble with authentication with your GitHub account setup on Sourcetree. I also acknowledge that ssh key selection isn't the best of experiences if you have a key already in a custom location and Sourcetree doesn't select a previously generated key unless the account is authenticated (if you are using OAuth). We will definitely note this and make the experience better in the coming days. Feel free to submit a ticket for this on our public bug tracker jira.atlassian.com to track.
However, I see that HTTPS Auth for GitHub is working as expected for me in almost all use cases. I would like to understand the specific steps that led to the error and error messages you saw with the reports of authentication failure. Should you face this again, please make sure you enable debug logging for Sourcetree by executing below command on the terminal and send us the logs too.
defaults write com.TorusKnot.SourceTreeNotMAS
"LogLevel"
5
Thanks,
Manjunath
Sourcetree Mac Developer
Hi, Manjunath.
This was a previously working Github repo. It broke after the upgrade to 2.6.3, and was discovered when pulls stopped working. Going so far as deleting and recreating the account in Sourcetree didn't fix the problem.
The only mildly unique thing here is that the Github repo is not public - it's a private one and the account in question is the owner, not just an authorized user.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
And now... the SSH config that was the fix is no longer working.
The dialog box error message:
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree fetch origin
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
The console message log:
default 22:39:41.484189 -0700 Sourcetree UNIX error exception: 17
default 22:39:41.484324 -0700 Sourcetree 0x610000a78200 opened /private/var/db/mds/system/mdsDirectory.db: 50744 bytes
default 22:39:41.484639 -0700 Sourcetree UNIX error exception: 17
default 22:39:41.484802 -0700 Sourcetree 0x618000c69880 opened /Users/Richard/Library/Keychains/login.keychain-db: 1144436 bytes
default 22:39:41.488529 -0700 Sourcetree CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 22:39:41.488619 -0700 Sourcetree CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 22:39:41.488692 -0700 Sourcetree CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 22:39:41.488758 -0700 Sourcetree dbBlobVersion() failed for a non-existent database
[This block repeats several times]
default 22:39:41.497292 -0700 Sourcetree TIC TCP Conn Start [8:0x600000198bb0]
[...]
default 22:39:41.746537 -0700 Sourcetree TIC TLS Handshake Complete [8:0x600000198bb0]
[CSSM error block repeats a few more times]
The CSSM errors appear to be related to MacOS keychain access, which is likely close to the root issue here. It seems that Sourcetree is trying to read keys that don't exist. (There are keys present for Sourcetree for each of the accounts I've configured.)
I've previously deleted the key in question and let Sourcetree recreate it when prompted, so it's freshly constructed. Meanwhile, I have a second GitHub account configured here (HTTPS) that's untouched and still working fine.
But... the SSH keys are on disk, so why is Sourcetree even accessing the keychain for the account that's having issues here? (Content of the password in the keychain is a UUID that doesn't match any of the local disks / partitions, plus another 16 bytes.)
MacOS 10.12.6 (Sierra)
Sourcetree 2.6.3 (which is when the problem appeared)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
A common scenario where we see this is when the ssh keys aren't added to the agent. If you have restarted your Mac recently, it is possible that the OS hasn't loaded your keys to the ssh agent. You can check this by running below command in terminal -
ssh-add -l
If you don't find your ssh keys, please add them using below command
ssh-add <path_to_key>
Hope this helps!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Manjunath, this seems to have fixed the problem, and I thank you for the solution, but it shouldn't have been necessary.
1) The SSH key worked in Sourcetree a week prior. The Mac wasn't rebooted, etc. in the meantime.
2) The SSH key and the supporting config was originally generated by Sourcetree, so this step should have been done if necessary.
3) Foremost, if Sourcetree would just allow the user to point to the key file instead of requiring the more elaborate ssh-config-file + ssh-agent + keys-loaded-into-agent + keychain-used-for-who-knows-what the whole setup would be far simpler and more obvious to maintain.
I shouldn't have to learn the nuances of the SSH subsystem to login through your product - I don't with any other (e.g., command-line git, ssh, scp, etc.).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.