Hacker News Reader

Comment by F30 | Hacker News Reader

MITM attacks are designed to not be detectable, so the solution is to have tooling which prohibits them – exactly what is lacking in this case.

For web, using TLS (SSL) is a good start. This could be improved further by using HSTS, HPKP, DANE etc. (not sure if A+ already implies them anyway).

For SSH, you need to have an out-of-band way to get the host keys or use something like an SSH CA.

View on HN

What does that mean out-of-band? I'm not good with SSH, I'm not using 2-factor key based, also in general it makes sense to have separate servers right? Like one server that transfers request to a server closer to another country. Not Cloudflare but your own thing assuming you rented from different datacenters in the world. Sorry not related to the question.

edit: literally band? Like another wavelength/connection?

Out-of-band means you need to transfer (or at verify) the ssh host key over something other than ssh for the initial connection. The host key is how the client verifies the server is who it says it is. The client caches the key after the initial connection. But for that initial connection, there's no way to know that the key isn't that of a MITM attacker.

One way to get the key out of band might be from the AWS console for example. Presumably that connection is protected via HTTPS where the CA infrastructure (theoretically) can protect against MITM attacks.

BTW, it's also possible to setup ssh to use certificates instead of simple keys which might make sense depending upon how many hosts you manage.

Thanks a lot for the information. You mentioned AWS console, that's not service-specific right? I haven't used AWS before. At any rate, lots too look up/research I appreciate your time.

At the moment I'm just dealing with a cheap domain-mapped single-core vps

In that case, from an existing client with the SSH host key installed, or with your VPS provider's login shell system (if any), read the files '/etc/ssh/ssh_host_$ALGO_key.pub'. Each of these files will yield a line like this:

  ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBA4Ljuxwb9ss74agSmMRlBZdnIwMHprWIZ3Ts3G+hxnMmcQxeMAWoA4YXZwbrpQulFjDhjGqQoAGF+MKWXBpaeU= root@ip-172-31-17-215

These are all different hostkeys that the server might give to clients, depending on their mutually-agreed signature algorithm. This is in the same format as a line in the known-hosts file; all you need to do is replace that last bit (in my example, root@ip-172-31-17-215) with the hostname by which you log in (e.g. someserver.example.com). Once you've done that, append the results to the known_hosts file, either for your user account (~/.ssh/known_hosts) or system-wide (/etc/ssh/ssh_known_hosts).

tl;dr: replacing HOSTNAME with the hostname by which you access the server, run the following command on your server and append its output to ~/.ssh/known_hosts on new clients:

  cat /etc/ssh/ssh_host_*_key.pub | awk '$3="HOSTNAME"'

Thanks a lot. Right now I just use PuTTY, possibly SSH by command line (OS terminal). I'm not sure what I would put for the hostname that you mentioned (some domain) I imagine this will come after you do the out-of-bandwidth access thing which at the moment I just have one server but I think you can do it on the same server "on another bandwidth" yeah. I'm still not 100% but thank you for this.

Any kind of direct console access can be used (which many VPS providers offer).

A different network connection (With physical infrastructure you might actually use a completely different network) that you can use to move private keys or any other sensetive information without exposing it to the Internet. We use such a network to monitor all of our infrastructure, and for iLo.

Thanks for your input. I have to look into this more. Have to plan stuff out for the future when growing past the single vps "instance"

Reply on news.ycombinator.com