SFTP-SSH Connector - Pursuing a working and repeatable use.

[msn2024]

Hello,

I'm completely new to the PowerAutomate Community but long in overall automation/process handling.  I'm having great difficulty getting SFTP-SSH connector to work.  The scenario:

• Using current powerautomate.com portal to compose.
• Target/remote system is running Enterprise Linux 9 (specifically Rocky Linux, but could/will be RedHat, Alma, any potential Enterprise Linux variant).
• Have found all the pitfalls for the following issues along the attempt path:
  • Generate private/public key set with the openssh (as distributed as part of the EL packaging) and using "-m pem" option that generates native RSA key content.
    • Did generate the key pair with a passphrase.
  • Calculating MD5 fingerprint for the key set via "ssh-keygen -E md5 -lf .ssh-appkeys/id_somekeyname".
  • Pasting those value results into the dialog, along with the general details.
    • Private key includes the BEGIN and END lines for the key data block.
    • Fingerprint is the 47-character series of hexadecimal values separated by colons, no algorithm prefix expressed.
    • Passphrase is entered and exposed as visible to ensure there are no typos in it for the dialog.

I am at the point where it attempts to validate the connection, and then receive this message:

Key exchange negotiation failed. clientRequestId: (UUID value)

I have observed some old posts that indicate the far end of this (my EL system) needs to support diffie-hellman algorithms, but those have been long deprecated in EL Linux distributions, and I don't get a solid pointer that this is actually the issue.

For what it's worth, I've used the private/public/passphrase combination on test systems to validate they all work in the standard ssh/scp/sftp scenarios from command lines, so I can only imagine there's some nuance or subtlety I am missing.

And another FWIW, I intend to drive this through a collective wisdom compilation process to share a full end-to-end example, both as a posting here and maybe an upstream suggestion to the keepers of the connector code to improve everyones' success rate here.

Has anyone encountered the result I've walked here, and found the next step fixed it action that I haven't found so far?

Thanks!

[msn2024]

Perhaps a solution...

On the Enterprise Linux system hosting the file to retrieve, I attempted to address the suspected cipher issue by executing:

# update-crypto-policies --set LEGACY

# shutdown -r now

That enabled/allowed old ciphers to be used, and the reboot ensures everything restarts with the intended setting.

• First test attempt failed.
• I then checked the Disable Host Key Validation checkbox in the SFTP-SSH dialog.
• Second test attempt worked.

At this point, I'd love to have some validation that either or both actions worked for someone else too.  Please follow up here with your experience if you hit this particular snag like I did...

[beejo]

I have gone down exactly the same path you did, except that I don't have control over the server's key exchange algorithms.  Presumably a Linux VM with legacy ciphers would work for me as well, but the idea of having that sort of SSH bridge gives me hives.

Interestingly, despite the connector docs claiming that only RSA and DSA are supported, I found that ED25519 works - but only with an empty passphrase and no host key validation.  Perhaps that's why they're not advertising it.

No actually good SFTP solutions here as far as I can tell.

[beejo]

Update: SFTP-SSH connector can use passphrased ED25519 keys if the private key is encrypted with aes256-cbc, e.g.:

ssh-keygen -m pem -t ed25519 -b 256 -C "<email address>" -Z aes256-cbc

I still have to disable host key validation in the connection and I'm not too happy about being open to MITM attacks, but at least it's an equal situation to RSA except with a modern (if not yet officially supported per documentation) encryption method.

Note that this SSH.NET issue report implies that forcing aes256-cbc won't be necessary when/if the SFTP-SSH connector integrates SSH.NET 2023.0.0.

Still a little flummoxed by the host key verification thing... haven't seen it working under any conditions though to all appearances the fingerprints we're using are correct.