Compliant Kubernetes Service documentation has moved

Please note: You are not reading Kubernetes documentation. If you're looking for Compliant Kubernetes Service documentation, it has moved. Read more here.

The Platform SSH Keys

There are two types of SSH keys that you can setup in The Platform: user keys and deploy keys. These two types, the differences between the two, and in what situations you would choose deploy over user are described below.

It is important to note that in older releases of the Platform, Datica only allowed one type of SSH key. Those keys were generically named keys. With the launch of The Platform, these keys were automatically converted to a deploy key. If you’re looking to switch to user keys, check out the Make the Switch section on how to do that and troubleshoot any issues you may run into.

User Keys

User keys are the preferred type of keys for the majority of Datica users. User keys allow you to access any Datica git repo that belongs to a service within an environment that you have access to. For example, let’s say Alice is a Datica user with two environments: production and development and each environment has two services named app01 and app02. A user key will grant Alice access to all services in both environments. Alice can access app01 in production and development as well as app02 in production and development with nothing more than a single user key.

User keys are intended to be private and not shared with anyone. These keys are tied to your Datica user account and can be used for authentication with the Datica APIs or as a method of pushing code to the Platform.

Deploy Keys

Deploy keys are much more restrictive than user keys. Deploy keys give an entity access to a single service in a single environment. Deploy keys are not tied to a user account, but tied to a service instead. The primary use for a deploy key is with a CI/CD server. Deploy keys are intended to be used by automated components of your infrastructure with a single purpose of pushing code to one repository.

There are few situations in which deploy keys are better suited than user keys. Primarily they are used with a CI/CD server such as Codeship, Jenkins, or TeamCity. It is important to note that deploy keys must be globally unique. It is also required that all deploy keys be different than your user keys.

How can I setup user keys on my account?

To execute the commands below, you’ll need to specify your Datica email and password, so be sure to have them available.

Download The Platform CLI

All SSH key management will be carried out through The Platform CLI. Get it here.

Generating New SSH Keys

If you need a new keypair, follow the instructions below for your operating system. If not following the instructions, note that your key must be an RSA, PEM-encoded key.


Using either Git for Windows and Git Bash or the Windows Subsystem for Linux, follow the Linux instructions below.


ssh-keygen -t rsa


For Mojave and newer:

ssh-keygen -t rsa -m PEM

For older versions:

ssh-keygen -t rsa

Add a Non-Shared Public Key to Your account

Do not use shared public keys for access to your Datica account. Your SSH keys should be private.

Below, I add a new SSH key that I made for a Datica environment

datica -E "<your_env_name>" keys add my_prod_key ~/.ssh/

Once that is done, you can list your public keys and see the key you just added

datica -E "<your_env_name>" keys list

How can I use an SSH key for authentication in the CLI?

To use an SSH key for authentication in the CLI, it must be added as a user key. After adding a user key as outlined in the previous section, set that key as the authentication key with the CLI. Be sure to specify the private key path when using the keys set command.

datica -E "<your_env_name>" keys set ~/.ssh/prod_rsa

You can now execute CLI commands without using an email/password!

How do I add a deploy key?

Before adding a deploy key, please make sure to read the sections above on the specifics of user keys vs deploy keys. To add a deploy key, you’ll need the CLI. Now run the deploy-keys command

datica -E "<your_env_name>" deploy-keys add codeship_key ~/.ssh/ app01

You can now use the codeship_rsa key pair with your CI/CD server to push code to Datica!

SSH Keys and ssh-agent

Git will use ssh-agent to present an identity to the git repository. The ssh-agent program will use the default ssh key file named id_rsa in the .ssh directory of the user’s home directory (~/.ssh/id_rsa). Only the default id_rsa key file will be loaded by ssh-agent unless the key is manually added to the agent. The OS X Keychain Access application can be used to load additional ssh keys when the ssh-agent starts. To add a key to the OS X KeyChain Access application, use the command ssh-add -K <path to ssh key file> For example: ssh-add -K ~/.ssh/catalyze-prod.key.

Similar tools are available for Windows (Pageant) and Linux (keychain) workstations. On Linux, the ssh-agent program can be added to your bash profile to start when bash loads.

Make the switch

After the launch of The Platform or when migrating to a newer environment, you’ll need to switch from using deploy keys to user keys. There’s a few steps required in order to use an existing deploy key as a user key. First, be sure to remove all existing deploy keys

datica -E oldEnvironment deploy-keys list
datica -E oldEnvironment deploy-keys rm {keyName} {svc}

Next, run datica init.

datica init

Lastly, add the recently removed deploy key as a user key and push code.

datica -E newEnvironment keys add default_key ~/.ssh/id_rsa
git push datica master

If necessary, reset your SSH agent and add in your default rsa key

killall ssh-agent
ssh-add ~/.ssh/id_rsa

You can now use your default rsa key (~/.ssh/id_rsa) to push code to app01 in both the old and new environments.

Help! I’m getting You do not have access to the requested repository. fatal: Could not read from remote repository.

The most common error encountered when pushing code to Datica is the You do not have access to the requested repository. fatal: Could not read from remote repository. error. This can occurs for a couple of different reasons.

To start, you’ll want to make sure your SSH agent is aware of the key you want to use for your git push command. Run ssh-add -l to list all keys that your SSH agent is managing. If your key is not listed, you’ll need to add it by running ssh-add ~/.ssh/my_key giving it the path to your SSH private key.

Next, you want to make sure your SSH agent is not managing a deploy key. Run ssh-add -l to list your keys and make sure that each key listed should be there. If you need to remove a key, the only option is to remove all keys with ssh-add -D and then add the ones you need back one by one with ssh-add ~/.ssh/path_to_key. If necessary, you can use ssh-keygen -lf ~/.ssh/path_to_key to match the SHA256 hash that the CLI prints out when running keys list or deploy-keys list.

The last step you want to try is making sure that your user key is not also a deploy key. To fix this, read the Make the switch section to ensure that all of your deploy keys are unique or removed.

One of the most effective ways to debug this error is adding the -v flag to your git push command. When adding the -v flag, you can see which keys are offered by your SSH agent and in what order. Here’s a sample partial output

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/catalyze/.ssh/deploy_rsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /Users/catalyze/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/catalyze/.ssh/id_dsa
debug1: Trying private key: /Users/catalyze/.ssh/id_ecdsa
debug1: Trying private key: /Users/catalyze/.ssh/id_ed25519
debug1: No more authentication methods to try.

This shows that deploy_rsa was offered first and rejected, followed by id_rsa which was also rejected. The SSH agent attempted to find other default keys named id_dsa, id_ecdsa, and id_ed25519 but those files did not exist. At last, the SSH agent gave up and the push was rejected. This can be an extremely effective tool when fixing the Could not read from remote repository error.