SSH, HTTPS, and Proxies

GitKraken can connect to repositories hosted on most services (like TFS, Bitbucket Server, custom service, etc), over HTTPS or SSH.

When working with remotes, certain actions like Clone, Fetch, Push and Pull require authentication. Here we cover the common methods to enter the remote URL to ensure a successful connection.


HTTPS

The most common and default way to interact with a remote repository, HTTPS configuration will always require your Git username and password credentials.

The standard protocol is entered as a remote in the format below.

https://example.com/username/myrepository.git

By default when cloning a repo using HTTPS, your remote tracking at origin will be set using this format.


SSH

In Preferences Authentication GitKraken manages credentials for SSH Defaults and Integrations.

GitKraken can generate a key for you automatically in defaults and on integrations. Since GitKraken uses its own bundled copy of an SSH library, nothing needs to be configured outside of the app.

The standard protocol can be entered as a remote in one of following formats:

ssh://{user}@{host}/{repo}

or

{user}@{host}:{repo}

where

  • {host} can be example.com
  • {user} is the username (git by default)
  • {repo} is myrepository.git

Note: {repo} usually has an owner like a user or organization where the repository is located on which ssh://{user}@{host}/{owner}/{repo} would be used.

For example, the original HTTPS URL in SSH is formulated as

git@example.com:org/username/myrepository.git

By default when cloning a repo using SSH, your remote tracking at origin will be set using this format.

Custom SSH ports

To use a custom SSH port, you need to use the ssh:// format for your SSH URL.

ssh://{user}@{host}:{port}/{repo}

Local SSH Agent

"Never send a human to do a machine's job."

A local SSH agent handles key communication with your remote host, without needing a passphrase.

With SSH, it's not uncommon when working with many projects, and separate profiles that you need different credentials.

While you can specify a single SSH key pair as a default, and even have dedicated defaults per profile, it may be preferable to check Use local SSH agent and have the keys managed externally.

This way, provided your keys are loaded, every action requiring a chat with your known hosts can manage providing l33tp@$$..&3 for success without your keyboard involved.

100% of the time, it works every time.

I'm having an SSH issue.

Well if it's not working 100% of the time, the most common issues are:

  • SSH-agent on Windows — GitKraken currently only supports Pageant for the SSH agent for Windows.
    • You can download PuTTY and Pageant from their page here.
  • Misconfigured SSH settings — remote URL format
    • Check in Preferences Authentication to confirm that your SSH settings are correct.
    • Edit remotes in the left ref panel to ensure push and pull urls are set and in the correct format
  • Expected use of SSH config — GitKraken does not currently respect your SSH config and cannot make use of any remote server nicknames or identities.
    • You can either load your SSH key directly into GitKraken or use your system’s SSH agent to authenticate with your remote.

Proxy configuration

GitKraken supports proxies for Windows, OSX, and Linux. GitKraken should recognize your proxy settings by default, however please review the additional instructions below if you are using an authenticated proxy such as basic, NTLM, Negotiate, or Digest.

Windows

For Windows users, your Windows machine will prompt for your proxy credentials on GitKraken’s behalf. Enter the credentials to complete the proxy configuration with GitKraken.

OSX

If you’re using an authenticated proxy on OSX, GitKraken will directly ask for the proxy credentials. Enter the credentials to complete the proxy configuration with GitKraken.

Linux

If you are using an authenticated proxy on Linux, Gitkraken will directly ask for the proxy credentials. Additionally, you will need to run GitKraken with the command line flag:

--proxy-server=10.200.0.1:8080

where 10.200.0.1 and 8080 are the proxy IP and proxy port respectively. Without this flag, OAuth integrations are subject to fail.