37

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.

Improve this question
0

6 Answers 6

Reset to default
43

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.

Improve this answer
1
  • Thank you, the problem was fixed by adding the MaxAuthTries 3 in the ssh config and then rebooting the server.
    – Jerodev
    Apr 11, 2014 at 8:17
43

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...

Improve this answer
1
  • 4
    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.
    – ek9
    Nov 26, 2014 at 18:13
5

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.

Improve this answer
1
  • the bug seems fixed with version 7.3p1
    – Dennis Nolte
    Sep 13, 2016 at 12:10
3

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.

Improve this answer
1

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

Improve this answer
1
  • 3
    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.
    – ek9
    Nov 26, 2014 at 18:16
-1

Certainly getting those notices on your console could be annoying, but when I see in my log files that yesterday I had 987 failed root login attempts coming from an IP address in China, or 2670 from some cloud service in California, or ...many others, I don't worry. User root isn't allowed to login at all on my machine. No matter how many tries.

Were they to start trying user names that can login, that would be a different matter, but if one has good passwords, I don't see a risk there either. Login passwords (unlike encryption keys) can only be tried so fast.

Using something like fail2ban seems unnecessary complexity that doesn't buy anything (if you have good passwords) and complexity is bad for security. Throttling attempts is something that sshd should implement, not something that should require some add-on...and sshd does throttle attempts. Good.

-kb, the Kent who only uses good passwords, and never recycled between different sites.

Improve this answer
4
  • 2
    Using ssh keys and disabling passwords is even better at preventing successful brute-force attacks.
    – HBruijn
    Nov 11, 2014 at 15:07
  • 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.
    – Kent Borg
    Nov 11, 2014 at 19:36
  • 2
    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...
    – HBruijn
    Nov 11, 2014 at 20:12
  • @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.
    – ek9
    Nov 26, 2014 at 18:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .