Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm using Fedora 19. By default it's setup with pam to disable bad passwords, like "password". This is good. Trying to change this default is infuriating. This is a box for testing internal stuff, not connected to the internet, nor any machine that is. Bad passwords facilitate the testing process. Alternatively, how the hell do you change password requirements at all??


man pam_cracklib has some great examples of setting different password requirements. So I open up /etc/pam.d/system-auth, which is where you see lines like:

# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
password    requisite try_first_pass retry=3 authtok_type=
password    sufficient sha512 shadow nullok try_first_pass use_authtok
password    required

*headdesk*. In my experience, warnings like this mean your changes are wiped every time the package manager is run and/or randomly.


So...authconfig is the next step. I look for all files named "authconfig". /etc/sysconfig/authconfig looks promising. And, no warning at the top about destroying my edits on a whim. I find this line USEPWQUALITY=yes and change it. Now I run:

# authconfig --test
pam_pwquality is enabled (try_first_pass retry=3 authtok_type=)

wtf. So let's read man authconfig a little closer. Oh! Looks like that file isn't read by authconfig, it's changed. do you configure authconfig? The manual suggests system-config-authentication, which I install and doesn't provide anything resembling a checkbox to disable pam_pwquality. The next suggestion from the manual is command line options. Great! I love command line tools. Only, none of the documented command line options disable pam_pwquality.


Thanks to Aaron's answer, I learned that a couple years ago fedora decided to make /etc/security/pwquality.conf the place to configure password quality requirements. Unfortunately, as documented in the file and in man 5 pwquality.conf, there (1) isn't a way to disable the dictionary checking and (2) can't set allowed password length below six.

share|improve this question
If it's internal why is Pam installed or even enabled? – Ramhound Sep 19 '13 at 17:23
@Ramhound because fedora is infested with pam. yum remove pam removes, as far as I can tell by the time it takes to scroll all its depending packages, everything. Including yum and systemd. Also, disabling pam feels like a sledgehammer, when I think I just want to use sand paper. – djeikyb Sep 19 '13 at 17:47

4 Answers 4

After a cursory look at the source code in /usr/sbin/authconfig and /usr/share/authconfig/

  • The man page is incomplete, the complete list of options accepted by the script is in authconfig --help
  • Everything can be overridden on the command-line (even /etc/security/pwquality.conf settings like password minimum length), except pwquality itself. IMHO, this is a bug and should be reported.
  • From line 2489 and 2156:

    def read(self):

    First readSysconfig reads /etc/sysconfig/authconfig ; then what you put there is overwritten by readPAM with what is in /etc/pam.d/* (especially password_auth* and system_auth*):

      if module.startswith("pam_cracklib") or module.startswith("pam_pwquality"):
         self.setParam("enablePWQuality", True, ref)

TL;DR: for the options which are not overriden (or cannot be), the settings are taken from the current configuration including files which are tagged autogenerated. To make it work, edit /etc/sysconfig/authconfig and remove lines shown by grep -E pwq\|crack /etc/pam.d/*

Edit: There is a second bug, which makes the advice above still not work: line 2248:

    # Special handling for pam_pwquality and pam_passwdqc: there can be
    # only one.
    if self.enablePWQuality and self.enablePasswdQC:
            self.setParam("enablePasswdQC", False, ref)
    if not self.enablePWQuality and not self.enablePasswdQC:
            self.setParam("enablePWQuality", True, ref)

You have to chose one of the two implementation of quality control, or one will be chosen for you ! Combined with first bug, this makes it impossible to disable.

share|improve this answer

It looks to be configurable through /etc/security/pwquality.conf


share|improve this answer
Thanks, I hadn't seen that yet. Unfortunately, pwquality.conf doesn't support disabling dictionary checks or disabling password length checks. – djeikyb Sep 20 '13 at 16:36
Maybe the suggestion in this post would work?… – Aaron Okano Sep 21 '13 at 0:46
i.e. remove the module from system-auth and also set USEPWQUALITY=no and then run authconfig --update. – Aaron Okano Sep 21 '13 at 0:47
Unfortunately (as mentioned in the question), running authconfig --updateall resets the files. I'm thoroughly perplexed at that answer, since it directly contradicts the behaviour I'm observing. – djeikyb Sep 21 '13 at 0:58
I should also note, just setting USEPWQUALITY=no and/or USECRACKLIB=no doesn't solve my problem either, even before running authconfig. – djeikyb Sep 21 '13 at 0:58

You can still change from the command line. You get a warning, but it will let you set a password that is too short, as well as one that does not meet complexity rules.

share|improve this answer
This is absolutely not the behaviour I experience with Fedora 19. – djeikyb Dec 9 '13 at 1:26
@djeikyb run the passwd <username> command as root (Either with sudo passwd <username> or after su - to root terminal. – Nick Dec 18 '13 at 21:06
@Nick That doesn't disable or modify pam's password requirements. – djeikyb Dec 18 '13 at 23:34
@djeikyb It does not change the requirement, but it bypasses it. When you run passwd as root, it will ignore the password policies. If you just need to set it once and forget it, then that will work. If you are trying to set it so each user can freely change their passwords, then you need another solution. – Nick Dec 19 '13 at 16:46
@Nick I see. Yes, root can use passwd without being f-d with by pam. Little to do with the actual question, but it does make the claim in this "answer" true. – djeikyb Dec 19 '13 at 20:22

I just found this question based on a related search, and I think I have an answer for you.

Fedora creates symbolic links to the authconfig generated files. i.e.. system-auth links to system-auth-ac. If you make system-auth its own file, then theoretically any future changes made by auth-config will still update system-auth-ac but leave your modified files unchanged.

It's actually quite elegant, but I only discovered it when wondering what the *-ac files did.

share|improve this answer
This doesn't work. The next run of authconfig (e.g. authconfig --updateall) will delete your file and symlink it back to the -ac file. – The Doctor What Apr 15 '14 at 17:09
@TheDoctorWhat Is that so? Now it doesn't make any sense too me why they would do it that way if it wasn't to allow persistence of local changes with an easy fallback to the managed configuration. Oh well. – Cyclone Apr 16 '14 at 4:09
Yeah, it confuses me too... the documentation doesn't talk about it and the source code even has a long comment explaining how they're trying to be all things for everyone...very annoying. – The Doctor What Apr 18 '14 at 6:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.