4. The Authentication Protocol Framework

4. The Authentication Protocol Framework

Le serveur pilote l'authentification en indiquant au client quelles méthodes d'authentification PEUVENT être utilisées pour poursuivre l'échange à un moment donné. Le client a la liberté d'essayer les méthodes listées par le serveur dans n'importe quel ordre. Cela donne au serveur un contrôle complet du processus d'authentification si souhaité, mais donne aussi assez de flexibilité au client pour utiliser les méthodes qu'il prend en charge ou les plus pratiques pour l'utilisateur, lorsque le serveur propose plusieurs méthodes.

Les méthodes d'authentification sont identifiées par leur nom, comme défini dans [SSH-ARCH]. La méthode « none » est réservée, et NE DOIT PAS être listée comme prise en charge. Cependant, le client PEUT l'envoyer. Le serveur DOIT toujours rejeter cette demande, sauf si le client doit se voir accorder l'accès sans aucune authentification, auquel cas le serveur DOIT accepter cette demande. Le but principal d'envoyer cette demande est d'obtenir la liste des méthodes prises en charge auprès du serveur.

Le serveur DEVRAIT disposer d'un délai d'expiration pour l'authentification et se déconnecter si l'authentification n'a pas été acceptée dans ce délai. La période de délai RECOMMANDÉE est de 10 minutes. De plus, l'implémentation DEVRAIT limiter le nombre de tentatives d'authentification échouées qu'un client PEUT effectuer dans une seule session (la limite RECOMMANDÉE est de 20 tentatives). Si le seuil est dépassé, le serveur DEVRAIT se déconnecter.

Des réflexions supplémentaires sur les délais d'authentification et les nouvelles tentatives se trouvent dans [ssh-1.2.30].