Replace the default pubkey with a clearly bogus key

[SharkWipf]

Since it's impossible to verify whether or not the default pubkey is tied to a key controlled by the author, this makes it clear no real key is being used by default, and also makes it more obvious the default value should be changed for people less familiar with how SSH keys work.

[adamoutler]

Do you think its best to make it so much shorter than an actual public key?

[SharkWipf]

This is only slightly shorter than a standard ecdsa key (but then again, it is an RSA key in the example). The default RSA key length also gets updated occasionally based on new security standards, so does not have much of a long-term standard length (although certainly longer than the bogus key I provided here).

Personally I feel like this would make it clear enough what kind of key goes here, I deliberately kept the start and end of the original key intact for this purpose as well, though it is, of course, your project and your decision.

For me the most important thing was not using something that could be an actual key as default, both as an insurance to whoever installs the addon that accidentally using the default key doesn't risk giving someone else access unintentionally, and to avoid the scenario in which people might start incorrectly accusing you of malicious intent/hacking their NAS.

These may be fairly far-fetched and easy to debunk scenarios, but since I figured a fix would be simple and clean, I thought I'd shoot a PR.
Up to you whether you actually want to accept it of course, and in what form.

[adamoutler]

Well, you're right here. I think we could do it better though. Maybe we can add instructions instead of EXAMPLEexample?

[SharkWipf]

Something like this? Seems to fit nicely in the box on a 1080p monitor too.

[adamoutler]

Yeah. Maybe. What about

Your public key goes here. Find it in a file called ".pub" along with your private key. It's one long line ending with your computer name.

They all end with user@host right?

Some common problems I'm trying to address are

1. Partial copy leaving out user@host
2. Copying private key
3. Using a mismatch pub/priv key combo
4. Trying to use this as a password box

[SharkWipf]

They all end with user@host right?

Nope, the part after the key itself is freeform, can be anything, can be nothing, depends on what was used to generate the key. PuTTYgen generates something like rsa-key-20230131, I have one key that is called 27:40:82:d6:ae:c3:63:c0:f8:51:75:40:cb:58:87:11 Discord for some reason, and I have received pubkeys from people without any descriptor. It's also not necessarily always a file that ends in .pub, that's also dependent on the generation method/application used.

It's worth noting that attempting this in the first place is a fairly advanced procedure, with little to no use to the average user, so it might not need to be completely fool-proof. Plus, it's a configuration sample, not the actual documentation. More in-depth instruction can always be handled by the actual documentation if necessary.

Maybe in my example emphasize the "public" part?

Insert the full contents (i.e. ssh-rsa AAA...) of your public ssh key (id_rsa.pub, id_ecdsa.pub, ..., NOT your private key or password) here.

[adamoutler]

I felt it was important to start with "ssh-rsa AAA" then provide the context. Additonally this will be an update so the version needs to change.