Skip to content

Conversation

mrkn
Copy link

@mrkn mrkn commented Sep 19, 2025

This is a concept implementation to support SSH proxy in dstack apply comand.
I think this can be a part of #2562 and #2554.

Summary

  • Add client-side SSH proxy configuration to dev/task/service configs
  • Let dstack apply reuse those settings for ProxyJump, ProxyCommand, and AWS SSM

Liimitations

  • dstack attach still bypasses the new proxy controls, so detached runs cannot yet use them

Next Steps

  • Add cloud-specific helpers (e.g., GCP, Azure) on top of this structure

Example configuration

type: dev-environment
name: example
ide: vscode
attach:
  proxy:
    type: aws-ssm
    profile: sso-profile-name

This is a concept implementation to support SSH proxy in `dstack apply` comand.

## Summary
- Add client-side SSH proxy configuration to dev/task/service configs
- Let `dstack apply` reuse those settings for ProxyJump, ProxyCommand, and AWS SSM

## Liimitations
- `dstack attach` still bypasses the new proxy controls, so detached runs cannot yet use them

## Next Steps
- Add cloud-specific helpers (e.g., GCP, Azure) on top of this structure

## Example configuration

```yaml
type: dev-environment
name: example
ide: vscode
attach:
  proxy:
    type: aws-ssm
    profile: sso-profile-name
```
Copy link
Contributor

@peterschmidt85 peterschmidt85 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @mrkn very much for the PR.

A few questions and comments:

  1. I assume you've tested the PR end-to-end, have you? I mean submitting runs using the aws backend?
  2. I assume this won't work if dstack doesn't create (and reuse) the default EC2 instance profile that is granted with ssm permissions.
  3. I personally think that ssm should be a setting of the aws backend rather than a part of the user configuration. This means if ssm is enabled for the backend, dstack would always require ssm when attaching.
  4. I agree that it should be possible to configure AWS credentials on the client side. I personally think, as the first initial version, we could simply reply on the default AWS credentials. This gives the user 100% control over that when using the dstack CLI.
  5. Also, in my view, the attach logic cannot be outside of run.attach. The run.attach is the high-level API that should do anything what is required internally. Users may use it not via CLI but programmatically via dstack Python API (see examples).
  6. You also use ssm with jump hosts ({run_name}-jump-host) which is only required with the kubernetes backend (and has nothing to do with SSM).
  7. I wonder if the PR also works under Windows (I guess not).

Please let me know if you need more assistance with it! We're actually happy to help as this functionality is definitely important.

@peterschmidt85
Copy link
Contributor

Hi @mrkn! Will close the PR for now. Please feel free to re-open if you decide to get back to it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants