Seems like way easier way would be sshing for the first time and just typing `sudo reboot`. If VM reboots, it is yours Or cat-ing some secrets that would be on target machine but not attacker
A mitm does not redirect your ssh login to their machine
Stop MitM on the first SSH connection, on any VPS or cloud provider
61–70 of 80 posts
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#62[dead]
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#63Earlier quoted context omitted.
SSH has *ANOTHER* built-in solution, in the form of the SSHFP DNS record. If the DNS record for the host has an SSHFP (SSH FingerPrint) record, SSH will compare it to the retrieved public key(s) and refuse the connection if there is a mismatch. It can be configured to require DNSSec for this, or to only reject if it gets a secure rejection (to prevent DoS). It works perfectly, has no notable down sides (just add a DN…
It is very insecure unless you use dnssec, isn’t it? Just means an attacker also needs to mitm DNS if you MITM the host. Not trivial, but depending on setup might not be harder.
I recommend reading the description of the option `VerifyHostKeyDns` in the `ssh_config` man page.
If set to `yes`, you get automatic trust-on-first-use (no user prompt) if you use DNSSec, and you get the current asking-the-user behavior if your DNSSec is broken or you are under attack.
Obviously it's more secure if you use DNSSec, because that way you can reflexively deny any request to manually verify a host key, but it provides value regardless.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#64Earlier quoted context omitted.
> Other comments say that this mitm stops working when you use public key authentication. It doesn't completely stop working; a MITM can still pretend to be the server, it just can't authenticate to the real server on your behalf. You could be doing all your work in a fake server controlled by the attacker, while the real server sits there untouched.
If that were the case then I don't think the OP approach works either.
It does note that it only protects against an attacker "who learns the cloud-init user-data at any point after the script terminates".
If the attacker can get the cloud-init user-data while the script is still running (in the time between sending the cloud-config.yaml and connecting with SSH to the machine) that would still allow MitM, but would require more effort on the attacker's part to leak the cloud-init data.
The point of the script was that leaking the cloud-init data after the script has completed is harmless.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#65A big class of attacker is nation state attackers who do not want to risk discovery. A big way to deter them is to keep remote log files which, if analyzed, will reveal any attack. For example, if both ssh-client and ssh-server kept a fingerprint of the session key in some append-only logfile, then a later administrator could compare the logfiles to know if an MITM happened. Suddenly, nation state attackers won't be…
Example of a nation state attacker that risked discovery and got discovered: https://notes.valdikss.org.ru/jabber.ru-mitm/.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#66> The technique appears to be new: I haven't found a proper write-up of this, nor of any other provider-independent solution. Maybe I'm missing something but SSH already has a built-in solution for this, key-certs. Just sign the server key with a private CA key you trust.
The article describes a method of securely seeding private key data to newly provisioned servers. It's a bit of bootstrapping problem, and not something a PKI can solve.
You usually need some form of trusted communication with a new server until you can give it its real identity, in the form of host names and cryptographic keys. In an enterprise environment this can usually be done with some sort of isolated management or provisioning vlan. In a cloud environment, I've seen all sorts of more or less hacky solutions but since it depends a lot on specific details of your networks and APIs, bespoke solutions are fine.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#67A big class of attacker is nation state attackers who do not want to risk discovery. A big way to deter them is to keep remote log files which, if analyzed, will reveal any attack. For example, if both ssh-client and ssh-server kept a fingerprint of the session key in some append-only logfile, then a later administrator could compare the logfiles to know if an MITM happened. Suddenly, nation state attackers won't be…
Example of a nation state attacker that risked discovery and got discovered: https://notes.valdikss.org.ru/jabber.ru-mitm/ .
Oof. The answers by Hetzner and Linode read as if they were straight out of a dystopian novel.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#68Earlier quoted context omitted.
A few do. Though a more common way of securing the loop is to take the desired user public key during the build process. Assuming you trust that the host control panel (or API server) hasn't been hacked, which you are assuming anyway if you trust a host fingerprint given to you that way, that should be as secure. For a small bit of extra assurance, to protect from an extra very unlikely attack, generate a new key pai…
AFAIK this is not secure. The SSH protocol doesn’t require the server to know the client’s public key for the connection to succeed. Instead, the client actively sends its public key to the server while authenticating, and the server just decides whether to allow a connection or not. OpenSSH will typically match the client’s key against a fixed list of keys, but nothing stops a rogue server from allowing connections…
It does need to know the public key. The AuthorizedKeysCommand does not provide a yes/no answer, it has to respond with a list of full public keys (or certificates) that are authorized to connect for a given user id. The SSH server then uses the public key to challenge the client to demonstrate it has the private key.
However, an easy attack in the same ballpark, is to accept the connection without any password or public key auth, and then accept agent forwarding, and ask that agent connection to authorize a connection to a target server, with the user's keys. Never forward your agent connection to an untrusted host. Though -- I imagine this pattern is common when setting up a new host -- trust the first connection, and forward your agent so you can pull resources (like git repos) from the new host to set it up ...
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#69Earlier quoted context omitted.
If that were the case then I don't think the OP approach works either.
It does note that it only protects against an attacker "who learns the cloud-init user-data at any point after the script terminates". If the attacker can get the cloud-init user-data while the script is still running (in the time between sending the cloud-config.yaml and connecting with SSH to the machine) that would still allow MitM, but would require more effort on the attacker's part to leak the cloud-init data.…
Yes, I'm just saying if you think you've set up a server with Hetzner, but Smersh is able to intercept your first interaction with it and present you a server that you think is the one you created, then it doesn't matter how much you try to harden the compromised server. But if you get MITM later in the the process, the above is the scenario you are worried about.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#70Earlier quoted context omitted.
Because log processing is handled in the kernel/root/system? Is this a trick question? See also: rsyslogd
I think the idea is the attacker didn't compromise both the local machine and the remote log sink machine. If you want to get really fancy the techniques used in cert revocation logs/blockchains could be used.
Blockchain is completely unnecessary (as it always is; I thought people stopped trying to ram that garbage into everything years ago).
I was answering this question from GP:
> Unfortunately it appears openssh doesn't even have an option to create such a logfile!! Why not??
The answer is because in Linux systems the logging logistics are handled at the system level, just like starting and running openssh itself. The answer to "why not" is because that's the logging system's job, not openssh's.
rsyslogd is one simple and direct way to distribute logs to remote machines.