it seems to work in the check routine of the New Credential dialog.
However: When I use the credentials in an SSH-Node I get the same error again.
When I go back to the credential the content of the Private Key field has changed to something like __n8n_BLANK_VALUE_e5362baf-c777-4d57-a609-6eaf1f9e87f6.
The same occurs when I enter the key as expression, close the credential window and reopen it again immediately. Then the check of the key fails as well.
How can I even store SSH-Keys in n8n without getting them destroyed?
Looking at your provided JSON, you are attempting to handle key files manually inside an Execute a command node using base64 decoding and shred.
Instead of managing file-based keys manually in scripts, it is much more secure and stable to store the SSH key in a proper SSH Private Key Credential in n8n and select that credential within the SSH node’s authentication settings.
If you continue to get an “Unsupported key format” even with a properly formatted PEM key, ensure the key does not have a passphrase, or if it does, ensure you have entered it correctly in the “Passphrase” field of the credential setup.
A clarification on the __n8n_BLANK_VALUE_xxx you see when reopening the credential: this is normal and expected behavior, not data loss. n8n never returns the actual value of a sensitive field (password/private key) to the browser after saving, for security reasons — it displays a placeholder token instead. The key is properly stored on the server; what you see on screen is not its real content.
The real issue comes rather from using an expression to fill the field:
The Private Key field is a simple multiline textarea: there’s no need to use an expression to preserve line breaks. Paste the key directly (Ctrl+V), with its actual line breaks — it works natively. Using an expression here mixes runtime resolution logic with sensitive field masking, which can explain the failure when the SSH node tries to resolve the value.
If after a direct paste the line breaks still seem flattened, check your source key: paste it first into a plain text editor to confirm it contains actual line returns (and not literal \n) before pasting it into n8n — some password managers or terminals compress the PEM format to a single line on export.
Hey there! You’ve hit a rather infamous n8n quirk: storing multi-line SSH private keys directly in the credential UI.
Your observation about the field changing to __n8n_BLANK_VALUE_... is spot on. This is n8n’s way of masking saved credentials, but it often breaks the serialization of multi-line strings (like RSA keys) when you reopen the node, resulting in the “Unsupported key format” error.
The most robust solution to bypass these parsing headaches is to use environment variables. Here is how to fix it specifically for your Docker/CasaOS setup:
1. Prepare Your Private Key (Single-line)
Replace actual line breaks in your PEM file with \n. It should look like this (keep the quotes): "-----BEGIN RSA PRIVATE KEY-----\nMIICdgIBADANBgkqhkiG9w...\n-----END RSA PRIVATE KEY-----"
2. Set the Environment Variable
In your CasaOS app settings (or docker-compose.yml), add a new environment variable:
Name: N8N_SSH_PRIVATE_KEY
Value: [Your single-line key from step 1]
Save and restart the n8n container.
3. Update Your n8n Credential
Create a new SSH Private Key Account in n8n. In the Private Key field, instead of pasting the key directly, use an expression to reference your new environment variable: ={{ $env.N8N_SSH_PRIVATE_KEY }}
This injects the raw, correctly formatted key into the SSH client at runtime, bypassing the UI completely. It should work instantly.
Hi @Me.MyBase Welcome!
“Unsupported key format” is the ssh2 parser rejecting the key content, not the field mangling your line breaks. n8n’s SSH credential expects the key in OpenSSH format, and yours is a classic PEM key (-----BEGIN RSA PRIVATE KEY-----), which that parser won’t accept. Convert it in place, same keypair so the server’s authorized_keys stays valid, and strip the passphrase so nothing needs decrypting at parse time:
ssh-keygen -p -N "" -f ./id_rsa
The header should change to -----BEGIN OPENSSH PRIVATE KEY-----. Paste that converted key whole, header and footer lines included, and leave the Passphrase field blank.
Hello, thank you for the response.
The content in the SSH node is not the problem. I’m unable to store the SSH private key in a usable way in the credentials. The step in the node is still a test and isn’t currently being used at all.
Hi, thanks for the reply. The Private Key field is single-line in the version mentioned and not multi-line. That’s why the trick with the expression, which apparently also works in the validation. It only fails once I use the credentials.
-----BEGIN PRIVATE KEY----- is PKCS#8, which the ssh2 parser behind the SSH node doesn’t accept either, so that attempt fails on format before the field is even involved. The header you want is -----BEGIN OPENSSH PRIVATE KEY-----.
Since the field flattens the key on your version, write the credential in directly instead of pasting it. Export the existing one decrypted:
That lands in your mounted n8n volume so you can edit it from the host. Put the full OpenSSH key into privateKey as a single JSON string with \n at each line break, then import it back over the same ID: