Quelle est la différence entre chacun des types d'entrée (console, vc / et tty ). Plus précisément, quel est le résultat final de l'ajout et de la suppression de chaque type d'entrée?
Ma compréhension est qu'ils affectent comment et quand vous pouvez vous connecter, mais y a-t-il d'autres effets? Et quand pouvez-vous et quand ne pouvez-vous pas vous connecter en fonction des entrées disponibles?
EDIT 1
Ce que je sais, c'est que les tty 1-6 correspondent à la possibilité de se connecter à partir des 6 premières consoles que vous atteignez en utilisant CTRL-ALT-F1 à CTRL-ALT-F6. J'ai toujours pensé qu'il s'agissait de consoles virtuelles, donc je suis un peu confus. Et à quoi correspond la console aussi? Merci.
EDIT 2
Quel est l'effet le cas échéant en mode mono-utilisateur?
/etc/securettyest consulté par le module pam_securetty pour décider depuis quel terminal virtuel (ttyS) root est autorisé à se connecter. Dans le passé, /etc/securettyétait consulté directement par des programmes comme login directement, mais maintenant PAM gère cela. Les modifications apportées /etc/securettyaffecteront donc tout ce qui utilise PAM avec un fichier de configuration qui utilise pam_securetty.so. Ainsi, seul le programme de connexion est affecté par défaut. /etc/pam.d/loginest utilisé pour les connexions locales et /etc/pam.d/remoteest utilisé pour les connexions à distance (comme telnet).
Les principaux types d'entrée et leurs effets sont les suivants:
S'il /etc/securettyn'existe pas, root est autorisé à se connecter depuis n'importe quel terminal
S'il /etc/securettyexiste et est vide, l'accès root sera limité au mode mono-utilisateur ou aux programmes qui ne sont pas limités par pam_securetty (c'est-à-dire su, sudo, ssh, scp, sftp)
si vous utilisez devfs (un système de fichiers obsolète pour gérer / dev), l'ajout d'entrées de la forme vc / [0-9] * permettra la connexion root à partir du numéro de console virtuelle donné
si vous utilisez udev (pour la gestion dynamique des périphériques et le remplacement de devfs), l'ajout d'entrées de la forme tty [0-9] * permettra la connexion root à partir du numéro de console virtuelle donné
lister la console dans securetty, n'a normalement aucun effet puisque / dev / console pointe vers la console actuelle et n'est normalement utilisé que comme nom de fichier tty en mode mono-utilisateur, qui n'est pas affecté par /etc/securetty
l'ajout d'entrées comme pts / [0-9] * permettra aux programmes qui utilisent des pseudo-terminaux (pty) et pam_securetty de se connecter à la racine en supposant que le pty alloué est l'un de ceux répertoriés; c'est normalement une bonne idée de ne pas inclure ces entrées car c'est un risque pour la sécurité; cela permettrait, par exemple, à quelqu'un de se connecter à root via telenet, qui envoie des mots de passe en texte brut (notez que pts / [0-9] * est le format pour udev utilisé dans RHEL 5.5; il sera différent si vous utilisez devfs ou une autre forme de gestion des appareils)
Pour le mode mono-utilisateur, /etc/securettyn'est pas consulté car le sulogin est utilisé à la place de la connexion. Consultez la page de manuel de sulogin pour plus d'informations. Vous pouvez également modifier le programme de connexion utilisé /etc/inittabpour chaque niveau d'exécution.
Notez que vous ne devez pas utiliser /etc/securettypour contrôler les connexions root via ssh. Pour ce faire, modifiez la valeur de PermitRootLogin dans /etc/ssh/sshd_config. Par défaut, il /etc/pam.d/sshdn'est pas configuré pour consulter pam_securetty (et donc /etc/securetty). Vous pouvez ajouter une ligne pour ce faire, mais ssh ne définit le tty réel que quelque temps après l'étape d'authentification, donc cela ne fonctionne pas comme prévu. Pendant les étapes d'authentification et de compte - au moins pour openssh - le tty (PAM_TTY) est codé en dur à "ssh".
La réponse ci-dessus est basée sur RHEL 5.5. Une grande partie se rapportera aux distributions actuelles d'autres systèmes * nix, mais il existe des différences, dont j'ai noté certaines, mais pas toutes.
J'ai répondu moi-même parce que les autres réponses étaient incomplètes et / ou inexactes. De nombreux autres forums, blogs, etc. en ligne contiennent également des informations inexactes et incomplètes sur ce sujet, j'ai donc effectué des recherches et des tests approfondis pour essayer d'obtenir les détails corrects. Si quelque chose que j'ai dit est faux, faites-le moi savoir.
+1 pour avoir pris le temps de répondre en profondeur. Je ne sais pas pourquoi il n'y a pas de réponse acceptée ici. On dirait que vous avez répondu à la question du PO. J'aime le commentaire de @Alexios, "vc / X et ttyX sont synonymes [ous] ..."
harperville
Debian a récemment supprimé / etc / securetty. Il est considéré comme obsolète et sans doute plus de problèmes qu'il n'en vaut la peine. Il a été utilisé pour telnet et rlogin, mais pour que certaines connexions de conteneurs fonctionnent, des pseudoterminaux comme "pts / 0" sont ajoutés sur certains systèmes, ce qui va à l'encontre de son objectif d'origine. Si vous devez restreindre la connexion root à un ensemble spécifique d'appareils, il existe des mécanismes plus fiables. Voir bugs.debian.org/731656
dlitz
4
vc/Xet ttyXsont synonymes: chemins différents vers les mêmes appareils. Le but de la redondance est d'attraper divers cas afin de ne pas vous enfermer.
Traditionnellement, login(et peut-être getty, je ne me souviens pas avec certitude) vérifiait /etc/securettyet refusait les rootconnexions sur les terminaux non répertoriés. Sur les systèmes modernes, il existe d'autres façons de procéder ainsi que d'autres mesures de sécurité. Consultez le contenu de /etc/login.defs(qui couvre également securettyles fonctionnalités de et qui est recommandé par la securetty(5)page de manuel), et aussi /etc/pam.d/login, où vous pouvez contrôler le comportement de cette fonctionnalité.
Puisque securettyest uniquement vérifié par login, les moyens de connexion qui n'utilisent pas login(par exemple SSH avec use_login=no, X display managers, etc.) ne sont pas affectés.
Il convient de noter que sur les busyboxsystèmes basés sur, il pourrait toujours être utile pour le simple fait qu'il loginn'a pas de /etc/login.defssupport.
vc/XetttyXsont synonymes: chemins différents vers les mêmes appareils. Le but de la redondance est d'attraper divers cas afin de ne pas vous enfermer.Traditionnellement,
login(et peut-êtregetty, je ne me souviens pas avec certitude) vérifiait/etc/securettyet refusait lesrootconnexions sur les terminaux non répertoriés. Sur les systèmes modernes, il existe d'autres façons de procéder ainsi que d'autres mesures de sécurité. Consultez le contenu de/etc/login.defs(qui couvre égalementsecurettyles fonctionnalités de et qui est recommandé par lasecuretty(5)page de manuel), et aussi/etc/pam.d/login, où vous pouvez contrôler le comportement de cette fonctionnalité.Puisque
securettyest uniquement vérifié parlogin, les moyens de connexion qui n'utilisent paslogin(par exemple SSH avecuse_login=no, X display managers, etc.) ne sont pas affectés.la source
busyboxsystèmes basés sur, il pourrait toujours être utile pour le simple fait qu'illoginn'a pas de/etc/login.defssupport.