This happens when dbus is restarted, but systemd-logind is not restarted. Just do the following:
systemctl restart systemd-logind
The solution is from here:
While the other answers are correct in elimiating the error message you got, consider that this error message may just be a symptom of another underlying problem.
You get these messages because there are many failing login attempts via ssh on your system. There may be someone trying to brute-force into your box (was the case when I got the same messages on ...
PAM is telling you that it is configured with "retry=3" and it will ignore any further auth requests from sshd within the same session. SSH however will continue trying until it exhausts MaxAuthTries setting (which defaults to 6).
You should probably set both of these (SSH and PAM) to same value for maximum auth retries.
To change this behaviour:
After all that, it turns out to have been a one-character typo in /etc/shadow. Spot the difference:
That's right, there are two colons after the exclamation point on the tbbscraper line. That shoves all the fields over one and makes PAM think that the account expired on January 8, 1970.
It helps to break things down like this in your head:
NSS - A module based system for controlling how various OS-level databases are assembled in memory. This includes (but is not limited to) passwd, group, shadow (this is important to note), and hosts. UID lookups use the passwd database, and GID lookups use the group database.
PAM - A module based system ...
Well, an item that you haven’t mentioned is the fingerprints of the private keys they tried before entering a password. With openssh, if you set LogLevel VERBOSE in /etc/sshd_config, you get them in the log files. You can check them against the collection of public keys your users have authorized in their profiles, to see if they have been compromised. In ...
maybe the exact question is how to configure pam to disallow passwords?
Correct. You've already stumbled upon the fact that setting UsePAM no is generally bad advice. Not only does it prevent any form of PAM based authentication, it also disables account and session modules. Access control and session configuration are good things.
First, let's build a ...
If you remove the setuid bit from the passwd command, only root will be able to use it. This will also disable the users from changing the password before it expires - which could otherwise be a way for the users to extend the account for another four hours.
[jenny@finch ~] sudo chmod -s /usr/bin/passwd
[jenny@finch ~]$ passwd
Changing password for user ...
You need to enable the user to use cron in the login access control table file /etc/security/access.conf
Use the following entry which will allow the coins user to run cron jobs:
# Allow the coins user to run cron jobs
+: coins : cron crond :0
Ensure it is above the last entry:
# Deny all other users access by any means.
-: ALL : ALL
As this entry denies ...
Generally, password expiration is used to force users to change their passwords. What it sounds like you want to do is to lock the account, which prevents all login.
What I would suggest you do instead is, when you create the account, also set up an at job which will lock the account after four hours.
echo chage -E 0 temp8143 ...
Going little bit further into the LogLevel DEBUG, you can also find out the client software/version in format
Client protocol version %d.%d; client software version %.100s
It will also print the key exchange, ciphers, MACs and compression methods available during the key exchange.
This excerpt was taken from amazing book written by Linux advocate Evi Nemeth( unfortunately recently lost in the sea http://www.theregister.co.uk/2013/07/05/evi_nemeth_unix_dead/ ) in her one of the first and best linux admin book: Linux® Administration Handbook. For this case it was in the second edition of the book, I am not sure if this was duplicated ...
Let's analyze the authentication section of your PAM configuration in detail.
auth sufficient pam_unix.so nullok try_first_pass
The first line says: "If this test is successful, stop checking any further and accept the login; if it fails, keep checking. Check for users/passwords configured in /etc/passwd and /etc/shadow.If the user exists and the ...
PAM does not just do authentication, but authorisation and session services. You probably want to keep it on as it adds quite a bit of flexibility.
PAM will be called for a successful pubkey authentication, because session and account services are still checked.
PAM can do things SSH cannot. This list is not exhaustive:
Deny a user access if SELinux is ...
If you block all user even block root you can add this lines to /etc/pam.d/password-auth or /etc/pam.d/sshd, in the auth section add this to block all user for 5 minutes:
auth required pam_tally2.so file=/var/log/tallylog deny=3 even_deny_root unlock_time=300
Now add the following line to the account section:
account required ...
At least on CentOS 6.4, /etc/pam_debug is NOT used.
If the pam_warn.so module is installed, you can get some logging output this way:
auth required pam_warn.so
success required pam_warn.so
etc. This module ensures that it will not interfere with the authentication process at any point, but it logs meaningful stuff via syslog.
After examining the ...
Temporarily tune via pam-auth-update command
You can temporarily deactivate Kerberos with the pam-auth-update. So that it looks like this:
[ ] Kerberos authentication
You can then add users/change passwords.
And then reactivate Kerberos with pam-auth-update when you are done. So that it looks like this:
[*] Kerberos authentication
See also: pam-auth-update ...
Thank you for posting your question. I was getting the same error, but my problem wasn't related to the shadow file. I found my fix and wanted to post an answer as well for anyone else Googling this error. This serverfault question comes up first.
Try checking the /etc/security/access.conf !
We're using Active Directory for authentication, but I needed to ...
Thanks for updating your question, that advice often gets taken the wrong way.
Your requirements as I understand them:
UID/GID lookups for all users must run against local files.
Authentication for specific users must try LDAP (Active Directory) first.
The short version is that yes, this is possible, but it requires actually understanding how these ...
PAM modules have over 30 different return values that are mapped to either pass or fail of the whole PAM stack as stated by the configuration.
It is noteworthy that a PAM module may behave different depending on the context (auth, account, password, session) that it is called in.
The pairs of value=action in square brackets describe which action to take ...
What I recommend is to stagger your security solutions. Security is best implemented in Layers, and having one solutions means you will have a Single Point of Failure.
Fail2Ban, as stated above by Jeff Ferland, is a good first step solution. It will monitor your log files for signs of a brute force attack, and can be configured to listen generally against ...
In order to disable two-factor auth for users without Google Authenticator configured, add the nullok option in /etc/pam.d/sshd:
auth required pam_google_authenticator.so nullok
For more details see: https://github.com/google/google-authenticator-libpam#setting-up-a-user
I just happened to spend several hours trying to find out how to enable debug logs in PAM on CentOS 6.4. Although this question is for Debian, I will still write down how to do it on CentOS in the hope that other people don't have to put in the time that I already have.
As it ultimately turned out, enabling debug logs in the pam CentOS package is ...
I had a similar problem, but with SSH logins only. Local logins (via console) respected the /etc/security/limits.conf.
As it turned out, when you set:
in /etc/ssh/sshd_config file, then sshd forks an unprivileged child to set up the account's env. Because this child is unprivileged, then pam_limits.so setting upper limits had ...
Debian and Ubuntu (and maybe other distros) have a special log file into which all pam output is logged:
I've been struggling with a pam related problem for a day and a half, finally found out about this log file, and saved myself from insanity.
Here's a sample of the contents of this file when things don't go as planned.
Jul 10 09:31:...
A home directory must be set for the user. If the user doesn't have one, you can specify it directly in the cron.d-file.
You probably need to provide PATH=/usr/bin/ too, or specify full path for the command.
0 3 * * * apache /usr/bin/php /path/to/my/script.php
Expanding on @bonsaiviking's answer you can generate the openssl md5 password and add it to the ftpd.passwd file in one line using htpasswd's batch mode -b, and plaintext -p options as follows:
htpasswd -c -p -b ftpd.passwd *username* $(openssl passwd -1 -noverify *password*)
The example above (Ubuntu) also creates a new ftpd.passwd file if it doesn't ...