I haven't tested Zealot's fix yet, but it looks promising.
The man page for pam_unix has the following to say about the nullok_secure option that is used in /etc/pam.d/common-auth:
The default action of this module is to not permit the user access to a service if their official password is blank. The nullok_secure argument overrides this default and allows any user with a blank password to access the service as long as the value of PAM_TTY is set to one of the values found in /etc/securetty.
Thus, the behavior of the module is as documented; it's a feature, not a bug! =)
So, the only possible fix would be changing nullok_secure to nullok as per Zealot's fix above (or globally in /etc/pam.d/common-auth). I do not know enough about the security implications of such a change to tell whether it would be a good idea in a default install, so I am leaving this open for now.
I haven't tested Zealot's fix yet, but it looks promising.
The man page for pam_unix has the following to say about the nullok_secure option that is used in /etc/pam. d/common- auth:
The default action of this module is to not permit the user access to a service if their official password is blank. The nullok_secure argument overrides this default and allows any user with a blank password to access the service as long as the value of PAM_TTY is set to one of the values found in /etc/securetty.
Thus, the behavior of the module is as documented; it's a feature, not a bug! =)
So, the only possible fix would be changing nullok_secure to nullok as per Zealot's fix above (or globally in /etc/pam. d/common- auth). I do not know enough about the security implications of such a change to tell whether it would be a good idea in a default install, so I am leaving this open for now.