pam service(sshd) ignoring max retries

Question

I have vps that I use to run a webserver on, it currently runs ubuntu server 12.04. Since a few weeks I keep getting a lot of errors in my ssh console.

2014 Apr 11 08:41:18 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:21 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:24 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:25 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:26 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3

Could someone please tell me what these errors mean. Or at least tell me how to disable these errors. It is realy anoying when I am working over ssh and these errors keep popping up all over my screen.

Solution 1

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.

Updated

To change this behaviour:

For sshd you edit /etc/ssh/sshd_config and set MaxAuthTries 3. Also restart SSH server for the setting to take effect.

For PAM, you have to look for configuration in /etc/pam.d directory (I think it's common-password file in Ubuntu), you have to change retry= value.

Note: I would strongy suggest to also check Peter Hommel's answer regarding the reason of these requests as it's possible your SSH is being brute-forced.

Solution 2

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 my system). Read your var/log/auth.log for research...

If this is the case, you shoud consider installing a tool like 'fail2ban' (sudo apt-get install fail2ban on Ubuntu). It automatically reads the log files of your system, searches for multiple failed login attempts and blocks the malicious clients for a configurable time via iptables...

Solution 3

It seems the above analysis is not completely correct. There doesn't seem to be a retry= option for pam authentication (I did find one for pam_cracklib, but that only concerns changing password in the "password" section, not authentication in the "auth" section of pam). Instead, pam_unix contains a builtin maximum number of retries of 3. After 3 retries, pam returns the PAM_MAXRETRIES error code to inform sshd of this.

sshd should really stop trying in this case, regardless of its own MaxAuthTries. It doesn't, which I think is a bug (which I just reported with openssh).

Until that bug is fixed, it seems that setting MaxAuthTries to <= 3 is the only way to prevent this message from showing up.

Solution 4

The ssh client may attempt to authenticate with one or more keys. Any keys which are not listed in authorized_keys will fail, consuming one of sshd's retries. The client will try every ssh key it has until one succeeds or all fail, so it's good that sshd lets you try several.

If no keys match, sshd may allow you to try a password. Each of these attempts also consumes one of sshd's allowed retries. But, it also consumes one of PAM's allowed retries.

So, the combination of 6 ssh auth tries and 3 pam auth tries is a good thing: it means that ssh will allow 6 auth tries total (key or password) but only 3 password tries.

As others have said, if you often see these in your logs, someone is trying to brute force their way in to your system. Consider using fail2ban to completely block packets from IP addresses from which these attempts originate.

Solution 5

After upgrading from Debian 6 to Debian 7, i ran into the same troubles. Suddenly these sshd errors came up in my console.

2014 Oct 15 13:50:12 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:17 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:18 vps456 PAM service(sshd) ignoring max retries; 6 > 3

In my case, the problem was that rsyslog was not installed anymore after the Debian upgrade.

After installing rsyslog these errors disappeared from my console: apt-get install rsyslog

View more solutions

Comments

[Jerodev]

Thank you, the problem was fixed by adding the MaxAuthTries 3 in the ssh config and then rebooting the server.

[HBruijn]

Using ssh keys and disabling passwords is even better at preventing successful brute-force attacks.

[Kent Borg]

Yes, but then the problem shifts to protecting your ssh keys. Where are they? Are they encrypted? How good a key protects them? If a password cannot be cracked in X-years of trying, then it cannot be cracked in X-years of trying, what do you need "better" for? I put a lot of time into managing my passwords, and I can type them, many of them I remember. But a bunch of ssh keys? Need some place safe to keep them.

[HBruijn]

Brute-forcing a password (typically fewer than 20 characters long and too often badly chosen) is much simpler than brute forcing a 1024 bit private key (simplified the equivalent of a 128 character password) to gain access through SSH. Let's stick to comparing apples with apples. - - Unless you're an complete idiot (e.g. storing your private key in your public github) getting at your private ssh key is difficult since it does not need to leave your workstation, ever. Once your private key is compromised we're no longer in the random attacks, but entering the realm of targeted attacks...

[phoops]

This is a very nice comment, I have updated my answer with a note to read you answer too for anyone who might come across this.

[phoops]

This only makes them appear in another place instead of console. My answer fixes the cause of the error due to SSH/PAM misconfiguration after upgrade.

[phoops]

@Kent you know you can password protect you SSH keys? Also, you say fail2ban is unnecessary but continue to suggest that SSH should implement this feature in itself. Also, if you don't block the requests they can just DDoS your system much easier.

[Dennis Nolte]

the bug seems fixed with version 7.3p1