Suggestion: Make ssh-copy-id useful

[brandon-fryslie]

It’s not apparent what the suggested workflow for using ssh keys in this application is. All the pieces are here, kind of, but none of it feels super intuitive.

Potential workflow #1

• Take an existing ssh key and import it into Blink on each device
• Use a non-Blink device to set everything up
• Pros: Simple, easy
• Cons: Does not use Blink

Potential Workflow #2:

• Create separate ssh keys on each device in Blink
• (On each device):
• Manually copy the ssh public key
• Log into each host
• Manually add the public key to the authorized_keys file
• Pros: Uses Blink
• Cons: Repetitive, manual, annoying, inferior to standard workflow

OK, so how about this as a feature idea?

• ssh-copy-id function exists within blink
• pressing (eg ‘ssh-copy-id ’) completes from your list of ssh keys
• Hosts argument completes as normal
• ssh-copy-id works as typical to set up a key
• Pros: Intuitive, simple, familiar, this would be expected behavior
• Cons: None

I’m not sure why this doesn’t work already. I mean, I understand that the public key does not exist as a file, and the ssh-copy-id command expects a file. What I mean is, I don’t understand why the entire thing wasn’t set up to enable this workflow from the beginning. Maybe there is a ‘recommended’ workflow that is even simpler and easier, and superior for some reason. I’d like to know if that’s the case. But I think at minimum this should work out of the box because IMO that’s going to be the most intuitive and generally abide by the ‘principle of least surprise’.

Great application btw! I’d be happy to try to implement some features if you can give me a high level overview of the ‘right’ way to accomplish something like this in this codebase.

[carloscabanero]

Thanks for the thorough workflows. It is an improvement I have had in the back-burner for a while. Some of it are really old reasons (on the first Blink, we needed a way to copy keys and things still worked with files back then).

First of all, most people just use option 1, copy the public key from a different device, and it is fine and is what they are used to do. I think also a big chunk of people just use the same private key between devices - which security wise is not recommended. (We do not get any usage info from people using Blink, so it is all assumptions based on support, issues, etc... which is skewed).

Now, the feature idea is to offer a way to copy the key inside Blink. Our ssh-copy-id is tweaked to work in the way you already suggest: "ssh-copy-id <key_name>" - note it is key_name and not key file, because we extract the public key within the command. This changed when we moved to file-less keys. I don't think it autocompletes though, which would be a good addition.

But how about a UI? The problem is that to do it from the same device that does not have a key installed yet, you need a different login method. This would be most commonly a password. We can introduce "password login" from the UI, and also "accept HostKey" dialogs, etc... But these all break the flow of using the "terminal" itself.

There is another possibility, which is from one of the working devices, to "Scan" a QR code with the public key of the new device you want to add. This would definitely work. But you still need the first ssh-copy-id method though. And most people still just copy / paste the public key from a note to install on new machines. So you end up in the same loop.

So partial conclusion, and feel free to send your critique back. The current ssh-copy-id is close to what you already suggest. Probably adding auto-complete for the keys so it is more obvious would be a fantastic idea. I don't think the UI over ssh-copy-id itself adds a lot of value for the work it would take and "breaking" the terminal boundary. I don't think other flows will provide enough value for the work they would take.

A final "out of the box" idea. it would be really interesting to have a way to "share" Blink keys securely, or requesting temporary access (kinda like an agent between Blink apps). That would require a lot of work though, but it would also enable other scenarios (login from even other computers). And that would make this flow also more straightforward or even unnecessary (except the first time).