"Add New SSH Host..." option overrides valid ssh config

[rjra100]

When adding a host with the Add New SSH Host... option, Remote-SSH adds a block to the start of the .ssh/config file:

Host myhost
    HostName myhost

My ssh config uses Teleport. This contains config along the lines of

Host *
    User <username>
    <other general host setup>

# Flags for all hosts except the proxy
Host * !dev.mydomain.com
    ForwardAgent yes
    Hostname %h.dev.mydomain.com
    IdentitiesOnly no
    ProxyCommand "C:\Program Files\Teleport\tsh.exe" proxy ssh --cluster=dev.mydomain.com --proxy=dev.mydomain.com %r@%h

The effect is that the Host block added by Remote-SSH overrides the HostName entry in the Teleport config (SSH takes the value from the first Host block which matches the host it's connecting to). The end result is that it gets confused about the hostname, gives a Host key for <hostname> has changed and you have requested strict checking error, and fails to connect.

Moving the generated Host block after the Teleport config, manually adding the domain to the generated HostName, or entirely deleting the HostName line all work around the problem.

I'd suggest that:

• It's a bit strange for a VSCode extension to use my .ssh/config file to note the hosts it knows about in the first place...
• If it must do so, it really shouldn't override my settings. An empty Host myhost block appears to be sufficient to keep track of the existence of the host.
  • If the intent is simply to keep track of known hosts, it would probably make more sense to put them at the end of the file where they're less likely to interfere with "real" settings. Note that SSH configs take the values from the first host block that matches, not the last.

[rjra100]

A colleague pointed out that if the Teleport config is moved into a separate file (e.g. teleport.config) and referenced with Include teleport.config, then Remote-SSH puts its Host blocks after the Include, where they don't interfere.

I still think it's strange to add these blocks to the config file, but at least this gives a way to work around it without manual intervention each time a host is added.

[joshspicer]

Thanks for the feedback. In case it's helpful, for one-off connections you can use Remote - SSH: Connect to host. This will let you type in your ssh connection command but will not add it to the config.

Is your suggestion that we should continue honoring the SSH config but never modify it (read but not write)?

Is it not clear that Add New SSH Host... would modify to your configuration? On my machine the final prompt of the Add new SSH Host asks which config i'd like to update, does that not happen on your machine?

Screen.Recording.2025-01-17.at.10.40.25.AM.mov

If it must do so, it really shouldn't override my settings. An empty Host myhost block appears to be sufficient to keep track of the existence of the host.

I suppose we can change the ordering of applying to the configuration, but I suspect that people would have different definitions of what is the "right" spot. I think the intent of this feature was to make it more convenient by not diverging what you use in VS Code from what you'd use outside of VS Code. Looking forward to hearing more of your thoughts

[rjra100]

Is it not clear that Add New SSH Host... would modify to your configuration? On my machine the final prompt of the Add new SSH Host asks which config i'd like to update, does that not happen on your machine?

Yes, it does that (though - separate issue - the locations it suggests include C:\ProgramData\ssh\ssh_config, which my normal user account doesn't have write access to, and the "specify a custom configuration file" option doesn't appear to actually do anything).
It's clear enough that it's going to modify my ssh configuration, but it's not entirely clear to me why it's doing so. What I think I think I'm doing by adding an SSH host is telling VSCode that this is a machine I'm going to be connecting to fairly regularly and I'd like it to stay in the connections dropdown; I'm certainly not expecting it to make changes to how it connects. I've also noticed that a lot of colleagues don't realise that it's possible to connect without explicitly adding the host first; the UI does rather encourage doing so.
Based on my assumption, there's no reason it has to be kept in the SSH config; I'd rather regard setting that up as beyond the scope of a VSCode extension. Were I starting from scratch, I think I'd expect that information to go in VSCode's own settings database; however, it is where it is and there's probably no point changing that now.

Is your suggestion that we should continue honoring the SSH config but never modify it (read but not write)?

I'd certainly retain the behaviour of listing hosts that have their own blocks in the SSH config at this point. Given where we are, allowing it to create Host blocks in there is probably reasonable, but I don't think those blocks should automatically have settings included. I think I'd suggest, rather than adding Host x...HostName x, it should just add an empty Host x block (at the current location). That appears to achieve the desired effects of adding it to the dropdown and making it clear where any host-specific settings go, without actually messing up any higher-level settings. Regardless of where it's placed, that won't interfere with anyone's config unless/until settings are explicitly added to the block, and anyone fiddling with their ssh config can probably be expected to understand what they're doing and move it to the right place if necessary.

TL;DR: Just don't override the HostName setting, everything else is probably fine as is :)