Provision owner's ssh key to their devtainers

[struanb]

Currently, users' passphrase-protected keys must be provisioned to devtainers using a shared volume mounted at ~/.ssh, and specified within the profile. The user must type ssh-add ~/.ssh/<their key> within a terminal to add their key to the ssh agent that Dockside launches within their devtainer.

Create a generalised system for managing users' ssh keys and deploying (and undeploying) them to devtainers.

This should comprise:

• Each user's public and private key being added to their entry in users.json

And some of the following:

1. Dockside deploying the owner's key to their devtainer at ~/.ssh (with file ownership matching ideUser) on devtainer launch; automatically updating the key files on all owned devtainers, if/when the key be changed.
2. Dockside adding the owner's key to the devtainer's ssh-agent when the devtainer is started (potentially needing a mechanism for obtaining the passphrase that may be used to unlock the key).
3. Dockside launching one ssh-agent process not for each devtainer, but for each user; providing each devtainer that a user launches with access to the owner's ssh-agent; adding the owner's key to their ssh-agent when required (potentially needing a mechanism for obtaining a passphrase to be used to unlock the key).

[struanb]

No. (3) is complicated, and limiting unless there's a way to reassign which ssh-agent process is associated with the devtainer at any one time.

No. (1) is simplest. Note that ~/.ssh should be a mounted tmpfs or per-devtainer volume, to avoid risk of keys being committed to an image.

No. (2) is probably the next easiest of these options. With a single ssh-agent per devtainer it's still possible for Dockside to manage the keys available in that agent, e.g. zeroing keys from the agent in certain circumstances. There is no need for Dockside to write keys to ~/.ssh - or any other path - though it could additionally do so as an option.

Contrary to the original issue text, provisioning users' preexisting passphrase-protected keys may not be the most secure way to do things. It would be more secure for users to use dedicated keys generated for the specific Dockside use case. To simplify an initial implementation, such keys could then be allowed to be un-passphrase-protected, as they would not be expected to be ever transferred off the Dockside server. Assuming so, and to simplify set up for an organization, such keys could be generated by Dockside for each user. Potentially, such keys could be stored in a separate table to users.json to allow each user to be associated with different keys for different projects or git paths. But one key per user might be a reasonable first case.

As an alternative to per user keys, per project keys may be required. If so such keys could be stored in a separate table and selected according to the best matching git URI domain and path prefix to the git repo specified in the profile all devtainer launch data.

[struanb]

An implementation of (2) above, with potential for support for (1) above, has been committed to https://github.com/newsnowlabs/dockside/tree/devel-gitlaunch-20241007-1 with commit f9d7993.

This prototype assumes dedicated non-passphrase-protected keypairs are stored in users.json. The keys for a devtainer’s owner will be added to the devtainer’s ssh-agent when the devtainer is launched or started. This facilitates accessing private git repos within the devtainer (either via terminal console or directly from the Theia IDE).

It can also be used (via a new Profile option) to launch a devtainer directly from a stock docker image and any private (or public) Github repo, which will be cloned into the devtainer during its initial launch. This makes it easy to use Dockside for private repo development and for launching devtainers from any Github repo.