Setup 2FA on an SSH Server with Recovery in Mind

When you’ve enabled time based 2FA authentication on a remote ssh server, have you ever wondered what you might do if you lost your phone? What about if your server lost track of time? What could you do to recover the server? 

There is only one answer, from the start we need to have recovery in mind, should we lose access to our phone or our server lose track of time, we need a route by which we can take back control. While there are multiple ways to ensure there is always an alternative route into the server, we will go over only a couple here: 

• Leave one SSH user without 2FA enforced
• Keep a secure copy of the 2FA Secret Key for Recovery Purposes

Let’s dive into these recovery methods further. If we leave one user without time based 2FA enforced we can always log back into our server via this user. This is useful in larger organizations where there may be multiple users that need access to a server, a sysadmin could keep one user account without 2FA enabled, and enable 2FA on the other accounts, this ensures that should the server lose track of time or an employee get locked out, that the sysadmin can always reset and fix the problem. However the utility of this method for smaller organizations where at best you have 1 -3 or so users for a server becomes less clear, if you have only a couple users that need access, is it even worth bothering with 2FA? There definitely becomes less of a security enhancement, and in the end the sysadmin may decide it’s not worth the time and effort. (I always recommend utilizing SSH keys for remote access, whether or not 2FA is utilized). 

Regarding keeping a secure copy of the 2FA secret key, this may be a better alt to leaving one account unprotected. The only danger to this is if the key is not stored securely, in which case it could be leaked, although a leaked key is no worse than no key. 😉 Seriously though, this ensures that should you lose your phone, that you could install a 2FA app on another and just re-enter the secret key. The waters are not so shallow though when the server loses track of time, in this case theoretically you could discover the server’s current time via ntpdate and then set a phone to that exact date and time and use the secret key to generate the correct token, albeit I have never tried this in reality. 

Well that’s a wrap, I recommend implementing one of the above recovery methods on your remote ssh server if you intend to or have already enabled time based 2FA authentication to further protect user accounts on a remote SSH server. Stay safe out there!