I'm trying to figure out the best practices for accessing my dev box from a public terminal.

Most sources I've found recommend protecting the box with some kind of two factor authentication, such as adding a command= prefix to the authorized_keys that forces entering some sort of one-time-password.

My question is, why is this necessary? Say I've got a pass-phrase encrypted SSH key sitting on the thumb drive. I insert the drive, enter my paraphrase and connect: in order to get into my system you've got to have the key file and the pass-phrase.

Say there's a keylogger on the public box. Now an intruder has my passphrase, but my key was never copied to the local system.

Of course once my USB drive is connected, it's possible for the key to be copied off, but is this really likely? How many keyloggers also slurp SSH keys off USB drives? How many malicious-types are watching their honeypots 24/7 waiting for activity that looks like an SSH connection?

To me it seems like a pass-phrase encrypted key is two factor. Can someone explain how it isn't?

  • "Most sources I've found recommend [...]" - got a citation? Are you sure those sources are good sources of information on this? I don't think you're getting good advice.
    – D.W.
    Commented Aug 21, 2012 at 19:20
  • Well, I'm more specifically referring to the best option for my situation. You're correct it's more complex than that, I would recommend this thread for a discussion on the strongest configuration. Commented Aug 21, 2012 at 19:33
  • 1
    The strongest configuration is one that has the hard disk wiped, is turned off, encased in cement, buried 100 feet deep, guarded by Marines 24 hours a day, on an isolated island in the middle of nowhere -- usually strongest isn't what we want. :-)
    – D.W.
    Commented Aug 21, 2012 at 19:37
  • 1
    How is "something you have" typically defined for two-factor authentication? (link to Security.SE answer from another question).
    – Jeff Ferland
    Commented Aug 22, 2012 at 3:28
  • 1
    A decade later, you can create an SSH key on a FIDO2 hardware security token. The secret data on the hardware can't be copied. You can either keep the private key on the machine you minted it on, or move it to the hardware token and set a PIN on the device. Commented May 17 at 15:02

5 Answers 5


A passphrase-encrypted key provides two-factor authentication, but only if used correctly. It is easy for the user to misuse the key, providing only a single factor, and the server cannot detect incorrect usage. Hence a passphrase-encrypted key cannot be considered two-factor without additional assumptions. From the point of view of the system as a whole, the passphrase-encrypted key provides two factors, but from the point of view of the server, there is only one factor, which is the private key.

The password is what-you-know. However, the password is not visible to the server. The server does not know if you used a weak password or no password at all. In any case, typing a password on a machine which may be running a keylogger is not valid use of a password for authentication.

The key file is what-you-have, but only if you do not copy it willy-nilly. Strictly speaking, it's the USB stick where the key file is stored that is a something-you-have authentication factor. The key file itself stops being an authentication factor once you allow for it to be copied off the stick.

In the scenario that you describe, where you copy the key on a machine that you do not control, is not valid usage. It transforms what you have into what the attacker also has. If the attacker can install a keylogger on that machine, he can also install a program that makes an copy of the content of every removable media that's inserted into it. What you have must be tied to an actual physical object that is not accessible to the attacker. A key stored on your own laptop or smartphone is fine. A smartcard inserted into a smartcard slot is fine (for normal smartcard usage, where the secrets do not leave the card). A USB stick inserted into a public machine does not provide an authentication factor.

And yes, there is off-the-shelf malware that grabs the content of removable media. Depending on where you plug in, it may be more or less common than keyloggers (though I'd expect the two to often go together). The attacker who installs a removable disk imager may be after authentication data, or possibly after other confidential documents. There is a resale market for corporate secrets (confidential documents, contact lists, etc.) which fosters this kind of malware, and grabbing authentication data is an easy side benefit.

With a user who may insert his USB stick into a public machine and type his password there, the passphrase-encrypted key provides zero authentication factor.


The General Assumption of Security(*) is:

The attacker is smarter than you, he has a bigger computer, he knows your own software better than you, and he is after you, specifically.

So one has to assume that the keylogger will also monitor SSH session and slurp keys from thumb drives. Or, more appropriately, you cannot know how much secure you are if the root of the security is a statement like "the attacker will never think of that", because such statements are inherently unquantifiable.

The extra security provided by the one-time password lies, precisely, in the one-time attribute. Note that security relies here on the idea that the attacker may slurp and spy all of your data but will not turn that into an active attack right on the spot (i.e. hijacking the one SSH connection that you are doing, as opposed to merely grab enough data to reconnect later on). A true follower of the GAS would refuse to use a public system, period.

(*) Don't search for it under that name, I have just made it up. The general concept of paranoia, however, is the baseline for security.

  • 2
    Great assumption. +1 just for that.
    – user10211
    Commented Aug 22, 2012 at 1:06
  • 2
    +1 for "inherently unquantifiable" (and also for making up acronyms)
    – curiousguy
    Commented Aug 22, 2012 at 1:07

Say there's a keylogger on the public box. Now an intruder has my passphrase, but my key was never copied to the local system.

If you assume an attacker has compromised a system to install a key logger, you must also assume they could do anything else on the system. Keyfiles are still considered "knowledge factors" like passwords, because they can be copied infinitely.

To be multi-factor, authentication mechanisms must use factors from two different categories:

  • Knowledge factors - passwords, keyfiles, other secret data or information
  • Possession factors - physical tokens, smart cards
  • Inherence factors - biometrics

The first question you asked is: what are the best practices? The best practices are, log in via SSH using private-key authentication. Put a passphrase on your private key. Don't copy it to machines you don't trust. Configure the SSHD on your server to only allow login via private-key authentication (not via password authentication). You're good. You don't need anything fancier.

The second question you asked is: is an encrypted passphrase with private-key authentication two-factor authentication? Well, others have answered that question well. The only thing I would add is: I would caution you about ascribing magical properties to two-factor authentication. There's nothing magical about two-factor authentication that makes two-factor authentication guaranteed to be secure and one-factor authentication guaranteed to be insecure. So, asking whether something counts as two-factor authentication is probably not the right question to ask. The right question is, is my approach secure enough for my requirements? (You could also ask: why is two-factor authentication generally considered more secure, what problems does it solve, and do those apply to my particular situation?)

The answer to these questions is: in most cases, SSH private-key authentication with a passphrase-encrypted private key is good enough. Whether it counts as two-factor or one-factor is in some sense irrelevant.

  • I never thought I would get so many perspectives on this question! Every answer is correct in its own way and answers a different part of the question. Perhaps you're correct that the more meta answer to the question is a perceptual one. Commented Aug 21, 2012 at 19:51

There's some terminological confusion here I think and it's common.

Most strong multi-factor systems are considered strong because they require more than one kind of proof of identity (factor) whereas the passphrase and key in your example can both be categorized as "something you know" and are the same kind.

Common multi-factor systems use something you know (passphrase or PIN) and something you have (keyfob or device) and there are other categories used such 'something you are' (used in biometrics) and 'somewhere you are' (geo-location) in even more complex systems.

A bank may require a username/password and a PIN for online access but this is not usually considered two factor in terms of attack resistance.

Ref: https://en.wikipedia.org/wiki/Two-factor_authentication#Regulatory_definition

  • +1 for two things you know not being multi-factor. They have to be distinct types of information, e.g. something you know, something you have, something you are.
    – Polynomial
    Commented Aug 21, 2012 at 15:58
  • 1
    The key is not something you know: the user doesn't memorize it, it is stored on a device. The device that it is stored on is something you have; here it is used incorrectly. Commented Aug 21, 2012 at 17:08
  • Is this hair-splitting? The knowledge of the long number that is the key is how you assert your identity, but where it is stored is not as important. Devices that function well for "something you have" use crypto, interaction, or both to make a mathematical assertion that the device is unique and in your possession at that time. That's completely different, no?
    – adric
    Commented Aug 21, 2012 at 17:25

You must log in to answer this question.

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