Installing Google Authenticator for SSH, OpenConnect, OpenVPN?

Hello Community,

I am trying to get Google Authenticator to be configured with my ssh, Luci, and OpenVPN. Is this possible? I have researched the following forums and websites and it looks like it has been discussed before.

I noticed there was an ipk developed for Barrier Breaker and Chaos Calmer at one time.

and there is a supported required package:

  • libpam 1.2.0-2 The Linux-PAM Pluggable Authentication Modules.

I was going to try these how-tos with alterations to match the openwrt environment but was not sure about the packages involved vs what they use on regular linux distros:

I tried checking the OpenWrt wiki and documentation section for any new information on this task but couldn't find anything. Would it be safe to try and work with this old build on a test router? Any tips or advice would greatly be appreciated.


A humbly committed student

Unlikely -- far too many things have changed in the last several years / releases to just install the packages.

It's "a bit incongruous" to talk about security with years-old, known-insecure releases, so you should be working with 18.01 or master.

Might be some good info at

The same problems apply here, you need urgent device access most, whenever the 'internet is down' and while your router doesn't have the slightest idea what time it is (rebooted, no RTC, no battery backed RTC).


Thanks @jeff
Since there was a build for google auth at one time, how hard would it be to port it over?

Very significant changes in OpenWrt run-time architecture since Chaos Calmer. It could be straightforward, it could be a challenge. Looking at the old Makefiles and current ones would be the first steps.

(Though I concur that requiring Internet connectivity to access a device that is critical to you to have Internet connectivity is asking for trouble.)


I've been researching this topic a bit myself lately, as I too would like to get Google Authenticator working (but only for OpenVPN, not for SSH or Luci that are only accessible locally). From my reading it should only be the additional GA libpam module that is needed, I _think_OpenVPN should not need to be rebuilt to support libpam in general. I've built lots of software from source on Linux, but I've never cross compiled anything. Over the next while I'm going to try and follow the docs to create a build environment in a VM and do some experimentation. I'm sure I will have questions, so I'll be back LOL.

So maybe someone here can help with this.

I've created a Debian 9 VM, and I've successfully built a toolchain for my device, as well as an image I will never use. Now I'm trying to cross compile google-authenticator-libpam, but configure fails looking for the PAM header files. The header files do exist in

~/openwrt/build_dir/target-aarch64_cortex-a72_musl/Linux-PAM-1.3.1/libpam/include/security$ ls
pam_appl.h _pam_compat.h pam_ext.h _pam_macros.h pam_modules.h pam_modutil.h _pam_types.h

but configure obviously does not find them there. Do I need to move these somewhere else? Create symlinks? Pass it to the ./configure script?

I am a complete newbie at this cross compiling thing so be kind :slight_smile:

So I tried passing that directory to CPPFLAGS, and configure with -host=aarch64-openwrt-linux-musl and make afterward both completed without errors.

I have no idea if this is going to work, but hey, just killing time on a Sunday.....

Edit: Did not actually cross compile. Got an x86_64 binary.

Back to the drawing board LOL.

The best strategy is usually to package it up for OpenWrt properly - and then to just build it as part of the normal image build. Cross-compiling has lots of quirks and OpenWrt's buildroot takes care of a lot of things automatically you'd usually have to handle manually.


Thanks slh. That's good advice. I'm a network guy and while basic building from source on Linux is pretty familiar I'm out of my depth here. I foolishly figured if I had a cross compiler it would be easy to just build one application for my own use.

Actually, making a package looks even more intimidating, but any time I've spent is still a good learning experience regardless. I've a lot more insight into what creating this system entails now. Props to the people doing it.

I'm still picking away at this when I have some spare time. I copied the header and pam library files into the staging directory where configure could find them, and built it with them statically linked so I would hopefully not have to worry about them later. It seems to have cross compiled OK with no errors

blair@Debian1:~/google-authenticator-libpam$ file google-authenticator
google-authenticator: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped

But alas, it does not run when I move it to the OpenWRT router, giving an error;

./google-authenticator: line 1: syntax error: unexpected ")"

For all the amazing things OpenWRT can do, the lack of support for 2FA does not seem like it should be an insurmountable thing to fix. I'm now looking at trying to create a package system makefile instead. Will post my results in that attempt eventually.

Hi, I had a similar problem (for OpenSSH)... and I think I solved it.

Published the Makefile to Github:

I have implemented this for OpenSSH as follows (as an example):

  1. Save the makefile in a package folder of your choosing (see the "Hello World" example on and add this to the feeds.conf.default file;
  2. "./scripts/feeds clean"
  3. "./scripts/feeds update -a"
  4. "./scripts/feeds install openssh-server-pam"
  5. "make menuconfig" and select the packages "openssh-server-pam" in Network - SSH and "libpam-google-authenticator" in Utilities. Make sure to select the M option and not *.
  6. Save the config and run "make -j$(nproc * 1.5)"
  7. Move the packages from //src/bin/packages// to the OpenWrt router and install / force install

You will need to do all the additional configs for Openssh though, like moving Dropbear to another port and change some of the config for Openssh.
Works fine on my OpenWrt 18.06.2 on a BT HomeHub 5A (target: mips_24k)

I hope this helps for the Google Authenticator bit. I have not tested this for OpenVPN.



Do yourself a favour and try to check this now, before you deploy it into productive use - before declaring victory.

  • switch off the router (remove the power cable)
  • remove the xDSL/ WAN cable, so the router won't be able to connect to the internet (no way to query ntp)
  • power up the router and try to connect using google-authenticator

Believe me, you need administrative access most, whenever the internet access is failing and these devices don't have an rtc (even less a battery backed rtc).


That is a very good point. :persevere:

So maybe still a good option for people with an OpenVPN need.

And if implemented for OpenSSH, maybe have one of the following:

  1. Have public-key authentication enabled and this set up for your main computer; or
  2. a separate DropBear instance listening only on local lan on a separate port, like 5522.

But that all seems to defeat the initial purpose.
Appreciate the warning...

Could be useful for the following setup though?

  • OpenSSH with Google-Authenticator for login from WAN (if you need this)
  • Dropbear (without Google-Authenticator) instance bound to LAN for emergency.

I made a PR and is now in the master tree


Thank you redorbluepill and lucize!!! I'll see if I can get this working now with OpenVPN and report back in a bit.

Obviously having the correct time is critical to use these token based auth systems. I'm only interested in using them for remote access as a more flexible "something you have" than certs. In theory if there is internet to allow remote access there should be NTP as well. I would obviously not recommend using this internally when internet/NTP may not be available. Using an internal NTP server with an RTC could be a work around for that though. GA lets you choose a token code range that allows for several minutes of drift should that be necessary.

1 Like

I've got MFA working for OpenSSH with OpenWrt v19.07.06, the howto.