Accounts and credentials

Where every credential Innesta holds is kept, and where each one is entered.

Innesta holds three kinds of credential, and all three live in the macOS Keychain:

  • HTTPS credentials — the username and personal access token Git uses for a repository cloned over HTTPS.
  • SSH passphrases — for a key that has one.
  • OAuth tokens — the access and refresh tokens for a connected GitHub or GitLab account.

Nothing is kept in a preferences file, and nothing is kept in the repository.

An SSH host key you trust is not a fourth kind: OpenSSH keeps that one, in your own known_hosts file, and the approval you gave it is not stored at all.

The Accounts tab

Innesta ▸ Settings… (⌘,) → Accounts is a direct editor for those Keychain items, one at a time. Choose which kind you are entering — Git HTTPS Credential, Provider API Token or SSH Passphrase — give the host and the account it belongs to, and Save.

The other two buttons do different amounts of work, and it is worth knowing which. Test Access, which an HTTPS credential gets, actually contacts the remote rather than checking that the fields are filled in, so a token that is going to fail fails here instead of during a push. Verify, which the other two kinds get instead, looks no further than the Keychain: Credential found means there is an item under that host and account, and nothing has been asked of the server. Delete removes the item.

The account for an HTTPS credential does not have to be a real username. A token label works, and so does x-access-token: it is the name the Keychain item is filed under, not something the server is told.

Connecting an account is somewhere else

An OAuth account belongs to a remote rather than to the app, so it is connected from that repository’s own settings — the gear beside the repository name, then Remotes. Provider Access there has the Status of the current one and a Connect button, which reads Reconnect once there is something to reconnect.

Onboarding offers the same step, for the repository you start with.

What else is on that page

  • A manual provider token for GitHub Enterprise Server, which does not do OAuth.

  • An OAuth application for a self-hosted or Dedicated GitLab: its Instance URL and Client ID, indexed by full base URL so that several instances can be configured at once.

    Both of those are a tutorial of their own.

  • A provider override. Detection reads a remote’s URL; where that is not enough — a GitHub or GitLab instance on a domain of its own — a picker appears offering Automatic, GitHub or GitLab, and the choice persists. It is shown only for a remote whose host Innesta could not place, because for the rest there is nothing to decide.