Connexion utilisateur dans sshd_config


12

Je regardais mon fichier sshd_config et j'ai trouvé ceci:

#Uselogin no

Je sais que c'est commenté mais il n'y a aucune explication au-dessus et quand je le google, j'obtiens ceci:

N'utilisez pas le service de connexion traditionnel (1) pour vous connecter aux utilisateurs. Parce que nous utilisons la séparation des privilèges, dès que l'utilisateur se connecte, le service login (1) est désactivé.

OU

Spécifie si login (1) est utilisé pour les sessions de connexion interactives. La valeur par défaut est "non". Notez que login (1) n'est jamais utilisé pour l'exécution de commandes à distance. Notez également que si cette option est activée, X11Forwarding sera désactivé car login (1) ne sait pas comment gérer les cookies xauth (1). Si UsePrivilegeSeparation est spécifié, il sera désactivé après l'authentification.

Autant que noje sache, empêcher ssh d'utiliser la "connexion traditionnelle" mais je ne trouve rien sur la connexion "traditionnelle".

Quelqu'un pourrait-il expliquer ce qu'il fait?

Réponses:


15

Ok, nous avons besoin d'un peu d'histoire ici, à l'époque où le principal moyen d'accéder à une boîte UNIX était un terminal et une ligne série, quatre programmes étaient impliqués dans la connexion. Ils étaient init, getty, login et un shell. init a démarré getty et l'a fait fonctionner. getty a ouvert un port série (et a peut-être fait des trucs spécifiques au modem), puis a affiché l'invite de connexion et a attendu la saisie d'un nom d'utilisateur. Lorsqu'un nom d'utilisateur était entré, Getty a exécuté la connexion avec le nom d'utilisateur et la connexion demandait alors le mot de passe, effectuait les tâches de compte, puis exécutait le shell, à quel point vous pouviez utiliser le système. Ceci est toujours utilisé dans les centres de données, les machines virtuelles et bien d'autres endroits.

Vint ensuite telnet. Telnet n'utilisait pas de port série, les choses ont donc un peu changé. init serait en plus de getty également démarrer telnetd (ou inetd qui démarrerait telnetd) telnetd obtiendrait le nom d'utilisateur puis exécuterait la connexion et tout fonctionnerait à peu près de la même façon à partir de là.

Maintenant vient le long de la coque sécurisée. Maintenant, le shell sécurisé vous permet de vous connecter sans mot de passe (en utilisant une clé ou peut-être en fonction de la version GSS), donc il y avait quelques façons de faire les choses, vous pourriez faire des choses exactement comme telnet et ne pas utiliser les fonctionnalités intéressantes ou vous pouvez laisser sshd gérer la connexion et démarrer le shell qui vous permet de faire toutes sortes de choses sympas. À moins que vous n'ayez une version personnalisée de connexion, je vous recommande de laisser sshd gérer les connexions. (Et si vous avez pam, il n'y a plus beaucoup de raisons de faire une connexion personnalisée.)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.