Blink: OpenSSH and RSA Keys can only be imported after modifying the Header of the Private Key

[webdog]

Checklist

• [x] Using latest version on the App Store
• [x] Read the docs
• [x] Searched for existing GitHub issues

Configuration

• Latest version of Blink
• iPad OS 14.2

To replicate:

• Generate an SSH key using openssh (MacOS default) or RSA cryptography from another source

Describe the bug

Keys cannot be validated by the application as valid keys (Yep, they're valid) when importing from clipboard or a file.

Looking at keys generated by Blink, the private key header does not specify rsa or openssh:
-----BEGIN PRIVATE KEY-----

The ones I want have headers like:
-----BEGIN RSA PRIVATE KEY-----
-----BEGIN OPENSSH PRIVATE KEY-----

To use these keys, I strip out the cryptography identifier and am able to upload them into Blink and login to my servers

Expected behavior

I'm not sure. RFC-4716 - Gives guidance on providing a specific identifer of the type of key the private key is, inside the BEGIN block, and I've never really come across a Private key doesn't specify the type of key it is. It feels like a hack that I have to edit the header to have the app recognize my key.

If I want to take my keys out from Blink, I have no understanding of how these keys were encrypted. I can specify the settings at creation time, but the app doesn't retain that information.

My questions:

• Is Blink doing a check inside the BEGIN block of my imported key to verify what kind of key it is?
• Are generated keys from Blink having their BEGIN delimiter edited with a custom string?

[redlavender]

I think I have the reverse problem.

Keys that I have generated using blink cannot be recognized in other applications because they need the, for instance RSA, key.

I have to hack the Blink key to get them to import from the clip board.

[carloscabanero]

The proper standards for the keys are the PKCS and if I recall we were using PKCS#1 style before, and then we changed to PKCS#8 (https://en.wikipedia.org/wiki/PKCS_8). As you can see, there is no reference to the type of key in the PEM header, unlike the previous, as it is encoded inside. Other apps may rely on it to identify what key it is, but we do not.

Blink should support in any case both standards, and I remember provisioning for both cases, even touching LibSSH for it (as they were not properly handling the case when there was no key specified, decoding first). It may be that we are actually picky about not having anything at all, the same way other apps actually are picky about having it.

I will take another look as some time has passed and maybe something broke somewhere - I myself may not remember things properly -. We have created a separated ssh library for all our calls in a way that is more maintainable so I will move this as well, to make sure we can continuously test changes on the different libraries we use.

Thanks for the heads up!

[calebhailey]

I think I'm seeing the same thing. Can't seem to add an OpenSSH private key that I generated outside of Blink. Tried adding from clipboard and from a file.

PS- THANKS FOR BLINK! I'm a big fan and recommend it whenever I can!

Cheers 🍻

[carloscabanero]

Quick update. We actually use OpenSSH itself to process keys. Most of the issues during import are due to missing EOL characters (this is almost sure if you are importing from clipboard), or additional spaces at the header.

While we do a rewrite of some of the key work, please check that is not the case. I am rewriting all the key handling to provide a better agent as well, and will be making a few changes to make the keys more flexible.