I don't think the idea was suggesting that TOTP would be the _only_ method to get in. In fact the code just decides to accept or reject the incoming connection. The normal SSH auth flow would still need to be completed.

So you would need to brute force SSH (which is already decently hard) AND brute force the IP every 30 seconds.

This would stop the constant and relentless failed auth logs. (Yes there are other methods, but this one is novel and good as well)

Definitely a cool project. And I agree this is a bad idea in practice for many reasons.

But I wasn't aware that TOTP was brute-forcable. What is the mechanism to achieve this (given only a set of IP address and their timestamps)?

TOTP implemented this way is brute-forceable because you can just connect to all of the IP addresses (or pick however many connections you can practically make in 60 seconds and hit those).

There's no way to lock out after N failures or even to rate limit attempts.

> There's no way to lock out after N failures or even to rate limit attempts.

Given it’s a single machine with a /80, couldn’t the machine rate limit attempts to any IP in the /80? Ie rate limit by source, and separately rate limit by destination. Cover both bases.

The way I understood it, only the correct IP address would even be connected to anything, the rest would just fail. You probably could do something like that, yeah.

Good point, just had a look at the code. The NF queue will receive packets from all IPs in the /80 and they are all processed and validated by the ghost program that reads from the queue. So it could do the rate limiting there with full visibility.

https://github.com/aidansteele/ipv6-ghost-ship/blob/main/mai...

A /80 prefix is equivalent to 65536 ipv4 Internets. Not so brute-forceble.

The random part is six digits. I'd say pretty brute-forceable.

The TOTP spec (rfc6238) allows up to 10 digits or 10 billion unique values, a bit bigger than IPv4's space.

Running anything like fail2ban on IP address misses would stop brute forcing in its tracks.

Both good ideas.

None of this fixes even a passive mitm attack, but it's still better.

Putting the IP block over WireGuard fixes both issues.

If you're using wireguard don't you already have a secured connection and don't even need any of this?

If the computer is stolen or compromised, but the TOTP device remains secure, then access will be blocked.

Actually, occurs to me now, the brute force approach could still be used then, so that does have to be mitigated separately (which is possible).