Private key passphrase visible on remoteEdit.json about remote-edit HOT 15 CLOSED

The ideal option is indeed to encrypt the passhrase (basically any and all passwords). Unfortunately, I do not think Atom provides any functionality that allows us to store encrypted variables. That basically leaves the only option to encrypt password/passphrase in the serialized remoteEdit.json using a global password that the user would be prompted for each time he connects to a server to unlock the settings.
The other option of prompting the user for the passphrase each time he connects is easier to implement.

Is this something you'd be interested in implementing?

from remote-edit.

I would like to implement it myself, but i'm a java developer and i don't know how to do with node.js + atom.io api (i'm still in learning process)

from remote-edit.

Definitely don't like remote-edit leaving my SSH passphrase stashed in ~/.atom ... using ssh-add is OK as a workaround I think, although catching the key not being loaded and prompting would be the nicest UX.

I tested with current master, it didn't seem to pick up on ssh-add until I added the change above (which I see might be better fixed a few lines above). Thoughts?

from remote-edit.

OK, I get it now - these three tabs (User Agent, Private Key, Password) set the mode of operation rather than just exposing tab contents. This was an unfamiliar UI pattern, so I thought there was a missing checkbox or similar.

Instead, selecting "User Agent" should make remote-edit try agent-based auth. Knowing that, and manually using ssh-add to unlock an appropriate key before connecting, I seem to be able to use remote-edit without the above change and without storing passphrases to disk, which is great.

Prompting for passphrase if not unlocked would be a big improvement, and making the UI clearer might help keep a few users from writing passphrases to disk - or maybe this is an Atom UI pattern I'm not familiar with?

from remote-edit.

It took me a while to understand too that "User Agent" is the preferred choice (it makes use of Pageant on Windows, for example) rather than putting in the path to the key and the key itself in plaintext (ugh).

I'm almost leaning towards suggesting that the "Private Key" tab be removed completely as it's insecure and confusing, choosing either "User Agent" or "Password" should be enough, right? Am I missing a use case here?

from remote-edit.

Well, the obvious use case would be someone who has multiple PKEYs and don't want to have them all in their user agent. Say you're a sysadmin that manages a large amount of servers, and you use a different pkey to access each server. You might not want to add all the keys to your user agent.
Either way, I do not want to force people to use a user agent, and as such will not be removing it.

I do see that the UI might be confusing. I've added a small fix in commit f87b0be that at least adds a label. If y'all have any other ideas that might make it more clear I'd be open to adding them.

from remote-edit.

Maybe put a small informative text under each button explaining what it actually means to select that option. Just clicking a button that says "Private Key" sounds like what I want, but it's really not if I'm using Pageant with my Private Key, it's actually more like "Specific Private Key" or "Private Key File".

Another idea for the passphrase could be to use the type of prompting used for the password. Caching the private key passphrase just makes me cringe, it's a better compromise to force the user to provide it every time the key is used -- if you want the convenience of not having to do that, that's what a user agent is for, right?

from remote-edit.

So - not forcing someone to use ssh-agent is fine - but writing the passphrases, as plaintext, to disk - without informing the end-user, at the time or in the docs - is a really poor substitute. Forcing a re-enter when Atom starts and the passphrase is needed, or prompting for a new remoteEdit passphrase and saving them all encrypted with that are both superior, by far, to throwing security out the window, again without informing the user. If you do - and I missed it - you need to do a better job there.

Software should never, ever, under any circumstances, write secret credentials to disk unencrypted. That sort of fundamentally broken behavior should be reserved for human beings.

from remote-edit.

I agree that adding a warning label makes sense but more than that can't be expected from @sveale , ssh-agent should already be the recommended way of using it and if you step outside that you can deal with the fallout (plaintext). @sveale doesn't "need" to do anything @bortels, if it bothers you that much, fix it yourself.

from remote-edit.

I agree with both of you that I haven't done a good enough job of informing the users of the consequences of typing in their password/passphrase.
To alleviate this, I've commited a patch that adds warning labels to aforementioned behaviour and adds a new section to the readme.

@bortels, as previously mentioned in this thread I'm well aware of the caveats of storing passwords/passphrases unencrypted, but as this is a package I work on in my spare time I don't have time to make it perfect. You're more than welcome to submit a PR.

from remote-edit.

It maybe a good idea to store password with node-keytar, it was made by the atom team too.

from remote-edit.

You're correct, of course - "need" is a strong word. You could walk away, and make no more changes.

I should have said you are "ethically obliged" to either warn people, or not do it.

And - you have apparently done so. Good enough. I do like the suggestion of node-keytar as well, but - that would turn "issue" into "enhancement".

from remote-edit.

I've just added a commit, 2b0e500, that uses node-keytar to store passwords/passphrases. If any of you could try it out and give me some feedback that would be much appreciated.

It's disabled by default. You can enable it in settings.

from remote-edit.

@sveale I just tested it on my Mac. I tried to "Add New Host (ftp)". The keychain entry is always <username>@undefined:21 (<username> is my computer login username) no matter what I entered in the hostname and username text field. Attempting to connect will result in "Login authentication failed".
If I switch off "Store passwords using node-keytar", it worked fine.

The bug should be in the confirm method in file lib/view/host-view.coffee.
As @host.getServiceAccount() is called before these statements:

@host.hostname = @hostname.getText()
@host.username = @username.getText()
@host.port = @port.getText()

Therefore @host.getServiceAccount() return username@undefined:21 due to the values wasn't set in @host yet.

from remote-edit.

Thanks @howanghk! Fixed and published new version, v1.8.20.

from remote-edit.