I'm curious which would be more secure, pub key authentication or 2-factor auth via Google Authenticator. Apparently I can't use both. If I have pub key authentication, the Google Auth PAM module doesn't ask me for a verification code. But if someone tries to log in with a regular password, it does. So it seems it's either-or.


Public key pair. As you have more control over exactly security you want, how you use it and how you store it.

That said, security doesn't exist if it isn't used or usable. The Google Authenticator has added quick, strong security to use cases that previously had none. The hassle of handling and distributing your key pairs may very well end up with you not using them and just reverting to one-factor vanilla passwords.


It depends, what are you more concerned about? Someone being able to steal your private key, or someone stealing your TOTP seeds? That'll determine which is more likely to be compromised.

Alternatively, if your version of SSHD is new enough, you can use the AuthenticationMethods option in sshd_config to require both, with something like publickey,keyboard-interactive:pam. This will require both a functional pubkey and the full PAM stack.

An attacker who passively observes traffic should not be able to learn anything about TOTP traffic, as its encapsulated in the SSH connection, and the SSH public key is computationally infeasible to factor for modern key lengths (ECDSA, or RSA >= 2048).

  • Nope, running sshd 6.0. And I suppose that's my question: which is easier to be compromised, a private key or TOTP seeds? – CaptSaltyJack Oct 24 '14 at 2:22
  • I guess the question is, then, for someone sniffing packets, which is harder to crack: ssh pub key auth, or TOTP? Because my private key is definitely secure on my phone and desktop computer. – CaptSaltyJack Oct 27 '14 at 18:22

In most scenarios Google Authenticator is more secure.

The two techniques have slightly different risk profiles, and it depends how your phone and laptop are configured. Lets assume you're following security best practice:

  • Both laptop and phone are encrypted with a strong password.
  • The devices have all security updates, the laptop has firewall and anti-virus, and the phone isn't jailbroken.
  • When you login you always verify the public key of the server.

If you do follow all this, your greatest risk is malware on the laptop. Despite following best practice, malware often still can infect laptops. Malware on smart phones is possible, but less common, so your phone is safer than your laptop. And that's why Google Authenticator is the more secure option.

Public key authentication has some advantages. For example, if you inadvertently connect to a malicious server, that server cannot impersonate you. However, with Google Authenticator, they get your code, and have up to 30 seconds to login to the real server. But if you always verify the server's public key, this doesn't matter.

  • What exactly do you mean by "verify the public key of the server"? – CaptSaltyJack Oct 27 '14 at 18:10
  • @CaptSaltyJack - when you connect to the server, you verify that the public key is correct. Most SSH clients do this automatically on second connections, but you must do it manually the first time. – paj28 Oct 27 '14 at 18:22
  • I never knew about this. How exactly do I verify it? I ssh into my-server, and then..? – CaptSaltyJack Oct 27 '14 at 18:23
  • @CaptSaltyJack - this is basic ssh usage. You will find instructions online – paj28 Oct 27 '14 at 18:24
  • 1
    @CaptSaltyJack - similar, I'm talking about verifying the server's key. Google for "verify server ssh key" gives this – paj28 Oct 27 '14 at 18:30

It largely depends on the environment and the users you're operating with.

A large IT organisation where end users can't be expected to take adequate precautions with a private key? Probably best to use Google Authenticator and passwords.

Just you and your personal server, where the private key never leaves the box it was generated on, has a strong password on the key, and you're confident in your ability to keep that box secure, patched, etc.? Public key authentication (ensuring that you turn off password authentication) is may be better in that case.

You'll need to assess the situation, environment and your users to make an informed decision about what's going to work for you or for your organisation.


What a great question to show the weakness of shared secrets.

If you have less than a handful of servers, the google authenticator pam module will be fine. However, since it is based on shared secrets, each server should have it's secret and thus a listing on the token. If you use the same secret across servers, you risk catastrophic failure across all the servers.

Both suffer from operational security concerns - how will you disable users and manage keys? Also, if you plan on providing two-factor auth for other services, such as a VPN, neither of these is likely to work, so you will end up having multiple two-factor solutions. Here's a post I did on issues an enterprise might have with google auth for ssh: https://www.wikidsystems.com/WiKIDBlog/5-issues-enterprises-should-consider-before-using-google-authenticator-for-ssh

  • You should disclose that you are the CEO of a company offering a competing 2FA solution in this post, not in your profile. Downvoted. – Deer Hunter Feb 7 '16 at 19:08
  • I have done that sometimes, but not every time. Fair enough, but my arguments apply for any 2FA solution vs google auth, which the google auth pam creators are not suitable for wide-scale deployment. – nowen Feb 10 '16 at 22:59

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.