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.

  • 7
    Is it the key that is encrypted with a passphrase, or is it the remote server that requires both a key and a passphrase?
    – ig-dev
    Oct 29, 2019 at 23:13
  • If you put a sticky note with your password on it in a combination locked safe, is that 2FA?
    – mm201
    Oct 30, 2019 at 19:41
  • 1
    Great question for sparking some insightful commentary. I really expected the answer to be "Yes, it's 2FA," but I think I've been convinced otherwise. Oct 30, 2019 at 21:11
  • 2
    "use an SSH key with a Passphrase" is unclear, and as such, the answers are all over the place. @ig-dev's comment needs to be addressed, as it literally makes the difference between yes or no Oct 30, 2019 at 23:14
  • 1
    @RichieFrame, yes sorry, I confirme that the question focuses on an encrypted SSH key using a passphrase
    – Antonin M.
    Oct 31, 2019 at 8:20

10 Answers 10


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.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – schroeder
    Nov 1, 2019 at 16:02


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?


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.

  • 2
    If your passphrase is short, it's likely brute-forceable by anyone who obtains your encrypted .ssh/id_rsa file, and brute-forcing is an offline operation in this context. Oct 30, 2019 at 2:30
  • 4
    "If you can will an unencrypted SSH key into existence" -- Nobody is saying that we can magically create a valid key just by wishing for it. SSH key pairs can be created without any passphrase encryption, or after being generated, can be decrypted and saved in that unencrypted state.
    – Ghedipunk
    Oct 30, 2019 at 21:58
  • 2
    Maybe you could add that this answer is true if the server requires both a key and a password, opposed to the key itself being encrypted with a password. That seems to be where a lot of confusion is coming from
    – ig-dev
    Oct 30, 2019 at 23:59
  • 5
    @PaulDraper your addition of a "defence" is completely unnecessary. An unencrypted key has no password and is then outside the scope of the question.
    – schroeder
    Oct 31, 2019 at 13:46
  • 3
    @PaulDraper Bascially, everything under the line ...
    – schroeder
    Oct 31, 2019 at 15:20

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.

  • 2
    A yubikey is a physical object that "just" contains information, so why does it count as a 2FA and a private key doesn't? Oct 30, 2019 at 17:00
  • 4
    @ConorMancone I don't want to put words in OP's mouth, but the information contained in the Yubikey cannot be extracted. I think OP is suggesting that information that can be duplicated is always "something you know," in the same way that a physical door key is (for you) a thing that you have, but is practically speaking information encoded in ridges and troughs for any locksmith. Oct 30, 2019 at 21:00
  • 1
    @ConorMancone as Michael says, it is all about availability of that information to attacker. You (nor I, nor Joe Random Hacker) can not get to that private key information stored in yubikey in order to duplicate it. On the other hand, ssh private key stored on USB memory card is trivial for anybody to read and duplicate (just copy&paste!), so is no different than plain old password written in text file on your USB memory card (or on piece of paper) -- so not really "something you have". But if/when someone finds a exploitable bug in yubikey, it too will stop being useful 2nd factor. Oct 30, 2019 at 23:22
  • 3
    This answer does a good job of laying out why SSH key+password is not 2-factor. But an uncareful reading of it might lead someone to think there's no point to encrypting your SSH key. Using multi-factor auth and encrypting your SSH key address different types of attacks, and thus both are valuable.
    – kbolino
    Oct 31, 2019 at 20:12
  • 2
    @kbolino good point; I've updated the answer to mention that point (and link to a way to have 2-factor auth implemented in ssh) Oct 31, 2019 at 23:04

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.

  • I don't think the fact ssh is proving in challenge-response it has a private key instead of passing it directly classifies it as second factor. You can use plain password it that way too (like for example APOP or CHAP) - it's just implementation detail. Otherwise, one could claim to have 2FA with only a password: by sending half a password directly, and half via APOP/CHAP-alike protocol (implemented in javascript for example). Jun 2, 2020 at 9:01

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.


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 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 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, 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.


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.

  • The act of joining the factors on the client side negates it from being a multi factor. Just like if you need 3 people with a password part to get access, isn’t a multi factor authentication. (It’s still only the 1 thing you know factor).
    – LvB
    Feb 10, 2022 at 9:33
  • Right that’s not MFA because three people with a password is only one factor (something you know) used three times. You need two or more different factors for MFA. The passphrase protected SSH key is two different factors. The password (something you know) AND a key (something you have). Feb 10, 2022 at 15:53

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) ?

  • You appear to have misunderstood the reasons for "no". MFA is from the perspective of the verifier, not a 3rd party observer or even the user. And it has nothing to do with "enforcement". The authenticator needs to authenticate in order for a factor to be included in a MFA model. You reframed the answers then debated the reframing, which took this answer in a weird direction and I'm not sure that it answers the question as it seems more interested in debating other answers.
    – schroeder
    Jun 21, 2023 at 7:49
  • 3
    For example, if I put the ssh key in a USB stick that has a fingerprint reader to access, and place that USB stick in a physical safe with a combination lock. In this case, I need to know the combination (knowledge factor), unlock the USB with my fingerprint (biometric 2nd factor), then use the ssh key to access the ssh server (3rd possession factor). But this isn't MFA. From the verifier's perspective (the ssh server), it only verifies the key. All the other protection measures are outside scope. It only authenticates one factor. Therefore, it is 1FA
    – schroeder
    Jun 21, 2023 at 7:56
  • As this is a Q&A site, please make sure that you address and answer the question directly. As written, this is more of a critique of the other answers than a direct answer itself.
    – schroeder
    Jun 21, 2023 at 8:06

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.

  • 8
    Unless you're memorized your SSH Key (which seems very unlikely), you could argue that the key is "something you have", and the password is "something you know". As a result, why doesn't it count as 2FA given your outline? Oct 29, 2019 at 19:55
  • 8
    I agree with Conor: The SSH key is something you have. It's only because the passphrase is tied directly to that SSH key that I would argue that they're not separate factors. If the passphrase and key were unrelated, then they would be separate factors.
    – Ghedipunk
    Oct 29, 2019 at 20:00
  • 8
    That is, the passphrase protects the private key, not the authentication. I can decrypt the private key whenever I choose, and the service I'm authenticating with would be none the wiser.
    – Ghedipunk
    Oct 29, 2019 at 20:07
  • 1
    @Ghedipunk: Can you post that as an answer? That's the key piece of reasoning that justifies my intuitive sense that it's not 2FA. I was having a hard time formulating it (server doesn't independently check both things) until reading your comment. Oct 30, 2019 at 13:29
  • 1
    @MechMK1: Your phrasing didn't put it as succinctly or even as clearly (at least for me), unfortunately. That's probably why commenters on your answer (especially @R.) felt the need to rephrase and highlight key points in other words. Oct 30, 2019 at 14:32

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.

  • 2
    A private key isn't something that you know or something that you are, though. (Out of the world's population, perhaps a thousand can recite over 30 digits of pi from memory.) As for me, every private key I have is physically stored somewhere (electrons/magnetic fields arranged in some digital memory... graphite/ink on paper, etc), it isn't something I know.
    – Ghedipunk
    Oct 29, 2019 at 23:32
  • 2
    It doesn't need to be something you know by heart, Ghedipunk. It is sometimes expressed as "a knowledge you have". It doesn't matter if you have memorized it or it is stored on a hard disk or notebook. See for instance that a password will be a "knowledge you have", even if it is an extremely long password on a .txt file, it's not a "something you have". Note that the key is that you need to have possession of the object in order to use it. You do not need to have a notebook or usb drive in order to use their contents.
    – Ángel
    Oct 29, 2019 at 23:42
  • 4
    @Ángel EVERY authentication factor can be expressed as "something you know" when authenticating with a remote service. It's all converted to data for transit. (Hence I don't think your argument is much good, since it produces this degenerate "2FA can't exist online" result.)
    – Brilliand
    Oct 29, 2019 at 23:49
  • 1
    @Ángel if you have data about a physical key (a photograph), you effectively have the key. But a key is "something you have", not "something you know". Oct 29, 2019 at 23:51
  • 2
    @Brilliand, you company/bank provides you with a SecurID. The data in transit is not usable for further authentications. Thus by showing showing something that can only be a "something you have", I probe that the 2FA may exist. QED.
    – Ángel
    Oct 29, 2019 at 23:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .