search

SUSE / pam-config

Tool to modify common PAM configuration files
GNU General Public License v2.0
10 stars 16 forks source link

Support for PAM Yubico #27

Closed kees-closed closed 6 months ago

kees-closed commented 7 months ago

It looks like there is no support yet for PAM Yubico (pam_yubico.so). More info: https://developers.yubico.com/yubico-pam/

An example from my sshd service in /etc/pam.d:

auth required pam_yubico.so id=16 authfile=/etc/security/otp_maps

Where the otp_maps could look like: user:cccccctwhsbc

thkukuk commented 6 months ago

pam_yubico.so is per service, you don't want that for all services (else you would need to authenticate every cron job with your key). pam-config does not really support single services, the minimal existing support is deprecated and unmaintained. And pam-config does not create additional configuration files. So as long as nobody steps up and implements full support for "single services" in pam-config and not only common-* files, there is no way to add this module.

kees-closed commented 5 months ago

Ah okay, I thought it was meant as the tool to configure PAM on SUSE systems. This example also hinted at something like that. But the tool is not meant for that? Even though there are some command switches for --service?

It's best to create your own PAM sshd config then? That's a bit new for me, usually I can edit existing PAM files with this single Yubico line, without that it's somewhat more complicated on SUSE, since PAM is quite complex. But if this is the way to do it in SUSE, then I'll try to create a working/secure config myself for sshd.

Any advice for creating a solid PAM config on SUSE? For example by including certain existing common configs and then just add my custom line to e.g. /etc/pam.d/sshd?

thkukuk commented 5 months ago

pam-config is for configuring the common PAM config, not for special services and never was designed as this, even if there was the try to enhance it this way.

Else I don't understand your comments. Since the single service files (so not starting with common-*)are not under control of pam-config, you can edit them in the same way as with every other distribution. And since PAM is quite complex, you should understand what you are doing and not just copy&paste something in the hope it will work and not make your system insecure.

kees-closed commented 5 months ago

even if there was the try to enhance it this way

Would it be an idea to remove this unmainted/deprecated feature?

True, the non common files are not managed by pam-config, but there are also no service specific PAM configs for e.g. sshd in /etc/pam.d, but I suppose I should copy /usr/lib/pam.d/sshd to /etc/pam.d and then add my single line for MFA there. PAM is indeed complex and easy to make mistakes. I am used to a different out of the box experience with PAM, but it becomes a bit more clear now.

thkukuk commented 5 months ago

even if there was the try to enhance it this way

Would it be an idea to remove this unmainted/deprecated feature?

Why should we remove it, if it does not harm but helps some people?

True, the non common files are not managed by pam-config, but there are also no service specific PAM configs for e.g. sshd in /etc/pam.d, but I suppose I should copy /usr/lib/pam.d/sshd to /etc/pam.d and then add my single line for MFA there. PAM is indeed complex and easy to make mistakes. I am used to a different out of the box experience with PAM, but it becomes a bit more clear now.

Sometimes it helps to read the manual page:

       Vendor-supplied PAM configuration files might be installed in the
       system directory /usr/lib/pam.d/ or a configurable vendor specific
       directory instead of the machine configuration directory /etc/pam.d/.
       If no machine configuration file is found, the vendor-supplied file is
       used. All files in /etc/pam.d/ override files with the same name in
       other directories.

And no, SUSE did not introduce that directory, we only started using it after others used it already since a longer time.

kees-closed commented 5 months ago

Why should we remove it, if it does not harm but helps some people?

You mentioned it was deprecated and not really within the scope of the tool. I thought it was a good suggestion to make this more clear to new users. Just another suggestion, maybe include a --experimental flag for the incomplete/deprecated features? Or update the --help. But I'm just sharing suggestions from a new user perspective. Thanks for considering it, and thanks for the tooling. It's cool stuff.

Sometimes it helps to read the manual page

Yes! :) Sorry for taking your time unnecessarily.