24

For SSH authentication, which is more secure?
2 Factor Authentication using a USB token/Google Authenticator(time based)
OR
Public/private key with password

Or could they be both used at the same time? If it is possible, are there any downsides in using a multi-factor authentication like this?

Also, could anyone post an example or a link to show how I could implement both public key and 2 Factor together if it's possible. Thankyou!

25

This is not a "one is better than the other" issue. Both increase the burden of an attacker to break into your system:

  • Using (and enforcing) keys increases the "quality of the password" ("mypassword123" vs "long_binary_asymetric_keypair_here"). Humans are very bad at remembering long passphrases with good entropy.

  • Using 2Factor auth ensures that an attacker would have to get 2 properties under control: one password-mechanism (usual passwords, PK) and another one which is (usually) not at the same physical location as the first one. With 2Factor mode the system you are trying to authenticate against will challenge you a second time after you succeeded at the first challenge. But if both challenges are silly / simple / easy to break the whole 2Factor thingy is pointless.

So, both mechanisms supplement each other.

Good tutorial on the 2Factor part:

http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/

Combine that with any other tutorial which explains how to use ssh-keys (and there are LOTS in the internets). The flow of the authentication is then as follows:

  1. Client triggers mechanism to unlock the private ssh-key (password) on his machine
  2. Client contacts Server to ensure public and private key match. From here on the ssh-server is basically not involved in the authentification any more.
  3. Server routes Client to the second challenge
  4. Client responds to the second challenge correctly
  5. Client gets access to the shell on the Server
  • Thanks for writing the flow of authentication. It helps a lot in understanding the process. Coincidentally, I've used that guide to set up Google Auth on a lightweight linux server. – Lelouch Lamperouge Dec 19 '12 at 7:41
  • 1
    I manage to set up private-key auth, and 2 Factor. The problem is that I can only use either one of them. What option do I use in order to check for the PrivateKey first, then prompt user for Google Auth? – Lelouch Lamperouge Dec 23 '12 at 14:55
  • I did some research into this a little while ago. Unfortunately, OpenSSH doesn't as of yet support the ability to use both, except in a patch for the version distributed with RedHat Enterprise Linux. Your only real options at this point are to use RHEL, or forego package management and build from source, forward-porting the patch. – Stephen Touset Jan 7 '13 at 18:13
  • @LelouchLamperouge OpenSSH supports using both methods since version 6.3 – Amir Ali Akbari May 1 '14 at 10:23
5

In addition to the other answer, I can also add that pubkey-based authentication can be 2-factor in itself if your private key is on a smartcard (e.g. OpenPGP card). In my experience, adding google-authenticator at the ssh level makes admin's life too cumbersome -- you have to enter the code each time you need to scp things around. My preferred approach is ssh key on OpenPGP card and google-authenticator when doing sudo.

These two links will be of use to you:

  1. Setting up OpenPGP card to handle your ssh authentication.
  2. Setting up centralized google-authenticator infrastructure.
  • ...but using a socket with ControlMaster you will only have to enter once at the beginning of your session (with a given host). – bryn Jul 31 '16 at 0:04
-1

The trade off between how much hassle it is to maintain a two-factor or Public Key authentication and the degree of security each provides depends on how/who is using it. If the usage is among a limited number of server system managers who are familiar with security so that they won't pollute either process by allowing access to their access (PC, laptop, mobile device) to be compromised, then either of these may prove secure.

The various reports, articles and blogs I have read indicate that the most often means of defeating either two-factor authentication or public key encryption is gaining access to insecure client access - a PC left on or without password protection that is used to gain root access (or other areas). Passwords may be stored on the device in a password manager or are automatically put in by a web browser or jotted down on paper in a desk.

Another means of compromise is when passwords and keys are not changed after an employee/associate leaves.

Most brute force, distributed brute force attacks and other outside attacks are effectively thwarted by either two-factor or Public key authentication methods. That is improved if reasonably tough passwords are used and password encrypted public key access is required (a form of two-factor authentication itself).

Other methods may be used, such as using a non-standard SSH port, although there is valid argument against that method. Another method is use of rotating/random non-standard ports or use of Port-knocking in which three or more ports must be sequentially hit/knocked before access is granted to a selected SSH or other ports. The port-knock ports may also be rotated periodically.

The latter methods are not usually justified because it is far more likely that security breaches will occur from within an organization that has implemented two-factor or/and public key authentication methods. If the nature of the work/servers requires the highest levels of security, the additional layers of security may make sense.

I re-watched the movie "The Imitation Game" 2014 last night. It is about the cracking of the Nazi Enigma encryption machine that required determining among some hundreds of millions of possible manual selections. The code was broken by Brit Alen Turing's electromechanical computing machine only after they came upon repeated terms in communications that could be guessed "Heil Hitler!" and other terms in daily weather reports. That goes a long way to describe the security of Linux servers and other secured systems - they are only as secure as the practices of people who use them.

  • I'm not sure you actually answered the question – schroeder Sep 7 '17 at 19:38

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.