This is certainly something they can fix, but I use different keys for different infrastructures, which makes this approach less convenient to me.
As I was already running a custom SSH server which practically required you to implement authentication yourself anyway
boy that doesn’t make me nervous or anything
Some way to do this on top of OpenSSH, or other tools people actually run in the wild. PAM?
The risk-reward analysis seems to have gone off the rails here.
I’m convinced that the solution to the copy-and-paste “problem” described takes more time than it would to just do the copy-and-paste in the first place…
It does have the advantage that users won’t accidentally paste their private key, or some other key that won’t actually be used. It’s a sort of self check that the client is capable of using the key.
But yes, it requires a fair bit of explanation to convince me I want to do this, whereas copying a key is closer to the expected workflow for someone familiar with ssh. Though if a user needs to be told how to use the clipboard, perhaps we shouldn’t assume familiarity.
I really like this approach (but maybe not the implementation; I didn’t look at it) but maybe that’s because I have a sick desire to run as much of the world via SSH as possible.
I’ve thought about how to offer some form of control panel and authpf gateways to novice users in a safe manner. It seems clear to me that neither web apps nor web browsers are terribly secure.
I imagined some form of customised SSH client that auto-generates a key-pair, auto-submits the public key when the user creates an account. The server could still require payment or email validation, an additional authentication factor or whatever else is needed.
Am I the only one with this sick desire?
How are browsers and web apps less secure than SSH (assuming we are using HTTPS, etc.)?
It’s the etc part that kills me. Not only do you need HTTPS (which outsources a great deal of security to a 3rd party) but also various HTTP headers, like HSTS, Public Key Pinning, Content-Security-Policy and a slew of other things that won’t fit in my tiny brain. And that’s just the transport layer.
All my online interactions with (Danish) local & tax governments are basically HTML forms that could be served just as well over a reasonable ncurses interface. Authentication, Encryption and tunneling are all solved problems in SSH but everyone basically has to manage their own solutions to those problems when it comes to HTTPS.
I fully admit it’s a sick desire, but it’s still a desire. And I want it soo bad.
Yeah, the only thing I see as being an issue there is that the average user doesn’t want to see a terminal ever again in a million years. Forcing them to use it would likely evoke a lot of anger, and it would make you look like you are taking a step backwards (even if you aren’t).
At least for basic usage, SSH seems a lot more foolproof to me. I run a server some people have ssh access to, and the “correct” way to do it is straightforward: they send me an SSH public key, and I create an account that allows login with that key (disabling password login). Authentication, sessions, etc. are now all handled in a reasonably sane way.
How do I do the same with a webapp? That’s a question I’ve actually had (for the same server), but I haven’t found a good answer, so thus far I don’t provide that functionality. I looked into X.509 client certificates, which in theory seem to be the web version of SSH public/private key pairs, but afaict usability is poor and therefore they’re rarely used. Instead afaict the only real credential solutions are: 1. passwords (ugh), or 2. OAuth (also ugh). And even once you get past the basic authentication problem, session security is full of pitfalls.