Sur cette page , l'explication donnée est:
L'option PasswordAuthentication spécifie si nous devons utiliser l'authentification par mot de passe. Pour une sécurité renforcée, cette option doit toujours être définie sur oui.
Mais il ne fournit aucun scénario d'utilisation qui précise quand un oui ou un non serait approprié. Quelqu'un peut-il développer davantage?
Réponses:
Votre lien pointe vers une documentation obsolète depuis 10 ans.
SSH prend en charge plusieurs façons d'authentifier les utilisateurs, la plus courante consiste à demander un identifiant et un mot de passe, mais vous pouvez également authentifier l'utilisateur avec un identifiant et une clé publique. Si vous définissez PasswordAuthentication sur non, vous ne pourrez plus utiliser un identifiant et un mot de passe pour vous authentifier et devez utiliser à la place un identifiant et une clé publique (si PubkeyAuthentication est défini sur oui)
Veuillez noter que le paramètre PasswordAuthentication ne contrôle pas TOUTES les authentifications par mot de passe. ChallengeResponseAuthentication demande généralement également 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 «interactif au clavier» défini dans la RFC-4256. Le schéma d'authentification «interactif au clavier» pourrait, en théorie, poser à un utilisateur un certain nombre de questions à facettes multiples. En pratique, il ne demande souvent que le mot de passe de l'utilisateur.
Si vous souhaitez désactiver complètement l'authentification par mot de passe, définissez BOTH PasswordAuthentication et ChallengeResponseAuthentication sur «no». Si vous êtes de la mentalité des ceintures et bretelles, envisagez également de régler UsePAM sur «non».
L'authentification par clé publique / privée (activée par le paramètre PubkeyAuthentication) est un type d'authentification distinct qui n'implique pas l'envoi de mots de passe utilisateur au serveur, bien sûr.
Certains diront que l'utilisation de ChallengeResponseAuthentication est plus sécurisée que PasswordAuthentication car elle est plus difficile à automatiser. Ils recommandent donc de laisser PasswordAuthentication désactivé tout en laissant ChallengeResponseAuthentication activé. Cette configuration encourage également (mais n'empêche pas nécessairement) l'utilisation de l'authentification publickey pour toutes les connexions système automatisées. Mais, puisque 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 sur un clavier tant que le (s) défi (s) est toujours et consiste uniquement à demander à un utilisateur son mot de passe.
UsePAMfait ...
PasswordAuthentication est l'implémentation la plus simple, 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 être un problème de sécurité si le serveur a été compromis, car le mot de passe pourrait alors être capturé.
Avec la clé publique, votre mot de passe n'est pas transmis au serveur, il est plus sécurisé mais il a besoin de plus de configuration.
Vous pouvez le régler sur no lors de l'utilisation des clés ou pour forcer leur utilisation.