|
When do you want or need this? It adds a burden in term of usability,
in addition to your password you will require a device that will be
pre-configured to generate the one time passwords, if you don't have it
you won't be able to login (that's the whole point). Let's say you
activated 2FA for ssh connection on an important server, if you get
your private ssh key stolen (and without password, bouh!), the hacker
will not be able to connect to the SSH server without having access to
your TOTP generator.
# TOTP software
Here is a quick list of TOTP software
- command line: oathtool from package oath-toolkit
- GUI and multiplatform: KeepassXC
- Android: FreeOTP+, andOTP, OneTimePass etc.. (watched on F-droid)
# Setup
A package is required in order to provide the various programs
required. The package comes with a README file available at
/usr/local/share/doc/pkg-readmes/login_oath with many explanations
about how to use it. I will take lot of information from there for the
local login setup.
```shell command with a # sign indicating it should be run as root
# pkg_add login_oath
```
You will have to add a new login class, depending on what of the kind
of authentication you want. You can either provide password OR TOTP,
or set password AND TOTP (in the form of TOTP_CODE/password as the
password to type). From the README file, add what you want to use:
```file /etc/login.conf sample including comments starting with #
# totp OR password
totp:\
:auth=-totp,passwd:\
:tc=default:
# totp AND password
totppw:\
:auth=-totp-and-pwd:\
:tc=default:
```
If you have a /etc/login.conf.db file, you have to run cap_mkdb on
/etc/login.conf to update the file, most people don't need this, it
only helps a bit in regards to performance when you have many many
rules in /etc/login.conf.
# Local login
Local login means logging on a TTY or in your X session or anything
requiring your system password. You can then modify the users you want
to use TOTP by adding them to the according login class with this
command.
```shell command with a # sign indicating it should be run as root
# usermod -L totp some_user
```
In the user directory, you have to generate a key and give it the
correct permissions.
```shell command with a $ sign indicating it should be run as a regular user
$ openssl rand -hex 20 > ~/.totp-key
$ chmod 400 .totp-key
```
The .totp-key contains the secret that will be used by the TOTP
generator, but most generator will only accept it in encoded as base32.
You can use the following python3 command to convert the secret into
base32.
```shell command
python3 -c "import base64; print(base64.b32encode(bytes.fromhex('YOUR SECRET HERE')).decode('utf-8'))"
```
# SSH login
It is possible to require your users to use TOTP or a public key +
TOTP. When your refer to "password" in ssh, this will be the same
password as for login, so it can be the plain password for regular
user, the TOTP code for users in totp class, and TOTP/password for
users in totppw.
This allow fine grained tuning for login options. The password
requirement in SSH can be enabled per user or globally by modifying the
file /etc/ssh/sshd_config.
|
|
```Sample configuration including comments for /etc/ssh/sshd_config
# enable for everyone
AuthenticationMethods publickey,password
# for one user
Match User solene
AuthenticationMethods publickey,password
```
Let's say you enabled totppw class for your user and you use
"publickey,password" in the AuthenticationMethods in ssh. You will
require your ssh private key AND your password AND your TOTP generator.
Without doing any TOTP, by using this setting in SSH, you can require
users to use their key and their system password in order to login,
TOTP will only add more strength to the requirements to connect, but
also more complexity for people who may not be comfortable with such
security levels.
# Conclusion
In this text we have seen how to enable 2FA for your local login and
for login over ssh. Be careful to not lock you out of your system by
losing the 2FA generator. |