2

I'm currently trying to enforce regular users on a Linux SSH server to use 2FA (password + TOTP) while allowing power users to only use SSH keys for authentication. SSH keys are sufficiently secure for my purposes, but many of the users will initially be unable to cope with the use of SSH keys. For them, it should be ok to use a password, but in combination with a TOTP like google-authenticator.

I found good tutorials for setting up 2FA like https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-20-04 and similar questions like Use Public Key or Password and PAM verification code but no answer with regard to how to configure sshd to allow public key as single factor and (password + TOTP) as 2FA at the same time. Any hints are welcome. Thank you.

2
  • 2
    There are google-authenticator PAM modules for this purpose and I think this is what you want. Feb 19, 2022 at 19:42
  • 1
    You may get better results asking this on ServerFault or Superuser or some such community; while it's a question about using a security feature, it is not a question about security itself. Now, if you wanted somebody to explain the security implications of such a setup, this would be the right place for that...
    – CBHacking
    Jun 14, 2023 at 1:03

1 Answer 1

0

Using password authentication in combination with TOTP should not be used because both are sent in plain text (see RFC-4252) to the server and can be intercepted by a man in the middle SSH server. This setup only increases security, if the password gets compromised/stolen.

Most TOTP tokens are valid for 30 seconds, which is a really long time, if a man in the middle attacker has intercepted the token. The password and the token can be used to login to other ssh servers, if you are using the same setup and users.

When using only ssh keys to login to the server, you must provide a way to deploy the public key. Instead of generating a TOTP token for the user, you can save the users public key. For example github allows to add a public key in their web interface.

The most important security feature is the ssh fingerprint!

Your users MUST verify the fingerprint. If the fingerprint is not verified, the user does not know if the remote server is a man in the middle server or not.

If you want to increase security, you should provide the SSH servers fingerprints over a trusted source:

  • SSH fingerprint an a website secured with HTTPS and a valid certificate (e.g. LetsEncrypt)
  • SSHFTP DNS records secured with DNSSEC
2
  • 2
    "sent in plain text" is completely wrong. The password and TOTP are in plain text within the authentication packet but the packet itself is encrypted before sending using a symmetric key exchanged during the initial client-server connection handshake. Please read the introduction of the RFC you linked, in particular the instruction to read the other SSH RFCs, and the sentence "This protocol assumes that the underlying protocols provide integrity and confidentiality protection." SSH as used in the real world would be catastrophically insecure if credentials were actually sent in plain text.
    – CBHacking
    Jun 14, 2023 at 0:59
  • I have used the term "sent in plaintext" because the mentioned RFC defines the password as following: "plaintext password in ISO-10646 UTF-8 encoding". You are right, I have forgotten to mention, that the ssh session is encrypted and sniffing on the network layer does not leak the password. Aug 18, 2023 at 17:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .