Problem

Only the user that started the run can attach to it. Often, it can be useful to share attach access with other users. For example, to collaborate in a dev environment, or to perform maintenance on a production service.

Solution

Allow to configure who can attach to the run in the run configuration.

# This is an example, the exact syntax is to be discussed

attachable_by:
  # the specified users
  users:
  - alice
  - bob
  # all project members, current and future
  project_members: true
  # anyone who can provide a valid private key in `dstack attach --ssh-identity`
  public_keys:
  - "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC3W5mKq8x8mQqQ5tZ7f9uY2G9wYx2YV3dK0wQ8pL7xM user@example"

The default is equivalent to:

attachable_by:
  users:
  - "<run owner>"

Specifying --ssh-identity in dstack apply is equivalent to:

attachable_by:
  public_keys:
  - "<public key of the key pair from --ssh-identity>"

Run owners and project admins are allowed to update the policy in-place.

Implementation notes

Granting SSH access can be implementing by delivering all authorized users' keys, either server-generated (#3176) or user-provided (#3688), to shim and runner, or exposing them to the SSH proxy. Shim and runner should be able to handle updates of authorized keys in case the policy or project membership change mid-run.

Workaround

Manage SSH keys manually.

1. Generate a key pair and share it with all authorized users.
2. Start the run with dstack apply --ssh-identity <path-to-private-key>.
3. Attach to the run with dstack attach <run-name> --ssh-identity <path-to-private-key>.

The workaround does not support sharing access to existing runs (in-place update).

Would you like to help us implement this feature by sending a PR?

Yes