Cannot decode Private Key

[mzch]

Hi,

When I'm going to use a ed25519/ecdsa style private key, sshwifty says "cannot decode private key". isn't their style unsupported?

[nirui]

Hello,

I've just tested it a bit, and can confirm it works at my end.

Have the key been encrypted? We don't support encrypted keys as doing so would require user to handover more of their secrets to the software, which is of course bad for their own security.

Also, I've failed to found the source error message "cannot decode private key". The closest I did found was "ssh: cannot decode encrypted private keys" here.

If that was the actual message, then it confirms that the key is indeed encrypted, and you need to manually decrypt it in order for Sshwifty to recognize it.

However, if the message was "Cannot use encrypted Private Key file" and you are using a old version (Order than 0.0.8-alpha that is), then there is a bug in the software which will block valid non-RSA private keys from been submitted. If this is the case, please use a newer version, lot's of other bugs has also been fixed since then.

[mzch]

Oh, sorry, yes, the message is "ssh: cannot decode encrypted private keys".
I'd like you to use ParseRawPrivateKeyWithPassphrase() instead of ParseRawPrivateKey(), so Sshwifty will recognize encrypted private keys. How about?

[nirui]

Sorry, I don't think I can do that. Because this software has been designed to collect as few data as possible.

If the software wants to decrypt user's private key, it will then have to collect the key passphrase, which is bad when you consider that later both information will be sent to the back-end server through public network.

An important background is, many people use one single passphrase to encrypt all of their private keys, effectively turning the passphrase to a master key. Handling and protecting a master key is too great of a responsibility for us, and a web app such as Sshwifty just doesn't have the power needed to fulfill it.

So, for the best interest of the user and their security, I have to refuse that. Hope you understand :)

[mzch]

I see. I can connect to my servers with a empty passphrase keys. Thanks!

[UlyssesZh]

which is bad when you consider that later both information will be sent to the back-end server through public network.

What about decoding on the frontend, and only send the decoded private key to the backend?

[nirui]

Hi @UlyssesZh,

What about decoding on the frontend, and only send the decoded private key to the backend?

I'm afraid that's still not enough. As long as someone (browser plugin, proxy, CDN, MITM etc) might inject content into the frontend page, the encoded/decoded data can still be send out via a simple XMLHttpRequest etc.

I figured the only way to do it safely is to make Sshwifty a desktop program that installs on the client computer so no change to the program can be arbitrarily introduced without user consent after installation, like a normal SSH app. But that's not a web SSH thing anymore.

[UlyssesZh]

According to your theory, users cannot even type their password to log in account on any web service. Do you not use password to log in GitHub on web?

[UlyssesZh]

I think HTTPS can mitigate most of the problems except browser extensions and the browser itself. As long as the self-hosting admin is aware enough to set up HTTPS, the only issue left is whether the user trusts their browser and browser extensions, which he has to trust if he enters any sort of personal passwords on web. If he doesn't trust the browser extensions, he can enable incognito mode or create a clean profile where no browser plugins are loaded. If he doesn't trust the browser, he will have to stop using this web service (as well as any other web services that require passphrase-based authentication). However, for a person that is so aware of security, he would have been using different dedicated passwords for different services anyway, and your original argument about a master password fails.

What I want to say is that, if we use HTTPS and rule out server-side attacks, then the client-side decoding of the private key is not less secure than any other web service that asks for a password.

[nirui]

Hi @UlyssesZh.

There are a levels of acceptable risk and trust involved here.

A private key maybe more sensitive than a password, since traditionally, people often reuse their private keys across multiple servers and it is deemed mostly safe to do so (aside from privacy concerns), which is a different paradigm compare to how people use their passwords (where reuse is discouraged).

Under that, if someone leaked their private key, then maybe more than one server will be impacted at once. So that's where I draw the line: password is an acceptable risk, encrypted private key on the other hand is risk-too-high and user should generate a dedicated unencrypted private key to be used in Sshwifty.

(On the same note: if you find Sshwifty keeps rejecting unencrypted private key, then maybe it's a bug)

You're right in that the line was arbitrarily defined. It is technically possible (easy, actually) for me to make Sshwifty accept those information. However, I'm not really feeling conformable doing that knowing my ability to protect user information is limited, and I really don't want to contribute to online leaks and then got my name mentioned that way.

Side note: Sshwifty is there to provide easy access. If you have too many private keys to manage, maybe try a desktop SSH app or access management platform such as https://goteleport.com/? I can live with the fact that you also uses other SSH programs. Plus, use the right tool for the right job is always good.

(I just realized that the original wording maybe too much, I've changed it. Sorry for any disturbance)