Hacker News Reader

> s yet, there are no known exploitable vulnerabilities in SSH2, though information leaked by Edward Snowden in 2013 suggests the National Security Agency may be able to decrypt some SSH traffic. http://searchsecurity.techtarget.com/definition/Secure-Shell

I really don't understand how people continue to state wrong information about ssh. Is it because of Heart Bleed? SSH is 22 years old and is still a solid tool. The only bad thing about ssh is key management which this company is addressing.

There are other bad things about ssh. Tofu sucks balls and ssh users are far too comfortable with it.

Had to look it up. https://en.wikipedia.org/wiki/Trust_on_first_use

What would you replace it with?

Signed keys. Here's an example of how to do it from Digital Ocean: https://www.digitalocean.com/community/tutorials/how-to-crea...

Well, feel free to come up with a better solution. 3rd party trust roots are way worse.

The server key can be signed by a trusted authority, no need to trust on first use.

>1. A request and its signed response can only be used for a specific login attempt by SSH design.

>3. The app has an internal known hosts list, so it denies attempts to just replicate hostname to trick the user.

>4. The app has to be paired with each machine that can authenticate, or the key material must be stolen off a paired machine. "Timed" acceptance is per pairing basis, so abuse of that only works if you steal the right pairing. The app shows the name of the pairing when requesting approval.

So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host.

>2. The app, through some nasty hacks, receive the host auth blob from the server to verify. If you skip this, the request will be labelled as from "unknown" to "warn" the user. Such request are never auto-accepted during "accept for 1h" periods.

Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned.

> Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned.

Of course it is relevant. It means that you're unlikely to get anything "pwned". When someone logs in, an authentic request towards host A will appear. Given your proposed attack, a fraudulent request would appear a few seconds later towards "unknown host". The only way such an attack would go through would be if the user was confused which request was the legitimate one (which is clear if one says "unknown"). Otherwise, the user will already have approved the legitimate one, either with a timed or direct approval, neither of which will apply to the fraudulent one.

> So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host.

I am having trouble understanding your wording here, but I believe that you might have misunderstood "timed" approvals as being per login-target (e.g. "accept all github logins for 1 hour"), when they are per login-source (e.g. "accept all logins from my work machine for 1 hour").

If you get someone to do a "timed" approval, it means that you given the pairing data from the workstation that tried to login, you can perform any login within an hour towards any host. Such a timed approval is sort of a bad idea, but note that all approvals are still logged, so the user would at least be aware of the problem.

If the user doesn't do timed approvals, then you can only ever "pwn" one machine at a time. However, if the request shouldn't be obviously fraudulent, it would have to be towards a host the person uses often, and it would still have to be using pairing data from the workstation the user is currently working on.

Both such attacks fails the usual sanity check: It requires you to already have compromised the user so much that the attack is pointless to do. If you are able to obtain the kryptonite pairing data from a users workstation, needed to either use a timed approval or to make the request not look obviously fraudulent, then you also have the privileges to replace the ssh client with an evil one (e.g., one that signs evil login requests rather than the local one, one that creates persistent evil shell sessions, etc.).

With such privileges, all the users machine-local private keys would also be implicitly compromised. The kryptonite key could be abused, but would not be compromised (that is, hosts have been accessed with your privileges, but the key is still safe and does not need rotation).

>2. The app, through some nasty hacks, receive the host auth blob from the server to verify.

What do you mean here? is the host auth blob coming from the third party service you are trying to auth to (e.g. Github), or from the initial client making the auth request (e.g. "Request from Macbook")?

It puts a little nc-like tool as ProxyCommand, parsing all traffic for host-auth like packets coming from the target machine. It then sends it to the app, so that it can verify the signature of the remote host before prompting you for approval.