DietPi-Config | Add support for 2FA SSH with Google Authenticator PAM module (TOTP/HOTP)

[GvY85]

For some reason I never liked/understood logging in with public SSH keys and the distribution of those among client devices.
So I have always been logging in with a (root) password on my 2 DietPi servers but that never felt safe enough.
Recently I found out you can use a password + 2FA (TOTP) via the Google Authenticator package and thus use your phone with any app that supports TOTP (Yubikey, Google Authenticator, Authy, etc).
You can also use public key authentication + 2FA but I have not tried that out.

Steps for using a password + 2FA with DietPi:

1: dietpi_software -> choose OpenSSH as SSH Server
2: sudo apt install libpam-google-authenticator
3: add auth required pam_google_authenticator.so to /etc/pam.d/sshd
4: sudo systemctl restart sshd.service
5: edit /etc/ssh/sshd_config and change/add ChallengeResponseAuthentication yes and (optinally) add a # in front of Subsystem sftp /usr/lib/openssh/sftp-server to disable SFTP if you where using Dropbear before and did not have SFTP.
6: run google-authenticator and answer these questions:
To the question if you want to use time-base authentication: y
7: Scan the QR code and back up the code/recovery code.

Do you want me to update your "/home/exampleuser/.google_authenticator" file (y/n) -> y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n)

-> y

By default, tokens are good for 30 seconds. In order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with
poor time synchronization, you can increase the window from its default
size of +-1min (window size of 3) to about +-4min (window size of
17 acceptable tokens).
Do you want to do so (y/n)

-> n

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n)

-> y

8: reboot and you should be good to go.

[GvY85]

I am a total noob in scripting this or I would have made a proposal for it.

[Joulinar]

probably better to add this to our online docs to describe how to activate 2FA and how to use SSH key authentication.

[MichaIng]

Since there are a lot of such 2FA authentication methods, which can be invoked into PAM, it is hard to cover this as an option within our scripts. Some hints in our docs sound more reasonable to me as well.

Moreover, key authentication is pretty simple and very strong in terms of security, unless you keep your private key unsafe, of course, which can be encrypted with another passphrase if not stored on a sufficiently secured client. Another benefit is to not rely on 3rd party services, especially not from data collector companies like Google, being a major privacy benefit. What are your particular concerns/issues with key authentication @GvY85?

[GvY85]

Thanks for the replies.
It feels simpler to have a strong password to use to login that you can store in a password manager and thus easily carry around with you.
However since a password alone is not considered safe I would like to use something like SMS verification (theoretically also not so safe) or, like in this case, TOTP/HOTP.
This is widely used as a method for 2FA and is generally seen as very safe when combined with a strong password (something you know and something you own).

The fact that the PAM module is called "Google Authenticator" is because it is a piece of open software developed by Google that implements TOTP/HOTP. You can use any authenticator app on your mobile phone or pc with it that supports these protocols (Authy, Microsoft Authenticator, Yubico Authenticator, etc) and it has nothing to do with Google at all. other than Google engineers working on it
It does not need to be online nor des it send something to Google.

[MichaIng]

Okay, thanks for the info. I think it is about personal workflows whether key authentication is feasible or not. I personally connect only with a single machine to my SSH servers and would put the key onto another, phone or whatever, if required. But if one works with many clients, or on not trustworthy client systems, remotely etc, 2FA may be a better choice. If the Google authenticator module is the only one, we may add it. In theory it works for other system logins as well, since it's PAM. Dropbear has very limited PAM support, but who knows.

[GvY85]

Exactly, think we are in sync on this.
Unfortinately it does not work with Dropbear due to the limited PAM support so I switched to OpenSSH and disabled SFTP to make it as minimal as possible. Not that resources are that much of a problem nowadays but it would have been nice for it to work with Dropbear

[piyushaswani55]

Hi @GvY85
I am on dietpi bookworm and I followed the above steps but still unable to enable 2fa for my ssh logins.
I am able to login without any verification code prompt.

Also, for context, libpam-google-authenticator wasn't available for debian bookworm so I added bullseye sources to install the package. But I doubt that could be the reason for it.

Do you think I could be missing something?

[piyushaswani55]

@MichaIng I too would like to request for this feature.
DietPi is really good and it would make it even better if we could add these additional pieces to harden the security out of the box.

[piyushaswani55]

Found the reason why it didn't work in debian bookworm
Instead of ChallengeResponseAuthentication it's KbdInteractiveAuthentication in /etc/ssh/sshd_config.

Also, refer below guide in case you are using shellinthebox.
shellinabox/shellinabox#187

@MichaIng would really appreciate if this too can be added as part of setup process somewhere. 2FA definitely improves security for SSH. I hope you consider it.

[GvY85]

I missed your earlier comments. I migrated from Bullseye with the 'old' settings and those work as well.
Also libpam-google-authenticator is now available in Bookworm.

# cat /etc/ssh/sshd_config
#       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
#Subsystem      sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

[MichaIng]

However, still makes sense to update this setting:

• Bullseye: https://manpages.debian.org/bookworm/openssh-server/sshd_config.5.en.html#KbdInteractiveAuthentication~2
• Bookworm: https://manpages.debian.org/testing/openssh-server/sshd_config.5.en.html#KbdInteractiveAuthentication~2