That seems completely arbitrary. A decrypted SSH key is simply the combination of SSH key and password. It's just like putting a key card and a (molded) fingerprint into a bag. Just because you can combine two things into one doesn't mean they aren't two factors.

Interesting point. It is two factors to the user (password knowledge + certificate possession), but the server only has one factor to check against.

The important distinction here is that the server cannot enforce the presence of the second factor. It has no way to know if your private key is encrypted with a passphrase or not. For a workplace/enterprise environment, this is probably a problem, but it can be mitigated by endpoint device policy (which you need in such an environment anyway; users should be working from managed workstations not random devices). For a personal-use context, it's a feature that the server cannot see or control how you manage your keys.

@PaulDraper No. It's like putting your key inside a box closed by an other key. We determine "multi-factor-icity" by looking at the door. Does the door have multiple lock devices? If yes it's multi factor, if not it's single factor. You can put your key inside a box, inside a box etc and still have a single keyhole, i.e. single factor authetication. The whole point of multifactor authentication is that providing the server with one of the factors isn't enough. This is like the attacker having one of the keys that can be used on the door.

@PaulDraper Let me ask you this: Would a username+password combination, stored in an encrypted Keepass database, be 2FA for you?

@R.. so? 2FA does not one single part of the system to require both factors. If a computer is password protected in a locked room, it requires two factors to access the computer (physical key and password). The computer doesn't enforce both factors. The room doesn't enforce both factors. Together they do. Moving the computer to an unlocked room, or writing the password on the key would reduce it to 1FA. But until I do that, it's still 2FA.

@GiacomoAlzetta unless the door has multiple lock types, it is not a multifactor. Door with three classical locks requiring three keys is still single-factor. A door with classical key, and with PIN keypad is however two-factor (as long as you need to enter both) .

I'd put In fact, the server is completely unaware if your private key is protected by a passphrase or not. in it's own paragraph, and/or bolded. That to me was the key point that I was having trouble coming up with when mentally refuting the "Yes" answers that I knew seemed wrong. Adding it at all is a big improvement, but IMO that's the key idea of 2FA: the server is independently checking both factors. Otherwise it's just extra protection of the secret for the single factor. That idea is there in the rest, but it didn't come through clearly right away from just skimming the first time.

If you could somehow hypothetically authenticate with an SSH key (either with or without password protection as the server doesn't know) as well as your user's password, would that be considered 2FA?

@CaptainMan If the server required both the password and the private key, then that would be 2FA, since compromise of either of them would not give access to your account, and both could individually be revoked.

@MechMK1 yes it would. I cannot get access without having the database and knowing the encryption password. True, there is possible single piece of information that exists that would grant me access. But that's an absurd way to analyze it. A copy of my server's files would also give me read access to my server's files. But you can't just conjecture the appearance of information of thin air.

@PaulDraper No, you are mistaken. Storing a password in an encrypted file does not make it 2FA. Because if the hash gets leaked (e.g. through SQLi) and subsequently cracked, the "second factor", aka. your password for the encrypted file, does not matter at all. The whole point of having 2FA is that you always need both factors to authenticate.

Even if this isn't 2FA this answer fails to live by its own definition. "That means your system should stay secure, even if one of the factors is compromised" Let's test. Test 1: Password (what you know) is compromised. System secure. Test 2: SSH key (what you have) is compromised. System secure. QED.

I would argue that a software certificate or key is „something you know“ and not „something you have“; there‘s a reason, HSMs generate the key themselves to solve this problem. The factor types „something you know/have/are“ are often helpful in identifying wether it‘s multi-factor. A part about that would make the answer better.

@PaulDraper Again, you are mistaken. If "the private key", not "a file containing the private key" is being leaked, your account is breached. If your password is Password1!, and you encrypt that file with a randomly generated key and store that file on a disk inside a safe, then it's still not Multi-Factor, because I only need to crack one part to compromise your account. I don't need to pick your safe, crack your decryption and then steal your password.

@TobiNary The lines between "something you know" and "something you have" are a bit blurred. For example, would a 256-character long random password in your password manager be something you know? I would say no, assuming that "something you know" implies that I can recite the required factor from knowledge.

@MechMK1 yes, you the two forms can be leaked together at access time. Just like a video can leak voice recognition and PIN entry when they are combined at access time. But voice recognition and PIN entry is still 2FA.

@PaulDraper but to compromise this system you don't need the password, you only need the private key. If you can get the private key while it's decrypted, you can access the server without ever knowing the password. A video of voice + pin reveals both factors, and you need to use both factors, so your scenario isn't comparable. A better analogy is a physical key in a safe. If you can steal the key while it's out of the safe, you can open the lock without ever knowing the combo to the safe. The door doesn't have multi-factor authentication, just a normal lock.

@Michelle Many people, including me, have argued exactly the same way, but Paul keeps insisting that just because he can make a setup that requires two factors (e.g. encrypting a password), makes an authentication 2FA. I gave quite a long-winded example in the chat, which illustrates why this belief is wrong. But then again, if he chooses to believe, then let him believe.

The door with one or two locks arguments here depend on where we consider the door to be. Apparently most consider it at the server giving access because otherwise regions behind the door (i.e., on the wire) are relatively easy to investigate. Then again, this could be seen somewhat like shoulder-surfing the secret info a properly 2FA-authenticated user can access. Or think of a bad implementation of a website where you need a password, plus OTP-token password, plus fingerprint, plus face recognition, plus whatnot to login - and then the authentication state is held in a cookie ...