What about this solution? https://www.grc.com/sqrl/sqrl.htm

It's pretty much the same thing but using QR codes.

One thing that SQRL has is automatic management of different keys for each site. It wouldn't be hard to add that to the ssh version, though.

Using QR codes for getting the challenge is also nice because you can just read them with your phone on an untrusted computer.

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.

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

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"

@nly How does this system prevent me from setting up a website that looks like Paypal and giving you the address of my ssh server?

It doesn't, but your SSH server wouldn't be able to produce a valid token for Paypal.com.

Btw i'm not liking this SSH solution either, I was just pointing out that's still better than SQRL, which is awful in that it has exactly 1 advantage (it protects users against password reuse) and many nuanced flaws.

Host authentication is a job of SSL though. So you should simply not log-in on a website if it cannot be verified that it is actually Paypal. This holds for both SQRL and passwords and seems to be an independent issue. It also applies to this case because the ssh server is supplied by the website.