Github HTTPS Authentication Broken in 2.6.3 on MacOS 10.12.6

Maasiv October 16, 2017

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.

  • Sourcetree would not allow me to specify the key to be used, and insisted that it was configured in .ssh/config.
  • To add insult to injury, when recreating the user account from scratch, Sourcetree refused to recognize the SSH key and config file it had previously generated.  Until it decided it would.  Very inconsistent.
  • Nowhere is a tip offered that the path for a repo is different for ssh as stored in Repo | Settings | Remotes.  Instead of being https://my_login@github.com/my_login/repo_name.git, it needs to be git@github.com:my_login/repo_name.git.  No https:// prefix, 'git@' for the username prefix, and colon after the server name.

 

I realize you have a competing service to Github, but authentication should really be more robust than it seems here.

1 answer

1 vote
Manju
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 16, 2017

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

Maasiv October 16, 2017

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.

Maasiv October 21, 2017

[Duplicate removed]

Maasiv October 21, 2017

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)

Manju
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 23, 2017

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!

Maasiv October 29, 2017

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.).

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events