Is an SSH key with a passphrase a 2FA?

Question

This is a really theoretical question, but if I use an SSH key with a passphrase to login on a server, could this be considered as a two-factor authentication (2FA)?

Indeed, I need the SSH (private) key, which could be considered as the first factor, and the passphrase which could be the second one.

If we compare to a single password for login, I see two 'elements' with a passphrased SSH key.

Answer 1

A second factor is defined as independent of the first factor. That means your system should stay secure, even if one of the factors is compromised (and you are aware of the compromise).

For example, a door badge and a fingerprint are independent of each other, and just having the door badge or the fingerprint is not enough to gain access. This is often called "multi-step authentication" instead of "multi-factor authentication".

---

Now imagine your scenario: You have a private key, encrypted with a strong passphrase. Are those two factors? No, because the private key can also exist without passphrase. An attacker that compromises the private key can thus log into your system, even without knowing that passphrase. In fact, the server is completely unaware if your private key is protected by a passphrase or not.

If you want true multi-factor authentication, there are SSH modules that do exactly that. That being said, a private key encrypted with a strong password is often enough.

---

Note: The original question talks about "an SSH key with a Passphrase to login on a server", which I interpreted as a private key, encrypted with a passphrase.

Answer 2

Yes

2FA requires two different factors or categories of authentication. (They must be different categories; a password and a PIN would not be considered 2FA.)

Wikipedia provides a great list of factors:

• Knowledge factors: Password, PIN, secret questions
• Possession factors:
  • Disconnected tokens (human-readable): Google Authenticator
  • Connected tokens (machine-readable): YubiKey
  • Software tokens: X.509 certificate, SSH private key
• Inherent factors:
  • Biometrics: fingerprint, voice, iris
  • Behavior: keystrokes, signature
• Location: physically secured networks

Your password is a knowledge factor; your SSH key is a possession factor.

Note that ease of duplication does not preclude an SSH key from being a possession factor. Physical keys can be copied with a camera, a printer, and a soda can; they are still a possession factor.

---

The purpose of multi-factor authentication is to leverage the advantages of multiple types of authentication, decreasing the risk of compromise.

Your password is short enough that it is never written and therefore difficult to obtain. Your SSH key is long and therefore hard to guess.

Together, they make a successful attack less likely.

---

EDIT: Several people have opined that because the key could be used unencrypted, it is no longer 2FA.

That is simply absurd.

If you can bring an unencrypted SSH key into existence without compromising two factors, and then use that information to claim that is all that is needed, why not save yourself some work and bring copies of server's files into existence?

Stating

All you need to access the server's files is an unencrypted SSH key

is no different than stating

All you need to access the server's files is a ZIP of the server's files.

But how did you get that key/ZIP? You had to compromise multiple factors. (Or there is some backdoor you are adding, like access to the server room.)

It's true that it's not a server-enforceable use of 2FA. In an organizational setting, it's often a requirement for the 2FA to be centrally enforceable. But

1. That's not the question.

2. Server-enforcement is never the final word of a security system anyway.

   1. If a door requires a physical key and keypad PIN, that door is "enforcing" 2FA as much as anyone can. But when you print the PIN on all the keys, you have a 1FA system.

   2. Likewise you can increase the factors. A password-protected laptop behind a door with a physical key is 2FA, despite the fact that there isn't a single component enforcing both factors. You could remove the laptop from the room and reduce security to 1FA, though until actually you do that, there is a 2FA system.

---

EDIT2: This answer also explains why the common practice of a separate password-protected encryption key -- which is what an SSH key is -- is two factors: the key (something you have) and the password (something you know). Someone must obtain both to produce a bare encryption key needed for data access.

Answer 3

No. Other answers are pretty close, but miss important factor.

I won't repeat in detail what other say, just summarize that for SSH key+password to be multi-factor in your case, it would have to be "something you know" + "something you possess".

What I would argue is if you need only knowledge to effectively replicate "something you have" (so nobody can tell which is original and which is copy), then it is not "something you have" but "something you know" instead.

For example, if I can't remember my password and have written it on a piece of paper, it doesn't stop being "something I know" and become "something I have". It is still just password (even if hard-to-remember), and once someone learns it, they can impersonate me any time they want without me knowing. It is the same with SSH private key. It is just data, and data is by definition "something you (could) know (and effortlessly make an exact and indistinguishable copy of)".

The main feature for something to be "something I have" is how hard it is to copy by unathorized third party, as the main feature of effective "something I have" is that the only realistic way the attacker can have it is if I don't have it anymore (as I'm bound to notice I'm missing it).

Of course, there are many many grey areas, as mentioned in some posts. CHIP bank cards would be "something I have" today, as it is not possible (without a lot of effort, people and money) to make a authentic working duplicate. However Bank card authorized only by magstripe, which any cashier can make a copy of with $25 equipment and $1 of materials is no longer effective "something I have".

Also, as technology progresses, definitions change. Once upon a time, MD4 was cryptohash. Nowadays it is most definitely NOT - it is just a hash, no better at being a cryptohash than simple Checksum.

So, "SSH private key + passphrase" actually fails at being two-factor authentication method on two fronts:

1. SSH private key is just information and not physical object, so it is by definition "something you know" and not "something you have".
2. if some authentication factor is totally ineffective at making it harder for attacker to succeed in authentication, can it still be called an authentication factor? If your server enforces 1-character-maximum password length and no limit on number of tries, is it still authentication factor? In strict theory, it might be, but in practice it is just security theater.

Note that this does not mean that ssh private key + passphrase is bad: it is much better than plain password, or unprotected private key. But it is not 2-factor.

But if you want extra security provided by two-factor authentication in ssh, you can setup 2-factor authentication in ssh, preferably in addition to having it's private key protected with passphrase.

Answer 4

From the point of view of the service: No, a passphrase protected SSH private key is not multifactor authentication.

The SSH server has no way to know whether the private key is encrypted or not, and has no way to know what that current passphrase may be in any case. The closest that the server can get is, if the key pair is generated on the server, it can capture the passphrase at that time. (This would be very unusual, and I'd question the security of any system that does this.) Once the private key has left the server, though, the only thing it can assert is that, at one point someone used the passphrase to decrypt the key. The server does not know if it was decrypted seconds ago as part of authenticating or if they private key is currently sitting on the client machine's disk completely unencrypted.

So, while it is a good practice to encrypt the private key with a passphrase, the authentication handshake between the client and server do not use that passphrase, thus the passphrase is not part of authentication.

As to whether or not the private key is something you have or something you know, I argue that it is something you have, because you are not passing the private key directly to the server, you are proving that you have the private key:

The authentication handshake goes like this:

1. The client selects a key to use and sends the key's ID to the server.
2. The server gets the public key from ~/.ssh/authorized_keys, generates a nonce, and encrypts it with that public key.
3. The client decrypts the nonce with its private key, then MD5 hashes it with the shared session as salt.
4. If the server gets the expected hash back, the user is authenticated.

This is a different process than passing a password; you are proving more than just knowledge, you are proving that you have a system capable of performing decryption on a message encrypted with a specific public key.

In physical security, something you know would be implemented with a challenge-response: The guard calls out a word, and you respond. (This also authenticates the guard. Don't give the password of the day to someone just because they're wearing a uniform.)

Similarly in physical security, something you have is a key. Yes, the key contains information that is easy to copy and could even be memorized, but unless that data is cut into a physical object, the data does no good. With a key, you are proving more than just knowledge, you are proving that you have an object capable of lifting the tumbler's pins to the correct height. And just as the passphrase on a private key is not part of the authentication, whether the tool used to turn the tumbler is the intended key, a copy, or a set of lock picks is also not part of the authentication.

Answer 5

Well, there's a couple of answers that are correct but where the subsequent arguments raging in the comments show that they are not clear enough, so I think there's still space to stress the following key point:

• Multi-factor authentication is an authentication policy where the verifier demands multiple (and ideally independent) authentication factors from the claimant.

The setting here is some sort of authentication protocol with two parties:

1. A claimant that claims a specific identity and must prove it;
2. A verifier trying to confirm the claimed identity and reject impersonators.

In SSH, the claimant is the client and the verifier is the server. In the most common configuration the server doesn't demand that the client's private key be encrypted with the password, which means it's not MFA. It's just the client's discretionary choice to encrypt their private key.

Answer 6

Given that the basic definition of multi-factor authentication leaves some room for interpretation (for example: Is an SSH key "something you have" or "something you know"?), it seems to me that the answer to this question requires a more detailed definition from an authoritative source.

I came across the Digital Identity Guidelines by the National Institute of Standards and Technology (NIST). Section 5.1.8 deals with "Multi-factor Cryptographic Software" and defines:

A multi-factor software cryptographic authenticator is a cryptographic key stored on disk or some other "soft" media that requires activation through a second factor of authentication. Authentication is accomplished by proving possession and control of the key. The authenticator output is highly dependent on the specific cryptographic protocol, but it is generally some type of signed message. The multi-factor software cryptographic authenticator is something you have, and it SHALL be activated by either something you know or something you are.

Section 5.1.8.1 makes a couple of recommendations for such software:

Multi-factor software cryptographic authenticators encapsulate one or more secret keys unique to the authenticator and accessible only through the input of an additional factor, either a memorized secret or a biometric. The key SHOULD be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, TEE). The key SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access. Multi-factor cryptographic software authenticators SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.
Each authentication operation using the authenticator SHALL require the input of both factors.
Any memorized secret used by the authenticator for activation SHALL be a randomly-chosen numeric value at least 6 decimal digits in length or other memorized secret meeting the requirements of Section 5.1.1.2 and SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on the number of consecutive authentication failures. The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on the number of consecutive authentication failures.
The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after an authentication transaction has taken place

My takeaway from this document is that, according to NIST:

1. A cryptographic key stored on disk (such as an SSH key) is "something you have".

2. A cryptographic software authenticator should follow the recommendations listed in section 5.1.8.1, such as

   • key stored in suitably secure storage with limited access
   • discourage cloning of the key onto multiple devices
   • each authentication requires input of both factors
   • rate limits on activation
   • decrypted key zeroized immediately after authentication

I believe some of the recommendations listed above are not in place when simply using a password-protected SSH key (rate limit?). That said, it certainly seems possible in principle to build a compliant multi-factor cryptographic software authenticator that uses a SSH cryptographic key and a password you know.

Answer 7

Yes, this is MFA and let me explain. The passphrase is the "something you know," The SSH key is the "something you have." You need both to log in.

If you knew the passphrase but didn't have the ssh key, you would not be able to log in because you only have one factor (something you know). If you had the encrypted SSH key but didn't know the passphrase to decrypt it, you still won't be able to log in because you only have one factor (something you have). You need both factors to log in hence MFA.

Where it gets tricky is enforcement. The server has no guarantee that the key wasn't decrypted then stolen. The attacker could log in with only a single factor in this scenario, but the original question wasn't about enforcement. The original question asked if a passphrase encrypted SSH key was MFA, and to answer that question with those specific restraints, you would have to say yes.

Answer 8

So the basic reason given by the "NO"s for not considering SSH 2FA is that you cant "enforce" a user use a passphrase - but of course if ssh users choose or follow security policy to use a passphrase then it definitely is 2FA.

Some additional points :

• if you are in a position to view the storage location of a user's private key (not the recommended way to use SSH but sometimes the only choice you give your users in larger enterprises that control desktops) then you can in fact easily check if the key is encrypted with a passphrase and enforce such encryption by just annoyingly deleting an unencrypted private key every time you find one and sending an email to the user that owns that location
• if SSH is not 2FA, then neither is a password and soft token as you can also set up such authentication to not require any user involvement (ie the something you have - eg MS Authenticator - is not something only that user has - as support staff also have access to it) and the token can therefore be recreated on another device with another something you know
• traditional 2FA with a password and token also falls down because you also CAN'T enforce that an administrator has a non-null or all space (or any other simple) password as any admin worth their salt can bypass password security controls
• you also cant "enforce" that people don't share their authentication credentials password or otherwise. In every organisation I have worked at this is just a policy.
• ssh is stronger authentication than password MFA when other users (eg support staff) do not have control over it. IT Security people often think only something they have control over is safe - but then IT Security people are among those tempted to breach internal security controls because they have easy access to all the passwords and keys.

Perhaps a nice hybrid ssh solution could be developed where encrypted private keys and public keys are stored in a security controlled ldap database (the ssh source code is available for such a modification to be made - such ssh keys could even be signed ssl certificates).

Edit: Actually the answer is possibly a lot simpler if you consider the way SSH is used to authenticate. The private key is something you have (possession factor) because - unlike a password - it is NEVER sent to the server (unless you stupidly decide to copy it there). The 2nd factor/something you know is the unique temporary challenge/nonce/token that the server generates for the current session and sends to you to allow you to prove you have the private key by calculating an appropriate response (something unique you, and only you, now know). IE there are two factors used in the actual authentication process and both have much more entropy than any password YOU could remember to send to a server or any conventional 2FA token. Conventional 2FA using a password and a generated token (supposedly by something you have) is also only ever 2FA the very first time you use it since the something you know is sent unencrypted (hopefully over an encrypted connection) to the server after which it becomes something not only you know - and you have no control over whether it is replicated elsewhere unencrypted. In the example given below where effectively each factor has a different verifier (combination lock, biometric, ssh key - and maybe a another knowledge factor of a passphrase), I would argue there are still multiple factors used for the authentication process even if there are multiple verifiers. Would you argue a single verifier with 2FA is MORE secure - especially if you are logging on to multiple servers with the same authentication credentials not knowing if one of them has spilled the proverbial beans (and don't even try to tell me you never do that) ?

Answer 9

Adding on to @MechMK1 's answer, The 'Factor' in Authentication mechanisms fall into 3 categories-

1. Something you know - Passwords, PIN
2. Something you have - Credit cards, USB drives
3. Something about you - Bio-metrics, Facial recognition

If you now want 2FA, You need to pick one from each category. Eg. Fingerprint plus Password, Credit card plus PIN etc etc. Having two factors from the same category is as good as having only one. Eg. Two passwords don't count as 2FA.

Coming back to your question, SSH Key and Passphrase also belong to 'Something you know' and hence, don't count as 2FA.

Answer 10

No. They are not different factors. An encrypted ssh key is not "something you have", since it is not an object you need to physically control (it is still much better than a plain password, though).

On the other hand, a ssh key that was stored on a usb authentication device (a Yubikey, U2F...) would qualify as a second factor.