-
Notifications
You must be signed in to change notification settings - Fork 881
Use wildcard SSH host names #14986
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Another alternative that at least partially works around the slowness, in JetBrains we could only add hosts to the config for the currently connected workspace and any in the recent connections, instead of blindly adding every single one. A wildcard would be nice but maybe this could be a temporary bandaid. |
Or, if we actually parse the host names, we can more smartly update the config and only make requests for workspaces that are new. Currently we interact with the config as one big block, so we have to update the whole thing at once as we have no knowledge of what might need to be added. I think wildcard would still be nice, but if we decide to take one of these other routes I will create an issue in the JetBrains repo instead and close this one. |
Another alternative, if the main workspaces query included all the agents even for off workspaces, this would at least make it faster probably, giant SSH config notwithstanding. |
I enjoy this idea and think we should strive for one opinionated method for SSH configuration. The one drawback to wildcards (which might be a worthwhile cost) is users lose autocomplete when typing |
Great point, I had not considered that. Hmmm maybe we can provide completions to compensate ( |
Ideally we would keep all completions coming in through |
Oof 🤦 I missed that. Yup, makes sense. |
Is there a way to do dynamic completions? Like can the autocomplete do a |
Yup, it can be shell-dependent, but with Bash for example you can generate completions with: _ssh()
{
local cur opts
cur="${COMP_WORDS[COMP_CWORD]}"
opts=$(coder ls --column workspace | tail -n +2)
COMPREPLY=( $(compgen -W "$opts" -- ${cur}) )
return 0
}
complete -F _ssh ssh In use:
We may also need to read the SSH config to get other hosts, since it looks like this replaces completions rather than augments them. 🤔 Edit: in my workspace, We could make the workspace list static to avoid an API call every time you |
Yep, you can override the completion handler in serpent to do it all without touching any shell :) |
Can it do it for a different command though or does it only work for itself? (Since we want completions for the regular |
Not override, sorry, it used to override. You can specify a handler on the command, and that handler gets run in addition to the one that completes flags and additional arguments - if that's what you mean. |
Ah yeah if I understand correctly, that can be used to add completions for itself (the Basically we want it so when you type Or, at least, I think that is what we want. |
Unassigned from myself for now due to time constraints, if this gets reassigned and it is not me then please let me know, happy to chat with whoever gets it to make sure my thoughts came across correctly, and I want to make sure whatever comes out is usable for the plugins. |
ahh yeah I see, my bad! |
If the argument to `coder ssh` fits the pattern `<prefix>--<owner>--<workspace>--<agent?>`, then parse this instead of treating the argument as a literal workspace name or `<owner>/<workspace>`. This will enable the use of `coder ssh` for the VS Code and JetBrains plugins in combination with wildcard `Host` entries in the SSH config. Part of coder#14986.
@spikecurtis will this functionality change how Coder Desktop works? |
With Coder Desktop, it won't be necessary to use the However, CoderVPN uses |
This adds a flag matching `--ssh-host-prefix` from `coder config-ssh` to `coder ssh`. By trimming a custom prefix from the argument, we can set up wildcard-based `Host` entries in SSH config for the IDE plugins (and eventually `coder config-ssh`). We also replace `--` in the argument with `/`, so ownership can be specified in wildcard-based SSH hosts like `<owner>--<workspace>`. Replaces #16087. Part of #14986. Related to #16078 and #16080.
@bcpeinhardt, Can you help me decide if it's not already done? Thanks. |
@matifali I would say the title of the issue (use wildcard SSH host names) is complete in 2.19 of Coder, but there's other work present in the comments worth looking at (mainly Spikes point about our current configuration not really following the semantics of DNS order). I wonder if we already have an issue for that 🤔 |
Thanks @bcpeinhardt. Yes, for following the semantics of DNS, we now have #16828. Also, tagging @ThomasK33 to have more context on why we are switching to a suffix. |
This broke so many things for us. This should have been optional. |
@octoxan Can you tell us any more information about what broke and how? |
@spikecurtis There are many tools we use (Tabby, Tinkerwell, etc and various automations we've built) that give you an option to connect to different remotes by parsing your ~/.ssh/config. Before it was very easy to not have to maintain this list manually in every single app as the way Coder was doing it before worked universally across many tools. Now when I go to start working on a project I need to manually add it to half a dozen different apps manually. Also, this update made it so we have to delete every single workspace connection in the Jetbrains plugin and recreate them. It no longer connects to any saved workspaces that were added to Jetbrains Gateway prior to 2.19, which is a major pain when you have so many workspaces. Here's Tinkerwell for one example of an app, which used to have a nice drop down of 100+ connections I could use automatically, and now this list needs manually added to and things removed all the time. Some flag to not do the wildcard and do the verbose method would save all of us over here a great deal of time lol |
I would like to propose that we configure SSH with a wildcard instead of individual host names. For example:
And in
ssh.go
we trim out thecoder.
prefix.Mainly, this is to support the IDEs. VS Code already does this with a special
vscodessh
sub-command but I think we should roll that up intossh
, then JetBrains can also benefit.The main reason is that the IDEs support connecting to anyone's workspace (for admins). That means potentially hundreds of SSH config entries, and potentially hundreds of calls to template resources, since that has to be done for every workspace, at least the ones that are off, to get the agent names.
It would eventually remove the need for the Gateway and VS Code plugins to implement their own versions of
config-ssh
as they currently do, but this would need one more tweak to include the deployment URL in the host (for examplecoder-vscode.dev.coder.com--*
is generated by the VS Code plugin).It would eliminate the resource fetch loop in
config-ssh
as well.As one data point, I tested with 138 off workspaces and configuring SSH took 20 seconds.
Alternatives:
idessh
sub-command that does this, maybe just renamevscodessh
and add a deprecated alias, but I believe it also has some VS Code-specific logic that would need to be figured out.config-ssh --wildcard
andssh --wildcard
or some such).config-ssh
for now, and addssh --strip-prefix=coder-vscode.dev.coder.com--
or some such flag to at least allow the IDEs to configure their own wildcard host.Edit: I presented the prefix flag as an alternative, but actually no matter what we will need a prefix flag for
ssh
because we want unique hosts for the plugins so they can add different SSH configuration if necessary (for example the session type env var, although that is deprecated). I also learned thatconfig-ssh
already has anssh-prefix-host
flag, so it makes sense to add that same flag tossh
. Then we can useProxyCommand coder ssh --ssh-prefix-host coder-gateway.dev.coder.com. %h
and emit a single wildcard entry in the plugins.I think we should still eventually change
config-ssh
to use wildcards, and switch the plugins to useconfig-ssh
instead of replicating that effort, but that can be done later.The text was updated successfully, but these errors were encountered: