Bonjour,
Je cherche une solution pour ne permettre l'accès à mon serveur (Ubuntu Server) que par SSH et donc que si un utilisateur tente d'entrer l'identifiant et le mot de passe directement sur la machine l'accès lui soit refusé.
Merci d'avance
Bonjour,
Je cherche une solution pour ne permettre l'accès à mon serveur (Ubuntu Server) que par SSH et donc que si un utilisateur tente d'entrer l'identifiant et le mot de passe directement sur la machine l'accès lui soit refusé.
Merci d'avance
# /etc/init/tty*.conf
Posté par dafp . Évalué à 1.
ma solution serait de fermer tout les tty* au démarrage.
Supprime les du dossier /etc/init/
[^] # Re: /etc/init/tty*.conf
Posté par moulator . Évalué à 2.
C'est le fichier /etc/inittab qui contient la liste des consoles à activer (lignes commençant par 1 à 6, et T0..n pour les consoles série).
Préfixer la ligne avec un # pour désactiver.
Mais ça empêche naturellement toute intervention ultérieure en cas de problème au démarrage ou connexion réseau hors service…
[^] # Re: /etc/init/tty*.conf
Posté par dafp . Évalué à 1.
Pas chez tout le monde.
Je n'ai pas ce fichier par exemple.
[^] # Re: /etc/init/tty*.conf
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Sous Debian, virer les lignes tty à la fin du fichier /etc/inittab
Par défaut, je n'en garde que 2 et vire les lignes de 3 à 6.
[^] # Re: /etc/init/tty*.conf
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Non, il suffit de rebooter et via grub, de lancer bash à la place d'init… Je n'en dis pas plus !
[^] # Re: /etc/init/tty*.conf
Posté par Dabowl_75 . Évalué à 1.
c'est pas : le caractère de commentaire dans /etc/inittab ?
C'est le cas sur des unix systemV comme aix…
# Clavier et Souris
Posté par ack . Évalué à 2.
Le plus simple parait de retirer clavier et souris.
Les autres solutions ne me semble pas une bonne idée. Que ce passe-t-il si tu n'as plus de réseau pour une raison ou une autre?
[^] # Re: Clavier et Souris
Posté par ninis666 . Évalué à 5.
Oui, et bien sûr, ne pas oublier de mettre de la colle liquide dans tous les ports, puis d'enfermer la machine dans une pièce fermée à clef et de la détruire…
[^] # Re: Clavier et Souris
Posté par moulator . Évalué à 3.
Plaisanterie mise à part, le seul moyen de sécuriser une machine est effectivement de l'enfermer, sans quoi on ne peut empêcher quiconque de la rebooter avec un CD ou autre, et d'y faire des modifications (et le mot de passe du BIOS n'est pas une sécurité non plus : un tournevis, un reset de la NVRAM et hop).
# Authentification par clé ou changer le shell (rssh)
Posté par xenom . Évalué à 10.
Il y a la possibilité de n'autoriser que la connexion par clé en SSH, et ne pas définir de mot de passe pour les utilisateurs, qui ne pourront pas se connecter en console, et leur désactiver bien sur la possibilité de mettre un mot de passe.
Sinon tu peux changer le shell de chaque utilisateur pour un shell ne permettant que la connexion SSH, comme par exemple rssh.
Ces deux solutions permettent aussi de garder au moins un utilisateur qui peut se connecter en console en cas de problème.
# Merci
Posté par nold88 . Évalué à 1.
Merci pour vos conseil c'est exactement ce qu'il me fallait
# pam ?
Posté par O-ol . Évalué à 3.
Je me demande si on ne pourrait pas aussi faire quelque chose dans /etc/pam.d
[^] # Re: pam ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
C'est comme ça que je procéderais. Éditer les fichiers login et gdm3 ou lightdm pour en retirer l'inclusion de common-auth.
[^] # Re: pam ?
Posté par Chris K. . Évalué à 1.
Oui :). D'ailleurs PAM est fait pour gérer ce genre de problématiques c'est donc certainement la solution la plus propre.
Cela a aussi l'avantage de pouvoir continuer à autoriser root à se connecter localement en cas de soucis avec SSH, le réseau ou autre. Ou même un groupe d'utilisateurs précis en utilisant, par exemple, un module comme pam_access.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.