[michael_michael]

MFA for my Synology failed recently because (I suspect) I let the drive go unused for a while and it lost sync with the time server. So all one time passwords my password manager generated were "wrong". Off in time by some unknown amount. No way to fix it, since I would need MFA to log in and fix it anyway.

I had to reset the administrative UI and lose my user settings/admin preferences, but it did hang on to the data on the drives, luckily.

[antsar]

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.

[olyjohn]

Kinda defeats the whole point of MFA if you can just bypass it like that.

[caconym_]

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.

[TrickardRixx]

If the SSH key is password-protected, then SSH access is MFA.

[olyjohn]

Not sure that's true... If the key gets compromised, having it password protected does nothing.

[jmprspret]

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.

[olyjohn]

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.

[password4321]

> If the key gets compromised, having it password protected does nothing

I apologize for my ignorance in advance: having a private key file password-protected does nothing?

I guess I'm not understanding what you mean by "compromised"?

[hatthew]

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.

[olyjohn]

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.

[doubled112]

My SSH key is on a YubiKey. How many factors is that?

[eli]

1 if it isn't password protected and 2 if it is

[crazygringo]

Which is why you have to manually enable SSH and it warns you that it's a big security risk.

You're entirely right -- the "proper" way is to login with MFA, enable SSH, do your thing, and then re-disable SSH.

[jethro_tell]

Well, maybe, if you have an ssh key, instead of an ssh password, there's a lot less surface area there.

[naasking]

Old tricks are the best tricks!