starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 00:15:10 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Auto generate profile from .ssh/config #12397

New Issue
Closed
opened 2026-01-31 03:14:35 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 03:14:35 +00:00
Owner
Copy Link

Originally created by @hanxi on GitHub (Feb 4, 2021).

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" .

Originally created by @hanxi on GitHub (Feb 4, 2021). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> 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: ```json { "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) <!-- A clear and concise description of what you want to happen. --> Also support `disabledProfileSources` setting. ```json "disabledProfileSources": ["Windows.Terminal.Wsl", "Windows.Terminal.Azure", "Windows.Terminal.PowershellCore", "Windows.Terminal.SSH"] ``` If OpenSSH not installed, then auto disable "Windows.Terminal.SSH" .
claunia commented 2026-01-31 03:14:36 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 4, 2021):

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.

@zadjii-msft commented on GitHub (Feb 4, 2021): 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.
claunia commented 2026-01-31 03:14:36 +00:00
Author
Owner
Copy Link

@hanxi commented on GitHub (Feb 5, 2021):

@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.

@hanxi commented on GitHub (Feb 5, 2021): @zadjii-msft I test this ssh version use `.ssh/config` from `%HOMEPATH%/.ssh/config` - [x] built-in ssh - [x] win32-openssh github repo - [ ] winget no openssh - [ ] scoop install failed - [ ] chocolatey install failed - [x] git bash So I think `.ssh/config` is a static path.
claunia commented 2026-01-31 03:14:37 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Feb 5, 2021):

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.

@skyline75489 commented on GitHub (Feb 5, 2021): 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.
claunia commented 2026-01-31 03:14:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 5, 2021):

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.

@zadjii-msft commented on GitHub (Feb 5, 2021): 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.
claunia commented 2026-01-31 03:14:37 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Feb 7, 2021):

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

@skyline75489 commented on GitHub (Feb 7, 2021): @zadjii-msft I'd argue Visual Studio is also first- party. But generally I see what you mean.
claunia commented 2026-01-31 03:14:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 8, 2021):

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

@zadjii-msft commented on GitHub (Feb 8, 2021): @skyline75489 VS definitely _is_ first party, which is why we're gonna try and get that PR merged this month 😉
claunia commented 2026-01-31 03:14:37 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 12, 2021):

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.

@DHowett commented on GitHub (Feb 12, 2021): 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.
claunia commented 2026-01-31 03:14:37 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 16, 2021):

@wsluser i cannot determine how any of the things you said are related to this feature request. Can you explain?

@DHowett commented on GitHub (Feb 16, 2021): @wsluser i cannot determine how any of the things you said are related to this feature request. Can you explain?
claunia commented 2026-01-31 03:14:38 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 16, 2021):

Got it. Nothing to do with this discussion -- no environment variable, nothing about CMD/PSCore/PowerShell, no path to the SSH executable. I'm gonna collapse these comments as resolved-off-topic

@DHowett commented on GitHub (Feb 16, 2021): Got it. Nothing to do with this discussion -- no environment variable, nothing about CMD/PSCore/PowerShell, no path to the SSH executable. I'm gonna collapse these comments as resolved-off-topic
claunia commented 2026-01-31 03:14:38 +00:00
Author
Owner
Copy Link

@mveril commented on GitHub (Mar 3, 2021):

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.

@mveril commented on GitHub (Mar 3, 2021): 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.
claunia commented 2026-01-31 03:14:38 +00:00
Author
Owner
Copy Link

@Kytech commented on GitHub (Apr 8, 2021):

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.

@Kytech commented on GitHub (Apr 8, 2021): 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.
claunia commented 2026-01-31 03:14:38 +00:00
Author
Owner
Copy Link

@hanxi commented on GitHub (Apr 21, 2021):

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

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

image

@hanxi commented on GitHub (Apr 21, 2021): I found a plugin in vscode for ssh. It use `.ssh/config` file. https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh ![image](https://user-images.githubusercontent.com/1185757/115527146-5eef5e00-a2c3-11eb-8810-ab4b1915a18e.png)
claunia commented 2026-01-31 03:14:38 +00:00
Author
Owner
Copy Link

@OlafvdSpek commented on GitHub (Sep 11, 2021):

  "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.

@OlafvdSpek commented on GitHub (Sep 11, 2021): > "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.
claunia commented 2026-01-31 03:14:39 +00:00
Author
Owner
Copy Link

@mrtnd commented on GitHub (May 28, 2022):

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?

@mrtnd commented on GitHub (May 28, 2022): 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?
claunia commented 2026-01-31 03:14:39 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 6, 2022):

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".

@zadjii-msft commented on GitHub (Jun 6, 2022): > 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".
claunia commented 2026-01-31 03:14:39 +00:00
Author
Owner
Copy Link

@ffes commented on GitHub (Oct 5, 2022):

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 https://github.com/microsoft/terminal/issues/1571#issuecomment-519504048 gets solved before that PR lands.

@ffes commented on GitHub (Oct 5, 2022): 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 https://github.com/microsoft/terminal/issues/1571#issuecomment-519504048 gets solved before that PR lands.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Extensibility Area-Settings Issue-Feature Needs-Tag-Fix Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#12397
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?