... like you need to when using TOTP for anything

Maybe I'm irrational, but it's one of the things that makes me real hesitant about where I deploy TOTP. Sometimes my cellphones randomly have a wildly wrong time -- a misbehaving (or malicious) cell-tower perhaps? And sometimes my computer gets the wrong time too -- e.g. booting between Windows and Linux screwing up the system timezone setting, or ntp failing to start properly, or when I busted up my CMOS. And I have to wonder, how secure is ntp from someone just spamming a system with the wrong times which can block me out?

I'd almost rather a combined thing where it's HOTP but it also rotates once per day like at midnight? Does anything do that, or does it even make sense? Is there a reasonable alternative -- challenge-response maybe?

> Sometimes my cellphones randomly have a wildly wrong time -- a misbehaving (or malicious) cell-tower perhaps?

If you experience that often, I would probably disable the setting to automatically set time from the network.

> booting between Windows and Linux screwing up the system timezone setting

That’s easily fixable with one registry change (RealTimeIsUniversal). You can also tell Linux to use the local time, but Linux will be less happy about that than Windows (Linux won’t write to the real-time clock automatically, for example).

The Linux/Windows timezone issue can be fixed with a registry setting [1]

If for some reason your time is off (e.g. after 3 failed attempts), it's easily detectable and fixable. Just browse to time.is [2], and your time is off, and set it manually if needed.

Because there's an increased dependency on accurate time, bad network time is now quite a rare occurrence in my experience. I haven't seen it happen in the last 3 years.

Once you point NTP to a trustworthy service (e.g. time.google.com [3] or time.cloudflare.com [4]), you won't have any issues.

The Google time server offers leap smear [5], and the Cloudflare one offers NTS (authenticated NTP).

1. https://wiki.archlinux.org/title/System_time#UTC_in_Microsof...

2. https://time.is/

3. https://developers.google.com/time

4. https://developers.cloudflare.com/time-services/nts/usage

5. https://developers.google.com/time/smear

It's one thing to lock yourself out of your application or admin interface when NTP breaks. It's another thing entirely to lock yourself out of recovering the server entirely when clock skew inevitably hits you.

If you really want 2FA for SSH, use something like Yubikeys that increment a counter and generate tokens based on that counter. And use it during the actual authentication session, not for figuring out which magic port the server will be listening on. You never have to worry about synchronized clocks, just a database tracking the highest counter value ever seen, so that previous values can't be reused.

Your server has NTP. Your client likely, too, if it has enough network to connect to the server. If it does not use NTP, it's easy to set the time within the minute or so required manually.

Hardware clocks are famously unreliable and inaccurate. NTP has failure modes that can result in servers being wildly out of sync with reality. Letting either one of those hose your ability to log in and diagnose/recover the system is a mistake.

It really depends on what you need. Yes, hardware clocks and NTP have failure modes[1], but how common are they? Hosing your bootloader or its ability to find the kernel is also a thing that happens where you definitely need some lower level access, which would also help with a mismatched server clock and TOTP. It depends on a lot of factors whether that is more or less common than NTP failure modes.

Would I employ this for a critical commercial server? No. Would I do so for my private server? Absolutely, without hesitation. If it really loses track of time so badly (hasn't happened yet to my knowledge), I can just log in through virtual console.

[1] I'm excluding drift and inaccuracy, since from my anecdotal experience they are usually not that bad.

I disagree that requiring the time to be correct precise to 30 seconds is "a mistake" in the general case, but it is a good point that this might happen in some weird edge case (where also changing the local clock +/-60s is not enough to fix it). Having a fallback that lets you in via a mechanism that does not depend on any external factors or uninterrupted power supply does seem like a good idea for important physical infrastructure. (For virtual stuff, in such a weird case you can always just modify the disk image to get ntp from a working host and boot again.)

From looking at the code, seems like it would be a pretty simple change to make the server accept several addresses, derived from the current time plus or minus a small number of 30-second intervals. That allows you to tolerate a small amount of clock skew, and if your clock is off by more than a minute or two, you should probably fix it anyway.

Just need to SSH in to fix it....

I'm not sure how you could really run a server environment of any size without that