
Signing in to websites with SSH - blfr
https://vtllf.org/blog/ssh-web-sign-in
======
patio11
It is actually pretty useful to require SSH as a two-factor authentication
method for internal services, particularly extraordinarily sensitive internal
services which you'll expose solely to technical employees.

I use it for exactly one purpose: authorizing the "ghosting" of a customer
account. ("Log in as this user.") Putting that behind SSH means that anyone
authorizing a ghosting has both a blessed SSH key and the password to it. Even
rooting my session on our admin app, via reflected XSS or stealing my unlocked
laptop out of my hands, doesn't get you that. (Our admin app, by design, is
less-than-all-powerful. A malicious admin session could do a heck of a lot of
damage to our business but, critically, would be unable to access personally
identifying data about customers' clients.)

~~~
nzealand
You use vanilla ssh to authorize the ghost of a customer account?

~~~
patio11
I'm not sure I understand the question. Here's what gets typed:

    
    
      ssh foo.example.com #uses private/public key per conf file
      *enter password*
      cd app
      ruby script/console
      irb > u = User.find_by_email "customer@example.net"
      irb > u.authorize_ghosting! "Reason for log goes here."
      * you'll want to incognito mode the URL returned here*
      irb > exit
      exit

~~~
cat9
With all due love and respect:

This is something I would wrap a simple CLI around, and then kick myself in
the tukhus for having ever used the language's interactive client to make raw
database queries and edits on the production server.

~~~
tedunangst
'find_by_email' is what counts as a raw database query these days? I feel so
old.

~~~
hamburglar
At my company, using an interactive shell on prod to invoke DB queries, even
through the ORM, is basically considered a raw database query, and is strictly
forbidden. It's untested code coming straight from your fallible fingers and
manipulating the prod database. I don't see why this should be treated as any
different than a raw db query. You can do some pretty powerfully destructive
stuff with an ORM.

~~~
tedunangst
If there's anything destructive about that interactive session, it's likely to
be the 'authorize_ghosting!' call. Somehow, I find it hard to believe sticking
it in a one line script would make it less destructive, but let's see.

    
    
        User.find_by_email(ARGV[0]).authorize_ghosting!(ARGV[1])
    

Oh, yes, so much better. patio11 should totally switch to using this. And then
pay me my $1000 consulting fee.

~~~
hamburglar
I'm going to go out on a limb and suggest that it shouldn't just be turned
into a one-liner that shoves ARGV elements directly at the database, but
should actually do some validation of input. Even your one-liner is safer than
raw irb since you can't make a typo and call the wrong method, but if you add
validation, then yes, I think it's much, much less destructive.

~~~
tlrobinson
What sort of validation? Either you provide a valid email address that exists
and it works, or not.

~~~
hamburglar
I suppose when the args are both allowed to be arbitrary strings, the
validation is already done, and the escaping is done by AR, so you can safely
pass them unmolested. It just triggers my safety reflex to send ARGV elements
on to the next layer without doing _something_ to them.

------
timtadh
I want to thank the author for testing this out and doing an implementation.
When Mozilla Persona came out I thought it would be cool to make an identity
provider which support SSH based auth. I never had much time to work on it so
seeing the various design problems was really great. I do think you can make
some improvements when paired with a system such as persona but the
fundamental challenge that SSH is not integrated into the web remains.

Still, as programmer, I would love it if I could auth to github et. al with
SSH keys. I would actually feel more secure doing that than with the password.
Keep the 2 factor token either way. I completely agree with the author's
assessment that this type of system would not work for the average web user.

~~~
duncankl
Glad you liked it!

I definitely echo the sentiment of wanting to use these sorts of power-user-
only tools. But I think Moxie's recent post, They Live[1], does an excellent
job of explaining why we shouldn't accept that the tools are too hard for
everyone else, then just hoard them for our own use anyway.

[1]: [https://whispersystems.org/blog/they-
live/](https://whispersystems.org/blog/they-live/)

~~~
jwise0
Adding on to the praise, I wanted to also comment -- thanks for doing an
analysis of the results. Having implemented it was neat, but the honesty in
revealing that what you've built is an interesting experiment, but not
necessarily an improvement on the status quo, is commendable.

There is still lots to be learned from the work you did -- both the technical
and the analytical. I think this is probably the most striking example I've
seen recently of "negative results are results, too".

Thanks for the writeup.

------
geocar
No need for custom url formats. Keep it really simple:

Use a <link rel="ssh"> 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 proxies.

[1]:
[https://github.com/jamescun/switcher](https://github.com/jamescun/switcher)

~~~
nothrabannosir
And please, please, _please_ add the fingerprint to that:

<link rel="ssh" data-
fingerprint="8b:16:df:7b:11:7c:78:1c:4d:65:3f:50:71:2b:91:5d" >

Or whatever your fancy, I don't care how, but please add that fingerprint.

SSH displaying the user a fingerprint on first connect and allowing it to
accept is its worst UI mistake.

~~~
stephenr
Yet again, there is already a mechanism for this.

Add your fingerprints to DNS (they can be obtained using ssh-keygen -r
<hostname>)

Set the SSH option VerifyHostKeyDNS to "yes" (or "ask" if you want to confirm,
with a notice about if the DNS entry matches).

~~~
pmh
That's not a secure option without DNSSEC. Given that we're unlikely to see
significant DNSSEC adoption, serving the fingerprint over HTTPS (or another
option altogether) would be preferable.

~~~
stephenr
So use DNSSEC for SSHFP lookups. The Debian package for example (openssh-
client) added support for DNSSEC in its lookups, almost 5 years ago (April
2010)

------
nly
The only substantial advantage to this scheme is you get server id pinning for
free (via your known_hosts file), but a combination of HTTP public key
pinning[0] and client-side certificates will give you all the same advantages
with far less user effort.

[0]
[https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...](https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning)

~~~
comex
You get pinning... and _absolutely no verification_ the first time you
connect, so anyone who got lucky enough to MitM you the first time (or first
time since you deleted your known_hosts file or reinstalled your operating
system or switched computers) can log in as you, without having to compromise
any PKI. Meh.

------
ams6110
I've worked in support of computing clusters that are widely used by
researchers. By far the most common problem people had with using these
systems was grokking ssh keys. Masters and PhD Computer Science people are
routinely baffled by them, provide their private keys instead of their public
keys, or provide both, etc.

People in general just don't get public/private key pairs. Any solution that
requires any awareness or handling of the keys by the user is a non-starter.
Sorry to sound negative but after a couple of decades of observation I'm
convinced this will never change.

~~~
swadworth
Yet, if you call a public key/private key a lock/key respectively, then a lot
more people would immediately get the concept.

"You send him a copy of your lock which he uses to lock a package and return
it to you. Then only your key can open it!"

You immediately fix the problem of people sending their key, because people
know keys are important and shouldn't be handed out to just anyone.

The PKI people are brilliant. Their communication skills, not so much.

~~~
aikinai
I've always wondered why we couldn't just call public keys locks. That would
avoid so much confusion for first-time users.

~~~
peeters
Probably because the analogy breaks down so fast.

"And to prove he sent the package, he locks it with his key and then you use
your copy of his lock to open it so that you know it's from him!"

It's a useful analogy for one specific use of public/private keys. But it
doesn't capture the full spirit, which may lead to more confusion than just
using no analogy.

~~~
teraflop
It's not true in general that public-key encryption and digital signatures are
inverse operations. (RSA has that property, but there are plenty of other
algorithms that don't work that way.)

If you're writing for a lay audience that doesn't care about things like
modular arithmetic, there's no reason to conflate the two operations. Just say
encryption is like keys and locks, and signing is like... well... a signature.

~~~
tedunangst
So this public key is like a lock and that public key is not like a lock. Got
it.

------
rohansingh
We use a philosophically similar solution at Spotify:
[https://github.com/spotify/crtauth](https://github.com/spotify/crtauth)

The difference with crtauth is that you don't need an SSH server running in
tandem, everything is handled by the crtauth library. Our main use case for
this is for bots that need to access secure services.

Protocol spec:
[https://github.com/spotify/crtauth/blob/master/PROTOCOL.md](https://github.com/spotify/crtauth/blob/master/PROTOCOL.md)

------
justinsb
An SSH key is equivalent to a (self-signed) SSL client certificate. I would
love to see an easy way to use your SSH key as a client certificate - either
an external tool or the browser itself could support this.

~~~
a3_nm
There is a related project to connect the web of trust of OpenPGP keys, SSH
keys, and SSL certificates:
[http://web.monkeysphere.info/](http://web.monkeysphere.info/)

------
erikano
I like alternative two, except that I'd have it be

    
    
        ssh <token>@<host> auth
    

This feels more natural to me and makes it easier to support other commands in
the future should one wish to do so.

Regarding the part where he said:

>Running a custom SSH server along side a web server is not convenient. There
is no good equivalent to the HTTP Host header, so hosting multiple SSH servers
on a single IP address doesn’t work well.

That's not a problem. Your server got the host header over HTTP. When you
generate the token, just tie the token to that host name.

~~~
duncankl
Good point about the <token>@<host> format, I like it much better too.

You're right about tying tokens to host names, that would work. But you'd have
to justify whether the extra complexity of multiple web servers preregistering
tokens with a SSH front-end was worth it. Another approach would be embedding
a static host identifier in the username as well.

Although my knowledge of the SSH protocol isn't complete, a related issue
appears to be that servers prove their identity before clients send their
usernames. That means servers sharing the same IP/port would also have the
same host fingerprint.

It could be acceptable if all the services were run by the same organisation,
but on a platform like Heroku it would be more of a challenge.

~~~
epaulson
It wouldn't be too hard to extend the SSH protocol to include something like
the HTTP Host-request header. In the protocol exchange section of the SSH RFC
(
[https://tools.ietf.org/html/rfc4253#section-4.2](https://tools.ietf.org/html/rfc4253#section-4.2)
) the format described is:

SSH-protoversion-softwareversion SP comments CR LF

In the comment section of the message, you could add something like "X-Host:
hostname.wherever.org" and a smart SSH server could proxy the connection to
the correct host. This happens before the key exchange occurs, so you'd still
get strong authentication from having the right key.

I checked through the OpenSSH and Paramiko code, and both essentially ignore
the comment section of the version exchange - everything between the first
space and the CR/LF at the end. They does hold on to it for part of the DH key
exchange, but they never try to interpret the bytes, so a modified client
could keep sending the X-Host extension and stock OpenSSH would just ignore
it.

------
IgorPartola
I am not sure about this. First, there is a built in MITM attack here. First
time you connect to sshd, the server has no idea who you are. I suppose this
could be mitigated by using HTTPS as the out-of-band channel for verifying
client and server fingerprints. Second, ssh keys are somewhat limited. You can
only have one public key for a private key. You cannot embed identity info in
the public key. I would much rather see hog keys used for this. For developer
types that should be just as easy. For real people the UI would still have to
be developed but could actually include useful features, such as user
identities.

~~~
icebraining
_First time you connect to sshd, the server has no idea who you are._

That's not a problem if you signup by first connecting to the sshd and getting
a custom signup URL.

~~~
IgorPartola
How do you know that the sshd you connect to is authentic and not a MITM? More
importantly, how does the sshd know that the incoming connection is you and
not a MITM?

~~~
icebraining
_How do you know that the sshd you connect to is authentic and not a MITM?_

You'd need the server fingerprint on the site (served over https, of course).

 _More importantly, how does the sshd know that the incoming connection is you
and not a MITM?_

But that's the point, there is no "you" to authenticate, since you're signing
up for a new account. The sshd generates a token URL and then stores your
fingerprint with that token. Then you can use that token to login to the
actual site and fill in your information.

If you're MITMing someone, the server shouldn't care, it's the client's job to
make sure it's talking to the right server. See above.

------
fideloper
Adding "-vvv" to the given SSH command, it looks like it uses the first SSH
key given. I happen to have quite a few for various services. I suppose you
could offer up one specifically by running

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)

~~~
duncankl
Thank you! I was looking for that option while writing the section on
throwaway keys. I'll have to test it out.

------
slyley
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.

~~~
nodata
Because client certificates have been around for donkeys years and almost
nobody uses them. Even technical people!

But technical people _do use ssh keys_.

~~~
stephenr
Even technical people can make stupid mistakes. Look at MongoDB and it's
legion of fans.

~~~
DanBC
> Even technical people can make stupid mistakes.

> it's

 _ahem_

~~~
stephenr
Somehow I don't qualify a misplaced apostrophe (either by human error or bad
autocorrect) on the same scale as choosing a fundamentally bad database or
failing to understand/take advantage of powerful technologies such as client
side certificates.

------
tedchs
Why not use client-side SSL certificates in the browser?

------
jerinaw
What about this solution?
[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

~~~
nly
SQRL is vulnerable to phishing and spoofing attacks due to the lack of mutual
authentication. I can send you a phishing email with a link to a webpage that
looks like PayPal, on mynastydomain.com, and then display an actual PayPal QR
code to you. There's no complete solution to this all the time you're passing
tokens with an unauthenticated association over an air gap. The IP binding
proposal is a just a disaster for a number of reasons.

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.

~~~
themattrix
Care to expand on this a bit? I'm somewhat familiar with SQRL, but what was
this IP binding proposal all about?

Is this a use-case not discussed in the SQRL phishing page?

[https://www.grc.com/sqrl/phishing.htm](https://www.grc.com/sqrl/phishing.htm)

~~~
nly
It's there buried in the discussions somewhere. The basic (and old) idea is to
shove the IP of the user (or spoof as the case may be), as seen by the web
server, in to the QR code and then tie it to with the session token using a
MAC. When the SQRL app passes the signed SQRL data back to the web server it
passes this back as well. The server can then reverify the users IP (remember
they're now using the app on another device).

IP binding is worth doing but there's no way for _the app_ to warn the user
that the IP differs. You have to trust the server implementation of SQRL
(which despite what Gibson claims, is actually fairly complex on the server-
side)

Other issues are discussed on the page you linked entitled "Details and
Limitations of IP-based MITM detection"

------
hughes
This question might be hilariously naive... but why don't web browsers make
signed requests, just as web servers make signed responses?

If I create an account on a website, then associate a public key with my
account, shouldn't the browser be able to sign each request with my key? The
website then wouldn't ever even have to deal with cookies or sessions as long
as I was logged in to my browser.

Or better yet, if my key is publicly known and trusted, couldn't a website
know who I am before I even create an account? It could skip the signup
process entirely.

~~~
gergles
[https://pilif.github.io/2008/05/why-is-nobody-using-ssl-
clie...](https://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-
certificates/)

~~~
duncankl
Thanks for the link! I added it to the article.

------
adamtj
I love SSH, but I don't want to actually use SSH for this. That's not the
important part. All I want is key-based authentication, and that doesn't need
SSH. I want to be able to plug a security token into a USB port and be logged
in, without even having to click a sign-in button. Reformat, reinstall,
reboot, plug in security token, launch browser, type news.ycombinator.com and
I'm already logged in.

~~~
stephenr
I don't know if I'm missing something here, but it sounds like what you want
is just SSL/TLS Client Certificates using PKSC#11 for the private key?

~~~
e12e
Which is also usable for authenticating to ssh (but needs to set up as such
certs are different from ssh key and from ssh "native" certs).

------
wampus
The author makes a very good case for why this approach won't threaten
password-based authentication, including:

 _...hard for first-time users to get right:... The private key being unlocked
and available via ssh-agent._

For this to be convenient for daily use, ssh-agent is essential, and that
could expose naive users to compromise. I know enough to disable ForwardAgent
in my personal config by default and generate site-specific keys for hosts I
can't trust, but that's beyond most ordinary users and even many of the
technical professionals I deal with.

It's a shame PGP was the target of so much persecution when it came out. Maybe
by now we would have worked out the key exchange problem and would all be
enjoying personally encrypted communication on the Internet. I sometimes feel
that any attempt to move beyond passwords without realizing that ideal is
doomed to failure.

~~~
hamburglar
I think one solution would be for the browser (or an extension) to expose an
SSH agent API through the DOM, but gate access to that agent with local UI
that confirms operations. "Facebook.com would like to view your public
identity information. Continue?" with an "always allow for this site" option.
"Facebook.com is requesting a signing challenge to verify your public
identity. Allow?" etc. It could even include an identity manager which would
allow you to generate different identities to present to different sites on
the fly. You could have the option of having the requests pass through to your
SSH_AGENT_SOCK (still gated by UI though) if you want, or you could just let
the browser maintain its own independent agent (or potentially a combination).

------
xnyhps
So you have a situation where the client has already authenticated the server
using TLS, and now the server wants to authenticate the client too. This
solution wants to do that by setting up a new channel, authenticating the
server /again/ and then also the client.

Yeah, I don't think this is a good idea.

------
wazari972
I love the idea, I think I'll implement something like that to automatically
log into the few services I host on my webserver: on machine boot and every
hours `ssh webserver echo $SOURCE_IP > token`, and on the web app, if token is
not too old in source address == $(cat token), then auto login.

------
kolodny
I may be missing something but this seems highly susceptible to man in the
middle attacks

~~~
davea37
If the web page was served over HTTPS and provided the SSH server's
fingerprint for the user to verify, wouldn't that get around the MITM risk?

------
vbezhenar
That technique would useful when user wants to add public key into his github
profile (or similar service). Instead of asking user to copy&paste his public
key, site might ask him to enter `ssh github.com authtoken` in terminal.

~~~
stephenr
So then you have two avenues for attack, if someone wants to inject their own
public key into your account - the Web UI and some form of custom SSH server.

Besides which you would need more than just "ssh github.com authtoken" \- it
doesn't identify who you are (thus knowing who to save the public key for)

~~~
vbezhenar
> So then you have two avenues for attack, if someone wants to inject their
> own public key into your account - the Web UI and some form of custom SSH
> server.

That's correct. SSH misses PKI and github can't sign their ssh public keys
with trusted authority. If someone intercepting your traffic, he can redirect
your connection to 22 port to malicious ssh server and save his malicious
public key to github. To prevent that, github must present ssh fingerprint
into their web page and user must check that fingerprint with one he can see
on terminal. Thanks for clarification.

> Besides which you would need more than just "ssh github.com authtoken" \- it
> doesn't identify who you are (thus knowing who to save the public key for)

authtoken is supposed to be an unique identifier and github server knows that
it's associated with your account.

~~~
stephenr
> github must present ssh fingerprint into their web page and user must check
> that fingerprint

yet another case where DNSSEC secured SSHFP records would automate this.
However, given that people currently commit and push passwords, private keys
and who knows what else to places like GitHub, it seems unlikely these people
would recognise why a connection might refuse (e.g. because of an invalid
fingerprint) anyway

> authtoken is supposed to be an unique identifier and github server knows
> that it's associated with your account

ah sorry I thought "authtoken" was meant to be some command to run on the
server.

Frankly I think things like adding a public key (whether to GitHub or a system
that allows SSH logins) over the internet, are probably safer behind a double
factor auth system (e.g. password + otp or client cert + otp) - the people who
need to use it can be shown how to copy their public key quite easily (if they
can't open Terminal.app, type "cat ~/.ssh/id_rsa.pub | pbcopy" and then paste
the result into a web form, can they really handle Git, or even SSH for that
matter?)

------
mjn
Interesting; this could potentially solve a pain point for me. I run a small
set of services for some research collaborators and have been phasing out
passwords, so users are authenticated solely via their public keys. That works
for most classic "Unix server" stuff. But for the use-case of a remote GUI for
scientific computing, the classic solution of network-transparent X is
gradually losing out to a more iPython-style solution of a browser front-end.
In which case I need to authenticate the same people in their browsers, and
it'd be nice to do it via the same public keys.

------
ddebernardy
I'm suspicious that this is any better than TLS and client certificates.

Plus, it's not entirely clear what's supposed to happen when your family and
friends are using your computer, or when your laptop is simply stolen.

~~~
IgorPartola
Surely you passphrase protect your id_rsa!

~~~
mkorfmann
Back to entering passwords (or passphrases for that matter)... Yay!

~~~
swadworth
That's a retarded retort. In the SSH case you have ONE password to remember.
Not one per website. Furthermore, the password never leaves your machine. Log
in to a hundred websites with SSL and a password and the NSA comes along,
collects all your passwords server side, knows which ones you reuse, knows
your password generation patterns, everything. You are completely nuts if you
think these two things are the same.

~~~
icebraining
You have a good point. You're also completely over-the-top aggressive for a
discussion about _website authentication_.

------
falcolas
I love this idea, but I have some issues with their chart, particularly as
related to authentication via email.

A developer with a few minutes of thinking time could get around the "red"
spots associated with email authentication, and fill in any missing dots
pretty easily.

And for better or worse, email is currently one of the better ways to create
an identity for the masses, and it's also one of the few systems that your
average user can justify the pain of setting up 2 factor auth on.

The only thing better would be to use text messages, if you could come up with
a way to lower the impedance for the user.

------
tux
Very cool. This could be used to count linux users. Like
[http://linuxcounter.net/](http://linuxcounter.net/)

~~~
nacs
I remember that site from years ago but it seems awfully out of date at this
point.

Even the Ubuntu distro's opt-in share-my-desktop-stats system likely contains
multiple times what Linux Counter is counting.

------
jrochkind1
> You can see where this is heading—a half-baked reimplementation of TLS
> client authentication with all the same usability nightmares.

Yeah, that's what I was thinking -- why would you do this instead of just
using TLS client auth? TLS client auth is a usability nightmare -- but I'm not
sure it's any _worse_ than what's in OP.

------
prateek_mir
A brilliant Idea; as far as usability for a normal user is concerned, How
feasible is it to modify a browser to take the command directly via the
address bar, and internally a thread can handle the ssh part, redirecting the
user directly to the newly generated link ?

~~~
icebraining
Not that hard (I've written Firefox extensions that run external programs),
but what would you gain over SSL client certs, which are already supported?

~~~
XorNot
I have an SSH key and use it routinely. I've never used SSL client certs.

~~~
stephenr
At some point in time you'd never used an SSH key, either. And then you did.

------
salzig
use <keygen>[1] and generate a client side certificate for authentication?

[1]:
[https://developer.mozilla.org/de/docs/Web/HTML/Element/keyge...](https://developer.mozilla.org/de/docs/Web/HTML/Element/keygen)

~~~
nacs
English version of parent:
[https://developer.mozilla.org/en/docs/Web/HTML/Element/keyge...](https://developer.mozilla.org/en/docs/Web/HTML/Element/keygen)

------
BrainInAJar
Why not just use HTTP Signature Auth ? (
[https://datatracker.ietf.org/doc/draft-cavage-http-
signature...](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/)
)

------
sparaker
A beautiful simple implementation for signing into websites using SSH. I think
this idea can be very helpful for developers, perhaps give them good scripts
to hot reload a patch on production servers.

------
neaanopri
What does "PTY allocation request failed on channel 0" mean?

~~~
duncankl
When SSH clients first connect they ask the server for a pseudo terminal
(PTY), to enable terminal colors, clearing the screen etc.

In this case the SSH server declines that request because it simply wants to
send back one line of text. The client falls back to text mode and works fine,
but issues the warning anyway. You can suppress it with `ssh -T
mars.vtllf.org` like I did in the demo video.

------
skratlo
This is brilliant. Here a full-fledged solution: the same way every OS
supports users, it should support identities attached to the user account
(~/.ssh). Upon OS installation / user creation, it would prompt the user to
either generate new identity, or import existing one (from a flash drive, from
a cloud, etc.). This would be the key pair. And the browser would
automatically use this, without any terminal session or any such non-sense.
Brilliant, right? No, because user accounts are commonly shared: here, can I
check my mail on your computer? Yes, password won again :P

~~~
swadworth
>Brilliant, right? No, because user accounts are commonly shared

Gee, I guess only I can drive my car. If only there were some way to share my
car with my spouse. Like having a second set of keys or something...

------
eatonphil
Would this become more usable if it was natively supported by the web browser?
Couldn't the browser take care of generating the keys and whatnot?

~~~
swadworth
<keygen> can generate client side keys. It's not very good, but it exists.

------
falsedan
You don't need to edit a hidden config file to remove an old known_host entry,
just run:

    
    
      ssh-keygen -R <host>

~~~
duncankl
Thanks for the tip, I wasn't expecting that feature to be part of ssh-keygen.

------
NietTim
Never thought about it like this, this is pretty ingenious!

~~~
mkorfmann
It's actually fairly simple, but not usable for 99% of web users.

------
jasonkester
_" 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 is not something that I love.

If you force me to use it just to log in to your website, I will decline to do
so.

~~~
IgorPartola
I think I found the Windows developer :). It is loved by pretty much everyone
but Windows developers because it really is the best thing since sliced bread.

~~~
vbezhenar
Funny thing is that many windows developers and administrators like to use
RDP, while *nix users generally don't like it at all (usually because RDP
doesn't allow easy scripting to automate routine tasks).

