@fkelava : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Learn Build status updates of commit e5af654:

✅ Validation status: passed

For more details, please refer to the build report.

Note: Links can become broken if there are changes on the target sites.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

@TylerMSFT

Can you review the proposed changes?

When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

To summarize the issue more neatly:

Visual Studio's ConnectionManager.exe component that handles, among others, SSH connections still only accepts private keys in "old" OpenSSH format (today available from ssh-keygen with the option -m pem). The old format has been superseded in OpenSSH 7.8, released in August of 2018. See the first entry under 'Potentially-incompatible changes'.

The problem is not so much the fact that ConnectionManager rejects these keys as the fact Visual Studio does not make this clear in any way. In Visual Studio, if you are trying to add a SSH connection through the 'Connect to Remote System' window, you will instead see a message of 'Failed to negotiate host key algorithm. Only RSA and DSA host keys are supported.', which is in this case entirely incorrect. The article I seek to edit talks at length about VS' supported ciphers and key/kex/MAC algorithms starting from v16.9, but does not mention this private key requirement.

It is mentioned in Set up FIPS-compliant secure remote Linux development, but I find it unintuitive that a general requirement for all private keys should be found in an article concerning FIPS compliance.

Making this clear in the documentation is merely a stopgap, but the issue should be properly resolved by finally updating ConnectionManager to be capable of handling keys OpenSSH produces by default for -t rsa for a solid four and a half years now.

I am open to suggestions on rewording this, placing it in a better position in the article, or reworking it in any way you deem fit.

#sign-off

Well I am currently ratholing into this issue and using -m pem is not actually converting into a PEM key.

If I haven't misread the man page, it seems the equivalent command is now ssh-keygen -e -f <FILE> -m pem. Does that work?

If so, I can amend the docs again.

do_convert_to_pem: unsupported key type ED25519 seems not.

I did get it to eventually work by making a new key, but it was pointless because debugging a self contained .NET binary remotely doesn't work anyway.