[londons_explore]

A 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 interested in MITM-ing at all.

Unfortunately it appears openssh doesn't even have an option to create such a logfile!! Why not??

[heinrich5991]

Example of a nation state attacker that risked discovery and got discovered: https://notes.valdikss.org.ru/jabber.ru-mitm/.

[ranger_danger]

How do you know this was a nation state attacker?

[londons_explore]

Linodes response of 'we have observed no illegal activity and are closing this ticket' is as close as you can get to 'yes, this is a legal wiretap and we aren't allowed to tell you about it'.

[codethief]

Oof. The answers by Hetzner and Linode read as if they were straight out of a dystopian novel.

[hnlmorg]

Couldn’t the MITM ssh server just forward the client’s fingerprint to the legitimate server?

If so, the legitimate server wouldn’t have anything in their logs that would help detect such an attack.

OpenSSH does log other telemetry though.

[cesarb]

> Couldn’t the MITM ssh server just forward the client’s fingerprint to the legitimate server?

The client sends not only the public key, but also a signature, and that signature depends on the output from the key exchange, so it's "bound" to the shared keys negotiated between the client and the server. If the MITM server does separate key exchanges with the client (pretending to be the real server) and the server (pretending to be the real client), the signature won't match; if it forwards the key exchange between the real client and the real server, it won't be able to decrypt the packets.

That's the best thing about SSH public key authentication (and HTTPS client certificates): even when MITM can impersonate the server to the client (because the client didn't verify the host key), it can't impersonate the client to the real server.

[mbxy]

Let me see if I understand correctly: Client takes its own public key and the server's public key and creates this signature.

MITM can take its public key and the client's public key and send the resulting signature to the server instead of forwarding what it received from the client.

Do pretty much the same exact thing: MITM PK + Server's PK -> Client. Now client has a signature as well. The signatures that client and server have are different but that is OK as long as MITM can see and change all communication.

It has been a while since I went through the details of the protocol, so I must be missing something. What is it?

[cesarb]

What you're missing is that, to create a signature, you need to know the private key corresponding to the public key; it's an asymmetric algorithm.

> Client takes its own public key and the server's public key and creates this signature.

According to https://www.rfc-editor.org/rfc/rfc4252#section-7 client takes its own public key, the "session identifier", and a few other things, and creates this signature (using the private key corresponding to that public key). According to https://www.rfc-editor.org/rfc/rfc4253#section-7.2 that "session identifier" is a byproduct of the key exchange.

> MITM can take its public key and the client's public key and send the resulting signature to the server instead of forwarding what it received from the client.

That's not possible, since the MITM doesn't know the client's private key (and using a different public key will be rejected by the server).

> Do pretty much the same exact thing: MITM PK + Server's PK -> Client. Now client has a signature as well. The signatures that client and server have are different but that is OK as long as MITM can see and change all communication.

You're confusing the Diffie-Hellman Key Exchange with the Public Key Authentication Method. When you MITM the key exchange, the shared secrets the client and server have are different (one side has a secret derived from the client and MITM keys, the other side has a secret derived from the MITM and server keys), but that works as long as the MITM can see and change all communication (basically, decrypting it and encrypting it again).

But since the secrets are different, the session identifier is also different. The MITM can't forward the signature from the client since the server will fail to verify it due to the mismatch in the session identifier; the MiTM can't create a new signature with the client public key since it doesn't have the corresponding private key; and the MITM can't create a valid signature with its own public key (and the corresponding private key) since that key won't be in the authorized keys list for that user account in the server.

[flumpcakes]

> Couldn’t the MITM ssh server just forward the client’s fingerprint to the legitimate server?

Fingerprints are derived from the certificates/private keys. Unless I don't understand some basic crypto, or SSH works in some obtuse way, I do not think it would be possible for the MITM attacker to present the server with the true client's fingerprint unless they also had had the client's private key.

[Groxx]

To try to add some explanation here: the server doesn't send the fingerprint. The server sends the public key, your computer just shows a fingerprint because it's more human-friendly and sufficiently secure.

If they forward the real key, so it matches the fingerprint, and you use it, they can't MITM the request because they can't read the contents.

[MaxBarraclough]

> Fingerprints are derived from the certificates/private keys

SSH fingerprints are derived from the public key. https://superuser.com/a/453022

[hnlmorg]

Ah thanks for the explanation. It’s been a long long time since I’ve delved this deeply into the topic.

[daveguy]

Because log processing is handled in the kernel/root/system? Is this a trick question?

See also: rsyslogd

[dboreham]

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.

[daveguy]

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.

[iberator]

how would you create REAL write only logs?

syslog > /dev/lpt0 printer?

[bitfilped]

Forwarding to WORM tape is one way. Of course that still involves network and likely a buffer somewhere.