Hardening SSH with 2FA • Hacker News Board

Re: Hardening SSH with 2FA

#101

Post by rincebrain » Tue, Apr 23, 2019, 10:47 PM UTC

oarsinsync wrote: post #100

rincebrain wrote: post #68

Earlier quoted context omitted.

Do they offer a good solution to the dual problem of: - if you can flash/read everything, so can an attacker - if you have a blackbox nothing can peer into, how can you trust the device?

It looks like the very first FAQ answers that: 1) You generate your own root keys, to deploy onto the device, 2) You can't read the root keys back off the device once it's deployed.

That doesn't quite answer my question, I think.

My statement was that:

- if you have an opaque enclave on the device (e.g. a black box you can't peer into), you can't know what it's doing

- if you don't, you can read the private key bits out

Your statement was that it has a private enclave you cannot extract key material out of, which resolves the latter half of the question, but not the former, I think?

Re: Hardening SSH with 2FA

#102

Post by oarsinsync » Thu, Apr 25, 2019, 11:03 PM UTC

rkeene2 wrote: post #35

xnyan wrote: post #34

Earlier quoted context omitted.

SNI https://en.wikipedia.org/wiki/Server_Name_Indication

SSH does not use TLS, and does not have the TLS extension SNI.

It can be tunnelled over TLS using openssl

Re: Hardening SSH with 2FA

#103

Post by rkeene2 » Fri, Apr 26, 2019, 4:10 AM UTC

oarsinsync wrote: post #102

rkeene2 wrote: post #35

Earlier quoted context omitted.

SSH does not use TLS, and does not have the TLS extension SNI.

It can be tunnelled over TLS using openssl

That is true (and relatively easy to do with OpenSSH's ProxyCommand) but that was not the implication of the statement that HAProxy was being used in TCP mode to direct incoming TCP sockets to the correct backend SSH server based on the hostname using any SSH client that understands the SSH protocol.