New Package Request: google-authenticator-libpam

[tymonx]

Project: google-authenticator-libpam

Fedora Magazine article: Set up two-factor authentication for SSH on Fedora

Please try to answer the following questions about the package you are requesting:

1. What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc)

No additional dependencies. It is a pure C source code that is normally compiling using any existing C compiler with PAM headers. It uses the same dependencies like any other existing PAM modules. All required dynamic libraries are already present in the Fedora CoreOS:

• linux-vdso.so.1
• libpam.so.0
• libdl.so.2
• libc.so.6
• libaudit.so.1
• libeconf.so.0
• libm.so.6
• /lib64/ld-linux-x86-64.so.2
• libcap-ng.so.0

2. What is the size of the package and its dependencies?

For the x86_64 architecture without any fancy build options around 129kB.

3. What problem are you trying to solve with this package? Or what functionality does the package provide?

Two-factor authorization for remote SSH access. This will greatly improve security for deployment OS.

4. Can the software provided by the package be run from a container? Explain why or why not.

No. It is strictly configured using PAM configuration files configured by system administrator (or using Butane/Ignition).

5. Can the tool(s) provided by the package be helpful in debugging container runtime issues?

No.

6. Can the tool(s) provided by the package be helpful in debugging networking issues?

No.

7. Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not.

Yes. It is quite easy to compile and install under /usr/lib64/security location.

8. In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries?

Yes. It requires only compiled pam_*.so library and install under /usr/lib64/security location.

9. Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS? (e.g. can it be abused as a Turing complete interpreter?)

I don't believe so.

10. Does the software provided by the package have a history of CVEs?

Yes like CVE-2012-6140.

[travier]

7. Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not.

Yes. It is quite easy to compile and install under /usr/lib64/security location.

To clarify here, this question is about layering the package via rpm-ostree install, either on first boot or post installation. There is a package in Fedora so this is a Yes.

But as far as I understand this requires manual / coordinated setup for it to be usable thus you will not be able to configure it directly via Ignition. This makes it less interesting for inclusion in the base image as this requires manual attention anyway.

[tymonx]

I think the best solution would be to include some kind of pam_otp.so library (pam_google_authenticator.so) with the Fedora CoreOS base image.

This will allow to have two-factor authentication out-of-box. This is important in deployment environments with limited access to internet or any kind of external network but remote SSH access is still required for management and maintenance. And configure it with Butane/Ignition by simple changing the /etc/ssh/sshd_config configuration file and the /etc/pam.d/sshd content.

It will be also possible to extend current Butane/Ignition specification with the otp field:

passwd:
    users:
        - name: core
          otp: true # Enable two-factor authentication OTP (One-Time Password)
          ssh_authorized_keys:
              - <key>

This may be a nice security feature for the Fedora CoreOS project.

[travier]

To setup OTP, you need a shared secret between the client and server. Thus this will at least need another field to store this secret.

[lucab]

Perhaps a bit of a subjective opinion, but overall I don't think we want to push *COS user towards more customized/heavyweight SSH usage. To the contrary, we'd like to keep host-wide privileged SSH access to the minimum required for disaster discovery (and be happy if you can get rid of SSH service at all). If a user ends up in a situation where they need both interactive shell access and heavily-customized authN/authZ mechanisms, maybe they should consider some dedicated solutions like https://goteleport.com/.

[tymonx]

@travier Yes, I'm aware of that. For now this can be handled with Butane storage.files.

@lucab Maybe to illustrate my request I will describe from my experience how most of my deployments looks:

• all deployments are 100% remote on machines and infrastructure manage by external customer
• network policy is very strict, no internet access, isolated, you cannot provide any additional services. Mostly of time allowing only remote IPMI or SSH access (through VPN) by IT even with harsh negotiation which ports/protocols to open
• because of that strict environment SSH (or SSH over IPMI SOL) is using for loading/updating images docker --host ssh://<ip> load to remote machines or updating Docker Swarm stack. Unfortunately it is not only used for disaster discovery :/ SSH is the easiest way to convince IT department why at least it is required

And I was thinking how to secure this more when someone expose/loose his SSH private key. Key rotation and revocation can be hard because it requires constant access to network and some customers automatically revoke accesses over time. TOTP works offline.

[dustymabe]

We discussed this in the community meeting today.

12:10:05   dustymabe | #agreed We will not add google-authenticator-libpam for now.
                     | Overlaying the package on first-boot is the currently
                     | recommended approach. It should be investigated if SSSD would be
                     | able to perform 2FA.

That being said there were some other points of discussion during the meeting that are worth bringing up:

• It was suggested during the meeting that SSSD, which we already ship, may be able to handle this use case already.
• Can anyone show us how you would provision multiple nodes using Ignition and take advantage of this PAM module?
  • i.e. getting the shared secret onto the nodes and configuring PAM to use the module.
  • also would you be using the same shared key across all N nodes, or a different key per node?

[tymonx]

if I'm not mistaken it requires some external centralized provider like FreeIPA, LDAP or Kerberos? I have looked into sssd code and I saw only OTP abstraction to these providers but any kind of OTP implementation. Other sssd services like files, simple, sudo don't provide any kind of OTP support. But I'm not expert in sssd. Still I don't have any possibility to setup full realm domain.

How about pre-installing /usr/lib64/security/pam_oath.so from the existing pam_oath package? And how to resolve chicken-egg problem for SSH+OTP without OTP after OS installation? Without external internet access to install it with the ostree-rpm? Go with CoreOS Assembler and custom image?

[dustymabe]

On the first question:

• It was suggested during the meeting that SSSD, which we already ship, may be able to handle this use case already.

I talked to a few experts on this:

@sgallagher: I know that SSSD supports two-factor authentication when used with FreeIPA (which supports both TOTP and HOTP authenticators). I don't know if there's a general implementation, though. CCing Sumit Bose to comment.

@sumit-bose I'm sorry there is no general OTP implementation in SSSD.

@tymonx - you are right.

[dustymabe]

On the second question:

• Can anyone show us how you would provision multiple nodes using Ignition and take advantage of this PAM module?
  • i.e. getting the shared secret onto the nodes and configuring PAM to use the module.
  • also would you be using the same shared key across all N nodes, or a different key per node?

@tymonx if I gave you a dev build with this package included could you show us exactly how you would use it? i.e. what Ignition config you would use to deploy everything with no manual interaction?

[tymonx]

@dustymabe I do something like this:

1. Prepare Butane configuration config.yml with included SSH public keys, included Docker Swarm Compose stack YAML files, enable Docker service, custom systemd services for creating Docker Swarm cluster and auto-joining nodes in Docker Swarm cluster and starting Docker Swarm stacks. Everything is automated including machine awareness and discovery in included custom systemd services
2. Generate Ignition configuration config.ign
3. Prepare Butane for Fedora CoreOS ISO iso.yml that contains custom auto-install systemd service with coreos-installer install --ignition-file /home/core/config.ign <auto-disk-detection>. Include generated Ignition from 2. config.ign
4. Generate Ignition iso.ign for ISO
5. Embed generated iso.ign using coreos-installer iso ignition embed --ignition-file iso.ign <fedora-coreos>.iso
6. Install the same ISO with embedded Ignition iso.ign for N remote machines. It depends on platform and BMC. For example I may use racadm for Dell, Remote Virtual Media or Redfish API
7. Everything is automatic including CoreOS installation on disk, Ignition configuration, Docker Swarm cluster creation, machine joining to cluster and starting stacks
8. The missing part are Docker images. Even if Docker Swarm stacks are started, Docker Swarm will wait for missing images
9. Use SSH MasterControl to create single connection and provide required password and/or TOTP pin
10. Configure ~/.ssh/config to attach <ip|hostname> connection to MasterControl connection
11. Upload Docker images from local host to remote machines using SSH docker --host ssh://core@<ip|hostname> load <images>
12. If I need in future to update/reconfigure deployment I only do docker --host ssh://core@<ip|hostname> load <images> and docker --host ssh://core@<ip|hostname> stack deploy --compose-file stack.yml <name>
13. Profit!

Example config.yml:

passwd:
    users:
        - name: core
          ssh_authorized_keys:
              - <key>
storage:
    files:
        - path: /etc/pam.d/sshd # Set auth *.so
        - path: /etc/ssh/sshd_config # Set ChallengeResponseAuthentication to yes, set UsePAM to yes, set AuthenticationMethods to publickey,password publickey,keyboard-interactive
        - path: /home/core/.google_authenticator # Include generated shared OTP secrets

This will work only for google-authenticator-libpam but should also for pam_oath (the /home/core/.google_authenticator path will be different). Everything works. The only missing thing in Fedora CoreOS ISO image is PAM module that will support TOTP out-of-box.

[tymonx]

I can create a public git sample project with Butane YAML to show how to setup SSH + OTP for Fedora CoreOS. I already have some little experience with custom derived Fedora CoreOS and I can prepare configuration that will include preinstalled OTP PAM module (google-authenticator-libpam or pam_aoth). With instruction how to test it with qemu or libvirt.

I can also prepare an example for Fedora CoreOS Documentation to show how to setup and use SSH with OTP. This should be a nice security add-on for everyone who like to harden their deployments.