Ssh Keys in Vault

This wiki pages discusses modifications necessary to store an ssh private (and public key) as a secret in Vault.

SshKey

The SshKey class has a couple of problematic behaviors for this use case:

• There is an assumption that there is always an on-disk file containing the private key; see SshMixin below for how this gets used.

Recommendations:

• Document the key_path property and indicate that it is permitted to be None
• Add an add_to_agent method to add a key to an agent. Note that because of the way the agent class works, this probably needs to be synchronous and block the entire carthage process.

SshAgent

The SshAgent class directly calls ssh_add on the key. Recommend instead that the agent calls a new method on SshKey to add the key to the agent.

SshMixin

Note that SshMixin has recently been modified to support the key being optional. This actually makes the following changes easier; it is recommended that master be used.

Change

        if ssh_key:
            ssh_agent = ssh_key.agent
            key_options = ("-i", ssh_key.key_path,)

to:

        if ssh_key:
            ssh_agent = ssh_key.agent
            if ssh_key.key_path: key_options = ("-i", ssh_key.key_path,)

And make sure key_options is initialized

VaultSshKey

Create a class that inherits from SshKey.

• Override key_path and return None.

• Override gen_key and make it be a setup_task that creates the key in vault.

• Create a gen_key.check_completed that checks to see if the key is already populated in vault. If so, dump the public key out to where it will be expected so that authorized key file handling works.

• Override add_to_agent to add the key to the agent and scrub the private key from memory.

Use with carthage_aws.

This approach is incompatible with AWS keypairs. Instead, use carthage.cloud_init.WriteAuthorizedKeysPlugin to populate authorized_keys on instances.