The Issue
Recently, I helped troubleshoot an intriguing GitHub issue. A developer was able to clone a repository using SSH successfully, however encountered this error when attempting to push:
someone@machine somefolder % git push origin features/[some branch]
Enter passphrase for key '/Users/[user]/.ssh/id_rsa':
ERROR: The '[github organisation]' organization has enabled or enforced SAML SSO.
To access this repository, you must use the HTTPS remote with a personal access token or SSH with an SSH key and passphrase that has been authorized for this organization.
Visit https://docs.github.com/articles/authenticating-to-a-github-organization-with-saml-single-sign-on/ for more information.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Why Clone Works But Push Fails
This scenario differs from the typical SAML SSO authentication issues I’ve written about in cracking the github code a heartfelt saga of ssh keys sso and cloning victories. The challenge was: Why could the user clone a repo but was not able to push to that repo?
The resolution is in the understanding GitHub’s permission model for forked repositories within organizations that enforce SAML SSO.
The Cause
The repository in question was special in two aspects:
- It was a fork of another repository
- The fork resided in an organization with SAML SSO enforced
When an GitHub organization enables SAML SSO, it requires additional authorization for SSH keys to access organization resources. Authentication with SSO explains that while certain public repository operations like viewing the repository overview and performing read operations via Git (e.g. cloning) don’t require IdP authentication. Other access to public repositories (the fork was public) — including viewing issues, pull requests, projects, and releases — does require authentication. Using the API or Git on the command line to access protected content in an organization that uses SAML SSO, you need to use an authorized personal access token over HTTPS or an authorized SSH key.
This explains why cloning succeeded while pushing fails without proper SSH key authorization for the organization.
The Solution
To resolve this issue, the user did authorize their SSH key for use with SAML single sign-on as described in Authorizing an SSH key for use with SAML single sign-on.
Please note that the error above recommends a different documentation: Authenticating with single sign-on. Authorizing an SSH key for use with SAML single sign-on is also listed in Authenticating with single sign-on though.
Important Notes
- You must authorize your SSH key separately for each organization with SAML SSO
- The authorization links your SSH key to your SAML identity
- You’ll need to repeat this process if you generate a new SSH key
- The local ssh agent must have loaded the authorized SSH key
Leave a Reply