Fix: Rebuild PEM format for RSA private keys before passing to Paramiko

[amritupreti]

Summary

This PR fixes an issue where private keys without proper PEM formatting (e.g., from environment variables or single-line inputs) would cause paramiko.SSHException due to incorrect formatting.

Problem

When using _get_pkey_object, the code assumed that the provided private key string was already correctly PEM-formatted. However, in many automation scenarios, users may provide the key in a single line or malformed format.

Changes Made

• Added a private method _rebuild_pem() that:
  • Strips the PEM headers and footers
  • Wraps the key content to 64-character lines
  • Adds back the standard PEM headers
• Applied _rebuild_pem() only when trying to parse an RSA key (i.e., paramiko.RSAKey)
• Left DSSKey and ECDSAKey untouched to avoid incorrect formatting
• Renamed the helper to _rebuild_pem (private) for clarity
• Added a new entry to CHANGELOG.rst under Bug Fixes

Issue

Fixes #6338

[CLAassistant]

All committers have signed the CLA.

[cognifloyd]

I'm inclined to close this as "won't fix".

StackStorm should preserve user input exactly as it received it. If it is not, then we should fix that bug.

Changing user input like this brings a lot of risk to the StackStorm project.

First, it adds a lot of security risks. The security implications of mangling user input like this are staggering. If the key the user entered is not the key used, then I would consider that to be a significant security vulnerability that requires a security patch, possibly even requiring a CVE. I don't want to trigger security scanners that look for any changes to security sensitive files such as private keys. If the key cannot be shown to be exactly what the user provided then the reliability and provenance of that secret has been broken.

Second, mangling user input causes a maintenance nightmare for a project that, like so many other community-driven open source projects, is short handed. If users encounter errors logging in, and in debugging we find that StackStorm has changed the input somehow, then it is easy to stop there and just blame StackStorm instead of looking farther to understand why the key is not working. Anyone upset about StackStorm mangling input would be justified in their anger. We are likely to get regression reports of private keys that worked with paramiko before but break after making a change like this. Any time you mangle user input, you're asking for hidden, difficult to debug, bugs.

Third, the implementation in this PR introduces serious bugs. For example, the new method assumes that all private keys are RSA format, but, the callsite is in a loop that explicitly works with DSA and ECDSA, not just with RSA.

Fourth, security formats change over time. So there will probably be a new version of paramiko that supports a newer private key format. Any key-mangling logic would have to be updated to support whatever that new format is. Not only that, but whoever works on that would have to read RFCs and other specs to ensure they support all variations of that new format, or at least all that paramiko supports. We should leave this maintenance burden on paramiko keeping the glue code in st2 as minimal as possible.

Fifth, if you are running StackStorm in an environment where you need to support mangling user input, you have 3 options, that I can see, that are supported today: (1) create a wrapper workflow around the action that uses the key and add action(s) that clean up your typical user input before passing it on to the underlying action that needs that input. (2) Create a fork of the python action that uses the private key, subclassing the original action to add user input cleanup before passing the key to the original scroll. (3) Have the users use the st2 cli to load their private key, encrypted, in the datastore, and then have them paste {{ st2kv.user.my_private_key }}.