2FA needed urgently

I need 2fA to work yet I find no specific instructions for Fedora Server 32, I stumbled over TecMints guide, and it works but I do not want nor need the SSH part of it .

Where is your solution?

you’re telling us that you found a guide that helps you achieve something that you don’t want… why do you even follow the guide?

And instead of telling us what you don’t want (2FA for ssh), you need to tell us what you want to achieve, urgently


There are many forms of 2FA. Just like there are many kinds of vehicles. Saying you need a vehicle doesn’t really help somone recommend a vehicle for you to buy. The same is true for 2FA.

2FA could be a fingerprint reader, a iris scanner, a usb hardware security key, a dna reader, a phone app that generates one time password or any number of other methods. I mean, it could be that your mom has to be present to enter her password also. It could be anything and for someone to answer this question they would need more info about what you are actually wanting to setup.

1 Like

ok, I get it. Mint wasn’t the answer.

I was naive enough to believe installing google-authenticator would … lo and behold… INSTALL google authenticator. @darakusyou are mixing this with Biometric methods, yes they are also a kind of 2FA, but do not run via Google Authenticator, at least never read about that…more like MFA…

I would like to expose my Fedora Server 32 publicly since it runs on Cockpit and I am thrilled by that possibility. So the 2FA solution I am asking for is to have Fedora Server ask for a code - just as google authenticator, or Microsoft Authenticator - when logging in.

Don’t think that is too much to ask for considering it has been around for a number of years… I am willing to test


This should do it it:


Thanks Tom.


ok, will test… thanks

Have you informed them people over at Cockpit, since I requested it at their Github as well…

It did not work by restarting Cockpit only.
I restarted the entire server, it did not work then either.

I checked the time, it is correct.

So I had to edit the file again and comment out the GA entry…

But it looked nice and input worked fine… :stuck_out_tongue:


No you will need to keep cockpit/github updated yourself.

I’ll spin up a VM and see if I can work out why it isn’t working.

Regards Tom.

1 Like



On going bug with Redhat based distros. I suggest in the mean time setting up 2fa on ssh, as this should cover cockpit as described here:


Thanks Tom.

1 Like

what a mess… will try out that later.
Thanks for checking

1 Like

FreeIPA can be a way…

tried the guide again after removing SELinux, but it still wont work…


setenforce 0

And now 2fa works. So as the bug report states selinux is preventing this from working.

I wouldn’t recommend disbaling selinux permanently, so with wait for the bug to be resolved or use ssh 2fa as I’ve already suggested.

Thanks Tom.

edit @SecCon

I’ve found a couple of work arounds (what can I say, stuff like this bugs me when it don’t work as expected). First is just to set selinux to permissive for just for the cockpit session:

semanage permissive -a cockpit_session_t

Its the easiest way to do it and its better than turning of selinux altogether, but I don’t really like it as cockpit doesn’t need a free rein; it just needs to able to access .google_authenticator.

A better option is local policy to allow cockpit to access .google_authenticator:


These instructions are for a different issue with selinux, but they can used to sort this out. You only need to follow steps 1 & 2, but you will need to repeat them about 4 times to create all the required polices; you can use journalctl -t setroubleshoot to get the timestamps (take note of the timestamp format on the webpage, as this is one you will need to use). Make sure to name each policy different, so for example:

ausearch -m AVC --start 04/05/2016 19:52:00 --end 04/05/2016 19:52:59 | audit2allow -a -M cockpit1


ausearch -m AVC --start 04/05/2016 19:52:00 --end 04/05/2016 19:52:59 | audit2allow -a -M cockpit2

You need to enable policies to survive a reboot:

semodule -e cockpit1

Thanks Tom.

Thanks Tom but I think I found a workaround, still testing it.

Ditched Cockpit for Webmin http://www.webmin.com/ … will check selinux after some probing

Testing GA TOTP ( I could have chosen Authy, but well…)

I can’t really say which is better, but I do know webmin has been around for since 1997 and is still modern and active, those are the solutions I like to choose.

I can verify successful implementation of Webmin and TOTP.


One think they omitted in that text (until they add it) is that you have to grant the user access to modules, selectively I guess, but Webmin Users seems a relevant module to grant when creating the account. I am guessing here, trial and error, but for the login to work, basic Webmin access is probably needed and the mentioned group above all.

1 Like

I was going to advise against using Google Authenticator since it’s a crappy proprietary implementation of an open standard, but reading Webmin’s website it seems they use “Google Authenticator” as a nickname for the usual TOTP standard and their implementation thankfully has nothing to do with Google.

I get that, you can choose Authy as well, but that would require additional signups and stuff, I am used to Microsofts and Googles authenticators so far and they are actually trusted by some commercial systems and my employer, so even if they are crappy, they can’t be that bad…

All I’m saying, there’s nothing “Google” about the Google Authenticator app, it’s merely a poor implementation of the TOTP standard (phoning home, no basic backup features etc.). There’s zero reason whatsoever why you should have it on your phone when there are more reliable, open-source programs like oathtool, AndOTP, FreeOTP… except if your employer installs the Google version on your business phone.

It’s good that Webmin apparently just uses the name “Google Authenticator” to attract the attention of the 95% of TOTP users who haven’t heard of “TOTP”.