[AnthonyMouse]

> Even with strong passwords, maybe you don't want someone attempting to authenticate so quickly. Could be DoS or trying to exploit sshd.

DoS in this context is generally pretty boring. Your CPU would end up at 100% and the service would be slower to respond but still would. Also, responding to a DoS attempt by blocking access is a DoS vector for anyone who can share or spoof your IP address, so that seems like a bad idea.

If someone is trying to exploit sshd, they'll typically do it on the first attempt and this does nothing.

> Also it's unlikely that your hotel's IP address is spamming the particular SSH server you need to connect to.

It is when the hotel is using the cheapest available ISP with CGNAT.

[hot_gril]

Good point on the DoS. Exploit on first attempt, maybe, I wouldn't count on that. Can't say how likely a timing exploit is.

If the hotel is using such a dirty shared IP that it's also being used to spam random SSH servers, that connection is probably impractical for several other reasons, e.g. flagged on Cloudflare. At that point I'd go straight to a VPN or hotspot.

[AnthonyMouse]

Novel timing attacks like that are pretty unlikely, basically someone with a 0-day, because otherwise they quickly get patched. If the adversary is someone with access to 0-day vulnerabilities, you're pretty screwed in general and it isn't worth a lot of inconvenience to try to prevent something inevitable.

And there is no guarantee you can use another network connection. Hotspots only work if there's coverage.

Plus, "just use a hotspot or a VPN" assumes you were expecting the problem. This change is going to catch a lot of people out because the first time they realize it exists is during the emergency when they try to remote in.

[hot_gril]

I already expect unreliable internet, especially while traveling. I'm not going to have to explain why I missed a page while oncall.