Syncing Git SSH Keys for Clustered Lookers (Looker 4.8+)

  • 17 February 2017
  • 5 replies

Userlevel 2
  • Looker Staff
  • 24 replies


Looker 4.8 introduces a change to where Looker stores Git SSH deploy keys:

  • Before Looker 4.8 — Git SSH deploy keys were stored in the server’s native SSH directory, ~/.ssh

  • Looker 4.8 and up — Git SSH deploy keys are stored in a Looker-controlled directory, ~/looker/deploy_keys/PROJECT_NAME

Note: Only Git SSH deploy keys for new LookML projects will be placed in this new directory—keys for existing projects will remain in ~/.ssh.

Required Action

You will need to make some changes if you are running Looker as a cluster without a shared storage directory (network file system). Specifically, you will need to start syncing this new directory across all nodes in the cluster. See below for more details.

You do not need to do anything if

  • Your instance is hosted by Looker

  • You host your own, single-node (non clustered) instance

  • You host your own clustered Looker but it is configured to use a shared storage directory

Syncing the New SSH Keys Directory Across Nodes

As noted above, the changes described here are only necessary if you are 1) running Looker as a cluster and 2) are not using a shared storage directory.

Also as noted above, previously-synced SSH keys will continue to function and remain in the same location (~/.ssh).

In order to sync Git SSH deploy keys for new LookML projects, follow these steps:

  1. Stop the script you are using to synchronize SSH keys across nodes in the cluster.

  2. Identify the directory from which Looker runs (this is commonly /home/looker/looker).

  3. Locate the portion of your existing syncing script(s) which specify the directory where SSH keys are stored. In the Looker-provided example script, this is WATCHDIR=/home/looker/.ssh.

  4. In your syncing script(s), replace the directory identified in step 3 with /home/looker/looker/deploy_keys (modify /home/looker/looker appropriately if you are running Looker from another location).

  5. Start your syncing script(s).

5 replies

If we make a new server and re-use a pre-existing Looker metadata DB with a pre-existing project, can we put the SSH key from the old server in the new location (~/looker/deploy_keys/PROJECT_NAME) or does the metadata DB have some memory of where to look for the SSH key? We would strongly prefer to just put the key in the new location, for projects old and new, so that there’s only one way to do things.

Userlevel 2

Hi @Patrick_Barry,

The short answer to that is no, you cannot. If it is an old project made pre 4.8, the keys are going to have to stay in the .ssh folder. However, what you can do to have some kind of uniformity is to update the old server’s instance to 4.8+, if not already, and then reset the git connection for that project. Then you can copy that over to the new server. Let us know if you have any questions or concerns.



I have to agree with Patrick_Barry, the fact that we now have to support two different locations for different projects, keeping track of which one was created when is hugely inconvenient and doesn’t seem well thought through. I don’t actually care where the keys live, but they should all live in one place.

This is a great idea, in fact, Looker, should just automatically do this. I love our customers.

If you want all your keys in the same place and aren’t willing to wait to see if we get around to implementing the automatic migration, there is something you can do.

Just go into Looker in the project view, and re-do your git setup. That will make a new deploy key, and the new deploy key will be written to the new directory. Delete the old deploy key when you go to the git service web site to authorize the new deploy key.

Userlevel 5

Totally understand that switching to the new methodology isn’t instantaneous and that every set up is unique, but it’s worth publicly noting that Looker 4.8 introduces a new (and recommended) method of clustering; using a shared directory. There are instructions on how to set that up here.