Auto generate profile from .ssh/config

[hanxi]

Description of the new feature/enhancement

Dynamic profiles like "Windows.Terminal.Wsl", "Windows.Terminal.Azure", "Windows.Terminal.PowershellCore"

eg:

If .ssh/config like this:

Host 251
    HostName 192.168.29.251
    Port 22
    User hanxi
Host 252
    HostName 192.168.29.252
    Port 22
    User hanxi

Then generate profile like this:

  {
      "guid": "{a060905f-d089-43d9-9422-cd748e7f0230}",
      "name": "ssh251",
      "commandline": "powershell.exe ssh 251",
      "closeOnExit" : true
  }
  {
      "guid": "{a060905f-d089-43d9-9422-cd748e7f0231}",
      "name": "ssh252",
      "commandline": "powershell.exe ssh 252",
      "closeOnExit" : true
  }

Proposed technical implementation details (optional)

Also support disabledProfileSources setting.

"disabledProfileSources": ["Windows.Terminal.Wsl", "Windows.Terminal.Azure", "Windows.Terminal.PowershellCore", "Windows.Terminal.SSH"]

If OpenSSH not installed, then auto disable "Windows.Terminal.SSH" .

[zadjii-msft]

I don't hate this. What I'm most worried about is the full path to .ssh/config - how consistent is that across various different methods of installing ssh? I'm worried that there's different paths for the built-in ssh, vs the version you'd get from the win32-openssh github repo, vs the one you'd install from winget, vs the one from scoop, vs chocolatey, vs git bash.... and now the logic gets way funkier.

That being said, I could be entirely wrong and it might just be a static path. That would certainly make this easier.

[hanxi]

@zadjii-msft I test this ssh version use .ssh/config from %HOMEPATH%/.ssh/config

• built-in ssh
• win32-openssh github repo
• winget no openssh
• scoop install failed
• chocolatey install failed
• git bash

So I think .ssh/config is a static path.

[skyline75489]

Do we still accept new profile generators? I thought we have moved pass that period. That being said I don't hate the idea, either. Also I'd love to see #7774 landed.

[zadjii-msft]

I'm thinking that this is one of those cases where a proto-extension actually won't work super well. They've got their config in this file already, but then would need to add another service to watch that file for changes. That's the only way I could imagine changes to that file being automatically picked up and turned into new profiles. Plus, I really doubt ssh as a project would ship anything like a proto-extension.

So this one seems simple enough, and with win32-openssh being shipped in-box, it's first-party enough. I'll bring it up in team discussion Monday, but this seems like a good idea to me.

[skyline75489]

@zadjii-msft I'd argue Visual Studio is also first- party. But generally I see what you mean.

[zadjii-msft]

@skyline75489 VS definitely is first party, which is why we're gonna try and get that PR merged this month 😉

[DHowett]

This will be an excellent first-party extension. I'm hesitant to do it as a built-in generator (since I don't think we need more of those), but it can come in soon after.

[mveril]

Currently I mainly use ssh through WSL to connect me to servers. I use custom profiles for that.
It would be interesting to be able to choose if we want to generate profile for ssh from windows or from WSL.

[Kytech]

I also find myself adding SSH configs to my terminal profiles regularly. However, it could be nice to have a way to setup an includelist/excludelist since I have some configs that just alias some server addresses to a nicer name, but I would have an unusually long profile list if I couldn't opt-out/opt-in which profiles are displayed. That sort of mechanism may be useful for other profile generators as well in case people want to have even finer-grained control over them. I also have some ssh configs that "chain" options (ex. a profile that applies to all 10.0.1.* servers), so I wouldn't necessarily want those kind of configs to show up and a include/exclude list could help with that. Another alternative would be only adding profiles for ssh configs that have a HostName field.

Another thought on this: Since people may have a number of different openssh installs/install locations (as mentioned above), would this just default to using the openssh version in their PATH? That would make sense, though I know that some people may use the git bash/git-bundled ssh along with its agent, which reads from the same .ssh\config as the built-in OpenSSH, but don't share agent-held keys without some extra configuration since each of these SSH installs has its own agent. Those may want to point their profiles to the git-bundled ssh executable if they use the git-bundled ssh's agent. I'm thinking we could make those profiles take an alternate ssh executable path as the commandline config option, or we can have the feature stick to relying on whatever is in the PATH environment variable and document that behavior somewhere. It's easy enough to choose which ssh version you want by placing it higher up in the PATH list and it should work out of the box for most people since most default Windows installs will have some SSH executable in their path.

[hanxi]

I found a plugin in vscode for ssh. It use .ssh/config file.

https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh

[OlafvdSpek]

  "commandline": "powershell.exe ssh 251",

For anyone trying this with MS PS, the cmd is pwsh -c ssh <host>

This feature would be nice to have.

[mrtnd]

Plus 1 on that one. I would very much appreciate such feature! I use vscode and terminal pretty much every day for remote development etc. VSCode already uses the .ssh/config. Terminal doesn’t. Which means I need to maintain two different config files. Kinda inconvenient. How is the progress going btw?

[zadjii-msft]

How is the progress going btw

There's no one currently working on this. If you'd like to contribute, I think we'd welcome the contribution.

There may be some continued debate as to whether this should be bundled with the application or supported as a "3rd party" extension. At the moment we don't really have a LoS on 3rd party extensions like this though. I'm in the camp of "probably okay to ship with the Terminal for now".

[ffes]

I see that #14042 is opened to fix this. Great that someone put in the work!!!

But with over 20 hosts in my .ssh/config that is going to pollute my menu very much. I hope that my suggestion mentioned in #1571 (comment) gets solved before that PR lands.