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

32

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.

Jerodev
la source

Réponses:

40

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.

phoops
la source
Merci, le problème a été résolu en ajoutant le MaxAuthTries 3dans la configuration ssh puis en redémarrant le serveur.
Jerodev
41

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

Peter Hommel
la source
4
Ceci est un très bon commentaire, j'ai mis à jour ma réponse avec une note pour vous lire répondre aussi pour toute personne qui pourrait rencontrer cela.
phoops
5

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.

Matthijs Kooijman
la source
le bug semble résolu avec la version 7.3p1
Dennis Nolte
3

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.

Facture
la source
1

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

ordinateur
la source
3
Cela les fait seulement apparaître dans un autre endroit au lieu de console. Ma réponse corrige la cause de l'erreur en raison d'une mauvaise configuration de SSH / PAM après la mise à niveau.
phoops
-1

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.

Kent Borg
la source
2
L'utilisation de clés ssh et la désactivation des mots de passe sont encore plus efficaces pour empêcher les attaques par force brute.
HBruijn
Oui, mais le problème passe maintenant à la protection de vos clés ssh. Où sont-elles? Sont-ils cryptés? Comment une clé les protège? Si un mot de passe ne peut pas être déchiffré en X ans d’essai, il ne peut pas être déchiffré en X ans d’essai. Pourquoi avez-vous besoin de "mieux"? Je passe beaucoup de temps à gérer mes mots de passe et je peux les saisir, mais je me souviens de nombre d'entre eux. Mais un tas de clés SSH? Besoin d'un endroit sûr pour les garder.
Kent Borg
2
Forcer brutalement un mot de passe (généralement moins de 20 caractères et trop souvent mal choisi) est beaucoup plus simple que forcer brutalement une clé privée de 1024 bits (simplifié l'équivalent d'un mot de passe de 128 caractères) pour accéder via SSH. Restons-en à comparer des pommes avec des pommes. - - Sauf si vous êtes complètement idiot (par exemple, stocker votre clé privée dans votre github public), accéder à votre clé ssh privée est difficile car il n’a pas besoin de quitter votre poste de travail. Une fois que votre clé privée est compromise, nous ne faisons plus partie des attaques aléatoires, mais nous entrons dans le royaume des attaques ciblées ...
HBruijn
@Vous savez que vous pouvez protéger vos clés SSH avec un mot de passe? De plus, vous dites que fail2ban est inutile, mais continuez de suggérer que SSH devrait implémenter cette fonctionnalité en elle-même. En outre, si vous ne bloquez pas les demandes, ils peuvent simplement DDoS votre système beaucoup plus facilement.
phoops