41–50 of 169 posts
ssh -o "IdentitiesOnly yes" -i ~/.ssh/id_whatever mars.vtllf.org
(I use the IdentitiesOnly option because I often see ssh still offer other keys without it)
"SSH is near-universally loved among developers." Really? Which developers? SSH is one of those things you get forced to deal with a couple times a year for some irritating task, and it involves firing up Putty, figuring out where you left your key file, trying to remember how to actually load that key file, and a bunch of following steps on some website just to get connected to what you were trying to connect to. It…
No need for custom url formats. Keep it really simple: Use a and rely on browsers to prompt us to "log in with ssh". IF there's no public key, the browser could offer to run ssh-keygen for the user and save the results in the user's keychain. If we use switcher[1], we can even put ssh and https on the same hostname and on the same point. This would be a recommended configuration since it would get through most proxie…
However, the correct way to do this is the way browsers link to external protocols already:
Open SSH connection
This is no different than a mailto: link, a skype: button, an ftp:// link, or any other link in a webpage that uses a protocol other than HTTP/HTTPS.
Frankly, I don't want my browser talking to SSH servers. Because that means it has access to my SSH keys. If you don't think its a problem for your browser (that thing that runs javascript from anywhere on the planet) to have access to your SSH keys, the point of my comment will no doubt be missed.
A browser should do one thing, and do it well: browse pages. Once you start adding SSH clients, RDP clients, etc, you are simply inviting security holes, and arguably missing the whole point of local apps.
What about this solution? https://www.grc.com/sqrl/sqrl.htm
This system provides mutual authentication and the ssh command (that the user will surely copy and paste) doesn't contain any tokens. The session token is produced after authentication has taken place.
Wow. I just have one question for you: why? Have you ever heard of TLS and client certificates? Every browser and every decent web server supports TLS with a client certificate for auth.
Because client certificates have been around for donkeys years and almost nobody uses them. Even technical people! But technical people do use ssh keys .
"SSH is near-universally loved among developers." Really? Which developers? SSH is one of those things you get forced to deal with a couple times a year for some irritating task, and it involves firing up Putty, figuring out where you left your key file, trying to remember how to actually load that key file, and a bunch of following steps on some website just to get connected to what you were trying to connect to. It…
I use SSH on a daily basis. Right now, from work, I have five SSH connections open, one is tunneling, one is tunneling and providing an interactive shell on one of my personal machines, one is connected to the live environment for server monitoring, and two are connected to the development environment. I'm running everything from applications, to the command line to my IDE (vim) all in SSH sessions.
Just because you personally don't understand a key bit of internet technology doesn't mean it's the same for everyone else. There are those of us who see a valuable tool and use it properly.
Earlier quoted context omitted.
How is this better than using cookies? I don't really see the advantage of moving session identification down a layer.
Because HTTP is stateless and session-less, and cookies are a hack to make it stateful. We introduced the notion of a session where we already had one, in the form of TLS sessions. Note that it would also make APIs much simpler by moving the authentification, authorization and session logic in the certificate, where it actually already is.
But that would only apply to HTTPS. An extension to HTTP itself was necessary so state could be maintained for both HTTP and HTTPS. Especially in the mid-1990s (the era when cookies and HTTPS were introduced) when acquiring a CA-signed certificate was cumbersome and expensive.
Earlier quoted context omitted.
Because client certificates have been around for donkeys years and almost nobody uses them. Even technical people! But technical people do use ssh keys .
Even technical people can make stupid mistakes. Look at MongoDB and it's legion of fans.
> it's
ahem
Earlier quoted context omitted.
So why are people trying to replace the algorithm, when what we need to do is to replace the UX? Patches could be submitted for both Chromium and Firefox to give them a better client-cert flow, but I don't see anyone working on the problem; just a constant parade of restyling on tab-strip and toolbar and notification banner UX. I mean, ideally, a client cert would be treated pretty much exactly like a cookie: generat…
How is this better than using cookies? I don't really see the advantage of moving session identification down a layer.