4 ms·

Just be careful which time source you use. One of our servers was configured to use tick.usno.navy.mil and tock.usno.navy.mil back 10-15 years ago or so. The Na

Just be careful which time source you use. One of our servers was configured to use tick.usno.navy.mil and tock.usno.navy.mil back 10-15 years ago or so. The Navy had an "issue" with the time they were sending out. The overnight result was several licensing servers wouldn't authenticate and we were locked out of those systems(SSH needs accurate time, within minutes I believe). We discovered the discrepancy by logging in locally (we were in the same building but a different office) and changed the time servers and then the sync method to resolve the issue.

bityard 3y ago
> SSH needs accurate time, within minutes I believe You may be mis-remembering a few details, SSH does not care about the time at all unless you are using _very_ short-lived SSH certificates.
- lazide 3y ago
  Time based OTP is pretty sensitive though. Probably that is what broke?
  - crote 3y ago
    The irony is that the TOTP spec explicitly takes this into account. By default tokens are valid for 30 seconds, with a token from the previous 30-second window also being accepted. Being off by more than that is pretty rare for NTP-connected systems. The specs also provide ways to deal with a dedicated hardware token slowly going out of sync by keeping track of the last-known clock drift, but that's pretty useless these days and can even do more harm than good.
    - lazide 3y ago
      The poster was referring to minutes, which has also been my experience. Something goes wrong, and suddenly you’re an hour off. Blam, now you can’t login. :s
- fanf2 3y ago
  They might have been using kerberos authentication?
- xorcist 3y ago
  Kerberos is very particular about time.
  - freedude 3y ago
    This system operated an SMB share so Kerberos is probably what locked us out.
- freedude 3y ago
  You are correct and I believe it was Kerberos that we were locked out of on this system since it was running a SMB share.

bityard 3y ago

> SSH needs accurate time, within minutes I believe You may be mis-remembering a few details, SSH does not care about the time at all unless you are using _very_ short-lived SSH certificates.

lazide 3y ago
Time based OTP is pretty sensitive though. Probably that is what broke?
- crote 3y ago
  The irony is that the TOTP spec explicitly takes this into account. By default tokens are valid for 30 seconds, with a token from the previous 30-second window also being accepted. Being off by more than that is pretty rare for NTP-connected systems. The specs also provide ways to deal with a dedicated hardware token slowly going out of sync by keeping track of the last-known clock drift, but that's pretty useless these days and can even do more harm than good.
  - lazide 3y ago
    The poster was referring to minutes, which has also been my experience. Something goes wrong, and suddenly you’re an hour off. Blam, now you can’t login. :s
fanf2 3y ago
They might have been using kerberos authentication?
xorcist 3y ago
Kerberos is very particular about time.
- freedude 3y ago
  This system operated an SMB share so Kerberos is probably what locked us out.
freedude 3y ago
You are correct and I believe it was Kerberos that we were locked out of on this system since it was running a SMB share.