Hacker News Reader

Comment by waihtis | Hacker News Reader

Doesnt the TOTP in this case concern the listening port for sshd, so it doesnt actually touch the authentication in any way? Just switches the port in a TOTP’esque manner

View on HN

The point is that if the attacker somehold got hold of the primary login credentials (username + key/password), then they can easily bypass this scheme with a port/address scan. This can be done very quick[1] and is hard to rate limit. Furthermore, an attacker that can eavesdrop on the user's connections can infer the OTP since it's being transmitted in the open., but if it was done through a PAM module they wouldn't be able to because it's encrypted.

[1] https://nmap.org/book/synscan.html

Both scenarios assume a pretty heavy compromise already in place before the ssh control starts crumbling

there is no "easily bypassing this scheme with a port/address scan" when it comes to ipv6 /64 ranges.

If you could scan 1 million IP addresses a second on a /64 (which is absurd), it would take 600K years to scan a full /64.

1 million IPs per second is doable with gigE if we're just sending a syn to port 22. I'm going to go out on a limb and assume your server has at least gigE.

However I don't think my server has 600000 years of runtime, or a sane firewall config is gonna allow 1 million connections a second.

Not sure why youre getting downvoted, I think an nmap based attack against this kind of rotating setup sounds borderline ridiculous

This does not use a full /64.

> If you could scan 1 million IP addresses a second on a /64 (which is absurd)

Not at all, I regularly scan the internet at well over 20Mpps.

This solution switches the listening address (IPv6 address), not the port.

Indeed you are correct.. Fruits of multitasking..

Reply on news.ycombinator.com