2FA Authentication for SSH in FreeBSD using FIDO Webinar

jardows

2[H]4U
Joined
Jun 10, 2015
Messages
2,308
I came across this in my email today. Klara Systems has been one of the leading support companies for FreeBSD and ZFS solutions. I am particularly interested in the implementation of 2FA on my FreeBSD systems, but I figure that even if you don't use FreeBSD, this could be very informative to get ideas for setting up 2FA on other systems as well.

You can sign up for the webinar at:
https://klarasystems.com/webinars/webinar-deploying-2fa-for-ssh-on-freebsd-with-fido/

I am not affiliated with Klara systems in any way, but am a big fan of their work and of FreeBSD in the network!
 
One item of note, in your /etc/ssh/sshd_config file if you set it to
Code:
AuthenticationMethods publickey,keyboard-interactive:pam
(note the comma) you can require both key AND 2FA.
I have my server set up to require key+2FA or password+2FA. You can even require a password, 2FA, and key if you wanted.
 
Last edited:
If you're using ssh keys and the private key is passphrase protected, you effectively have 2FA already. Just saying.

If the access to your private key (with or without passphrase) requires you to auth to get at it, again, you have satisfied 2FA. But note, access (of any kind) to a private key without passphrase allows potential compromise of a factor. Much like losing access (that is, someone else has access) to your phone if that was one of the factors in a 2FA.

Just as with backups, sometimes the backup of the backup of the backup..... is the answer for handling the last mile. So MFA becomes the "thing". I auth (1), I receive app notification to allow auth, confirmed via app (2), have to input biometric to confirm the confirm (3), etc.

However, you can create a dependency conumdrum. If biometric is ultimately required, and not working, you may lose the ability to auth at all. If your phone is required, and is lost, stolen or broken, you may not be able to establish a new phone easily, etc. Trying to work around this requires you to "prove" who you are, and if all factors of "proof" fail you, then trying to "convince" someone to reset you is arguably a security violation (it's a dependency circle). So, a weird as it is... and perhaps shameful, you might just find that good ole password/secret/pin (or secret q&a) becomes the "reliable" proof at the end of the day (so strange). Or you may find that very insecure things (like email) become source of proof. Or merely faxing a letterhead, etc.... (all of these being far weaker than a password).
 
  • Like
Reactions: Meeho
like this
However, you can create a dependency conumdrum. If biometric is ultimately required, and not working, you may lose the ability to auth at all. If your phone is required, and is lost, stolen or broken, you may not be able to establish a new phone easily, etc. Trying to work around this requires you to "prove" who you are, and if all factors of "proof" fail you, then trying to "convince" someone to reset you is arguably a security violation (it's a dependency circle). So, a weird as it is... and perhaps shameful, you might just find that good ole password/secret/pin (or secret q&a) becomes the "reliable" proof at the end of the day (so strange). Or you may find that very insecure things (like email) become source of proof. Or merely faxing a letterhead, etc.... (all of these being far weaker than a password).
This is the conundrum for smaller IT systems - SMB's and such. I work for a large university, and we have quite the separation of duties, so no one person losing their phone prevents a reset. But for a home server or a business that has 1 IT guy or simply outsources it, you have to weigh the potential lockout risk to the benefit for sure!
 
This is the conundrum for smaller IT systems - SMB's and such. I work for a large university, and we have quite the separation of duties, so no one person losing their phone prevents a reset. But for a home server or a business that has 1 IT guy or simply outsources it, you have to weigh the potential lockout risk to the benefit for sure!
Providers are playing "a game" today though. Many do not offer multiple users and some even demand the use of a unique "personal" account (not a Joe User account). I'm not saying that most companies aren't smart enough to get around all of that, just saying, providers are trying their hardest to do "bad things".
 
Back
Top