Is the certificate for that domain pinned? If not, just host it locally. In fact, I'm going to try doing that. Have you already checked the Docs? Somebody probably already published a gist somewhere with the needed path
Hover over the "minutes ago" string on any of those comments & you'll see the original timestamp. I guess this is a repost, comments got merged, and the "minutes ago" strings are cached/pre-generated from the old thread?
Experienced this too. Having SSH access enabled on the Synology saved the day. There's no 2FA prompt on SSH, so you can SSH in and manually fix the time.
SSH and the web UI are two different interfaces running on separate ports that can be firewalled differently. You might, for instance, expose the web UI on an external port on your router while restricting SSH access to the NAS's subnet. In that case, the MFA is a critical extra layer of security.
If your private SSH key is password protected, it is encrypted symmetrically with that password.
If somebody steals your password protected private key file, having the password protection there means they have to bruteforce the password. It does not 'do nothing'. Its an extra layer. If your password is secure enough, it can protect you from having the ssh private key decrypted.
It's an extra layer, but is that really another 'factor'? MFA would prevent someone with a compromised key from logging in. Password protected keys do not.
I think the point is about parallel vs serial layers of security. In a typical website account that is protected by password and SMS OTP, both of them need to be compromised for a bad actor to gain access. If they have just the password, they'll get stuck at the SMS token, and if they intercept an SMS OTP, they won't be able to get to the form where they can enter it. In contrast, a password-protected SSH key isn't pure MFA. If they have the password, they still need to get the private key file before they can use it to get the private key. However, if they have the private key, then they don't need the password at all. The password only protects you from people stealing the file, not from the stealing the key itself.
Compromised, meaning someone has the key in an unprotected format, or they somehow got your password. Say someone manages to MITM you somehow and get your password to the file, or they manage to crack it, or phish it out of you. Then they can just take the key and use it freely to log into your things. With MFA, there's no way that any key can be used to log in as long as the other factor exists. If you have to push OK on your cell phone to log in for example, the key is useless without physical access to your phone.
I'm not saying the password protection does nothing, it makes the key harder to crack but it's not another factor. It's simply an extension of the existing key. In other words, it's just a longer password.
Similar: A growing chunk of my support calls have the audio SO LOW that I have to turn on speakerphone and shove the thing halfway down my ear canal to decipher what they're saying. Asking the agent to speak up gets a response like I'm the first person all day to complain about this.
I guess "due to COVID", companies "just can't control" the quality of the microphone their support staff are using. Surely this has nothing to do with the side effects: it's impossible to make a usable recording of the call (to hold them accountable), I'm frustrated with the experience (and less likely to consume their support resources in the future), and maybe I'll even give up now (saving them money on a product exchange, credit, or whatever I'm calling about).
See also: long holds with noisy corpaganda instead of music, keeping you on the phone while we "fill some things in", "oops the system is loading", and so on.
Its not like these are unsolvable problems. But, money. And regulatory capture.
