pam service (sshd) en ignorant le nombre maximal de tentatives

J'ai des vps que j'utilise pour faire tourner un serveur web, il tourne actuellement sur le serveur Ubuntu 12.04. Depuis quelques semaines, de nombreuses erreurs se produisent dans ma console ssh.

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

Quelqu'un pourrait-il me dire ce que signifient ces erreurs? Ou du moins dites-moi comment désactiver ces erreurs. C'est vraiment angoissant quand je travaille sur ssh et que ces erreurs n'arrêtent pas de surgir sur mon écran.

PAM vous dit qu'il est configuré avec "retry = 3" et qu'il ignorera toutes les demandes d'authentification supplémentaires de sshd au cours de la même session. SSHCependant, vous continuerez d’essayer jusqu’à épuisement du paramètre MaxAuthTries (qui prend 6 par défaut).

Vous devriez probablement définir les deux (SSH et PAM) sur la même valeur pour un nombre maximal de tentatives d'authentification.

Mis à jour

Pour changer ce comportement:

Pour sshdvous éditer /etc/ssh/sshd_configet définir MaxAuthTries 3. Redémarrez également le serveur SSH pour que le paramètre prenne effet.

Pour PAM, vous devez chercher la configuration dans le /etc/pam.drépertoire (je pense que c'est le common-passwordfichier dans Ubuntu), vous devez changer la retry=valeur.

Remarque: Je suggérerais fortement de vérifier également la réponse de Peter Hommel concernant la raison de ces demandes, car il est possible que votre SSH soit forcé de force.

Tandis que les autres réponses éliminent correctement le message d'erreur que vous avez reçu, considérez que ce message d'erreur peut simplement être un symptôme d'un autre problème sous-jacent.

Vous recevez ces messages car de nombreuses tentatives de connexion via SSH ont échoué sur votre système. Il peut y avoir quelqu'un qui essaie de forcer brutalement dans votre boîte (c'était le cas lorsque j'ai reçu les mêmes messages sur mon système). Lire votrevar/log/auth.log recherche ...

Si tel est le cas, vous devriez envisager d'installer un outil tel que 'fail2ban' ( sudo apt-get install fail2bansur Ubuntu). Il lit automatiquement les fichiers journaux de votre système, recherche plusieurs tentatives de connexion infructueuses et bloque les clients malveillants pendant une heure configurable via iptables ...

Il semble que l'analyse ci-dessus n'est pas complètement correcte. Il ne semble pas y avoir d’option retry = pour l’authentification pam (j’en ai trouvé une pour pam_cracklib, mais cela ne concerne que la modification du mot de passe dans la section "mot de passe" et non l’authentification dans la section "auth" de pam). Au lieu de cela, pam_unix contient un nombre maximum de tentatives intégrées de 3. Après 3 tentatives, pam renvoie le code d'erreur PAM_MAXRETRIES pour en informer sshd.

sshd devrait vraiment cesser d'essayer dans ce cas, indépendamment de ses propres MaxAuthTries. Ce n'est pas le cas, ce qui, à mon avis, est un bogue (que je viens de signaler avec openssh ).

Jusqu'à ce que ce bogue soit corrigé, il semble que définir MaxAuthTries sur <= 3 soit le seul moyen d'empêcher l'affichage de ce message.

Le client ssh peut tenter de s'authentifier avec une ou plusieurs clés. Toutes les clés qui ne sont pas répertoriées dans allowed_keys échoueront et prendront l'une des tentatives de sshd. Le client essaiera toutes les clés ssh jusqu’à ce qu’elles réussissent ou échouent. Il est donc bon que sshd vous en permette plusieurs.

Si aucune clé ne correspond, sshd peut vous permettre d'essayer un mot de passe. Chacune de ces tentatives consomme également l'une des tentatives autorisées par sshd. Mais, il consomme également une des tentatives autorisées par PAM.

Ainsi, la combinaison de 6 tentatives d’authentification ssh et de 3 tentatives d’authentification pam est une bonne chose: cela signifie que ssh autorisera un total de 6 tentatives d’authentification (clé ou mot de passe) mais seulement 3 tentatives de mot de passe.

Comme d'autres l'ont déjà dit, si vous les voyez souvent dans vos journaux, quelqu'un essaye de forcer brutalement votre système. Envisagez d'utiliser fail2ban pour bloquer complètement les paquets d'adresses IP à l'origine de ces tentatives.

Après la mise à niveau de Debian 6 vers Debian 7, j'ai rencontré les mêmes problèmes. Soudain, ces erreurs sshd sont apparues dans ma 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

Dans mon cas, le problème était qu’il rsyslogn’était plus installé après la mise à jour de Debian.

Après l'installation de rsyslog, ces erreurs ont disparu de ma console: apt-get install rsyslog

Obtenir ces avis sur votre console peut certes être ennuyeux, mais quand je vois dans mes fichiers journaux qu'hier, 987 tentatives de connexion root ont échoué à partir d'une adresse IP en Chine, ou 2670 à partir d'un service cloud en Californie, ou ... beaucoup les autres, je ne m'inquiète pas. L'utilisateur root n'est pas autorisé à se connecter du tout sur ma machine. Peu importe combien d'essais.

S'ils commençaient à essayer des noms d'utilisateur pouvant se connecter, ce serait une autre affaire, mais si vous avez de bons mots de passe, je n'y vois aucun risque non plus. Les mots de passe de connexion (contrairement aux clés de cryptage) ne peuvent être essayés aussi rapidement.

Utiliser quelque chose comme fail2ban semble une complexité inutile qui n'achète rien (si vous avez de bons mots de passe) et la complexité est mauvaise pour la sécurité. Sshd doit mettre en œuvre des tentatives de limitation, et non une opération qui devrait nécessiter des ajouts ... et sshd effectue des tentatives de limitation . Bien.

-kb, le Kent qui n'utilise que de bons mots de passe et qui n'est jamais recyclé entre différents sites.