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.

  • 5
    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 '19 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 '19 at 19:41
  • 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. – Michael - Where's Clay Shirky Oct 30 '19 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 – Richie Frame Oct 30 '19 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 '19 at 8:20

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.


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.

  • 1
    A yubikey is a physical object that "just" contains information, so why does it count as a 2FA and a private key doesn't? – Conor Mancone Oct 30 '19 at 17:00
  • 3
    @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. – Michael - Where's Clay Shirky Oct 30 '19 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. – Matija Nalis Oct 30 '19 at 23:22
  • 1
    I agree with the benefits of the "something you have" as something that can't be copied, but is that a fundamental definition for the factor? Is that what makes it a discrete factor? – schroeder Oct 31 '19 at 13:49
  • 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 '19 at 20:12


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.

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

That is simply absurd.

If you can will an unencrypted SSH key into existence and then use that information to claim that is all that is needed, why not save yourself some work and will 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 saying

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

Sure....but how did you get that?

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.

  • 1
    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. – R.. GitHub STOP HELPING ICE Oct 30 '19 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 '19 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 '19 at 23:59
  • 4
    @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 '19 at 13:46
  • 3
    @PaulDraper Bascially, everything under the line ... – schroeder Oct 31 '19 at 15:20

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.


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.


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.

  • 7
    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? – Conor Mancone Oct 29 '19 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 '19 at 20:00
  • 7
    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 '19 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. – Peter Cordes Oct 30 '19 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. – Peter Cordes Oct 30 '19 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 '19 at 23:32
  • 1
    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 '19 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 '19 at 23:49
  • @Á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". – Paul Draper Oct 29 '19 at 23:51
  • 1
    @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 '19 at 23:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.