Sur cette page L'explication donnée est la suivante :
L'option PasswordAuthentication spécifie si nous devons utiliser l'authentification par l'authentification par mot de passe. Pour les sécurité, cette option doit toujours toujours avoir la valeur "yes".
Mais il ne fournit aucun scénario d'utilisation qui clarifie quand un oui ou un non serait approprié. Quelqu'un peut-il nous donner plus de détails ?
Veuillez noter que le paramètre PasswordAuthentication ne contrôle pas TOUTE l'authentification par mot de passe. L'authentification par réponse à un défi (ChallengeResponseAuthentication) demande généralement aussi des mots de passe.
PasswordAuthentication contrôle la prise en charge du schéma d'authentification par mot de passe défini dans la RFC-4252 (section 8). ChallengeResponseAuthentication contrôle la prise en charge du schéma d'authentification "clavier interactif" défini dans la RFC-4256. Le schéma d'authentification "clavier interactif" peut, en théorie, poser à l'utilisateur n'importe quel nombre de questions à réponses multiples. En pratique, il ne demande souvent que le mot de passe de l'utilisateur.
Si vous souhaitez désactiver totalement l'authentification par mot de passe, définissez les DEUX paramètres PasswordAuthentication et ChallengeResponseAuthentication sur "no". Si vous êtes plutôt du genre "ceinture et bretelles", vous pouvez également définir UsePAM sur "no".
L'authentification basée sur les clés publiques/privées (activée par le paramètre PubkeyAuthentication) est un type d'authentification distinct qui n'implique pas l'envoi des mots de passe des utilisateurs au serveur, bien entendu.
Certains diront que l'utilisation de ChallengeResponseAuthentication est plus sûre que celle de PasswordAuthentication parce qu'elle est plus difficile à automatiser. Ils recommandent donc de désactiver l'authentification par mot de passe et d'activer l'authentification par réponse à un défi. Cette configuration encourage également (mais n'empêche pas nécessairement) l'utilisation de l'authentification par clé publique pour toute connexion automatisée au système. Mais comme SSH est un protocole basé sur le réseau, le serveur n'a aucun moyen de garantir que les réponses à ChallengeResponseAuthentication (alias "clavier interactif") sont réellement fournies par un utilisateur assis devant un clavier, tant que le(s) défi(s) consiste(nt) toujours et uniquement à demander le mot de passe d'un utilisateur.
Votre lien renvoie à une documentation datant de 10 ans.
SSH supporte plusieurs façons d'authentifier les utilisateurs, la plus commune étant de demander un login et un mot de passe, mais vous pouvez aussi authentifier l'utilisateur avec un login et une clé publique. Si vous donnez la valeur no à PasswordAuthentication, vous ne pourrez plus utiliser un login et un mot de passe pour vous authentifier et vous devrez utiliser un login et une clé publique à la place (si Authentification par clé publique est fixé à oui)
L'authentification par mot de passe est la plus simple à mettre en œuvre, car il n'y a rien à faire. La contrepartie est que vous envoyez votre mot de passe, via une connexion cryptée, au serveur. Cela peut poser un problème de sécurité si le serveur a été compromis, car le mot de passe peut alors être capturé.
Avec la clé publique, votre mot de passe n'est pas transmis au serveur, c'est plus sûr mais cela nécessite plus de configuration.
Vous pouvez le régler sur non lors de l'utilisation de clés ou d'en imposer l'utilisation.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
