Comment désactiver les commandes de terminal effrayantes?
Comment désactiver les commandes de terminal effrayantes?
J'utilisais SSH pour accéder à un serveur Ubuntu distant sans accéder au serveur physique. Je pensais taper 'shutdown' sur le serveur NoSQL fonctionnant sous le système d'exploitation Ubuntu, mais en réalité, j'ai dit au serveur Ubuntu de s'arrêter. Ensuite, je devais dire à l'administrateur du serveur ce que je faisais pour qu'il puisse démarrer le serveur physique pour moi. C'était gênant!
Comment puis-je empêcher que cela se reproduise?
La réponse standard est "ne vous connectez pas en tant que root". Toutes les commandes exécutées en tant que root sont effrayantes. Si ce n'est pas une option, vous pouvez ajouter des commandes d'alias dans votre .bashrc pour désactiver les commandes que vous trouvez particulièrement effrayantes. Par exemple:
for scary in shutdown halt reboot rm
do
alias $scary="echo If you really want to do that, type: `which $scary`"
done
Ensuite, si vous tapez shutdown, vous obtenez le message suivant:
If you really want to do that, type: /sbin/shutdown
( Assurez-vous que votre .bashrc a été chargé en premier, avant d'essayer ceci sur un serveur de production)
Quitter votre session actuelle ssh et vous reconnecter, ou utiliser . ~/.bashrc devrait charger/exécuter .bashrc. Essayez peut-être d’exécuter rm sans aucun argument pour vous assurer que votre serveur n’a pas été désactivé en chargeant automatiquement .bashrc lors de connexions ou similaire.
Notez que si vous êtes principalement concerné par les arrêts et les arrêts, vous pouvez envisager d’installer molly-guard , ce qui vous obligera à taper le nom d’hôte avant d’arrêter la machine. Ceci est plus utile si vous arrêtez régulièrement des systèmes d’exploitation complets sur la ligne de commande, mais souhaitez vous assurer d’arrêter le bon.
Vous pouvez également tester essayez ceci avec une commande moins effrayante telle que logout ou exit.
Sudo existe pour une raison - utilisez-la. Lorsque votre commande (dans ce cas, une interface de ligne de commande interactive) est terminée, vous êtes redirigé vers votre shell au niveau utilisateur, et non un shell racine. Il y a très peu de raisons valables d'être dans un shell racine. (Je suis surpris que ce ne soit pas déjà une réponse ...)
Cela dit, ne soyez pas un muppet qui utilise Sudo pour everything . Comprenez ce que vous faites et pourquoi vous n’avez pas besoin des privilèges root.
De plus, vous pouvez différencier votre invite pour les shells root/utilisateur. Cela rend également plus évident que vous êtes de retour à l'invite du shell et non pas "un autre CLI". Le mien est très coloré et contient de nombreuses informations utiles (telles que le nom d’hôte), ce qui rend très très simple la connaissance de l’hôte sur lequel la commande sera exécutée, et facilite également la consultation de votre historique et votre localisation. invites - un shell racine utilise l'invite par défaut.
Ceci est plus approprié pour utiliser sur "votre" compte, mais si vous prenez la sécurité/sysadminning au sérieux, alors vous ne partagerez pas les mots de passe/comptes, et vous ne serez pas assis dans un shell racine sans être pleinement conscient.
Comme les gens l'ont répété maintes et maintes fois, "aliasing, commandes pour créer un environnement sûr, est une mauvaise idée". Vous allez être à l'aise dans votre environnement sécurisé, en tapant ces commandes «effrayantes» là où vous ne devriez pas. Puis un jour, vous changerez de travail ou vous vous connecterez à une nouvelle machine, puis vous ferez exploser "whoopsy, je ne voulais pas, je suis désolé" ...
Le paquet 'molly-guard' (au moins sur les systèmes dérivés de Debian) installera un wrapper autour des arrêts, des arrêts, des mises hors tension et des redémarrages. S'il détecte que le terminal est distant, il demandera le nom de l'hôte. Si cela ne correspond pas, la commande est annulée.
J'ai accepté une réponse qui me plaît beaucoup, cependant, si quelqu'un d'autre lit et veut une réponse plus simple, voici la mienne.
Recherchez le fichier .bashrc et mettez-le comme dernière ligne:
alias shutdown=notforuse
Ensuite, lorsque vous tapez shutdown, vous obtenez quelque chose comme ~bash: notforuse is not a command
C'est peut-être idiot mais c'est simple et ça marche. J'apprécie les réponses avec de meilleures façons de le faire cependant!
Vous êtes peut-être victime d’une nouvelle stupidité d’Ubuntu.
Auparavant, Ubuntu disposait de la commande shutdown classique, classique, qui prend un argument temporel obligatoire.
Voici ce qui se passe sur Ubuntu 12 si je tape shutdown, même en tant qu'utilisateur ordinaire:
$ shutdown
shutdown: time expected
Try `shutdown --help' for more information.
Ensuite
$ shutdown +100
shutdown: need to be root.
Maintenant, voici Ubuntu 16.10. Je ne suis pas root:
$ date ; /sbin/shutdown
Fri Jun 23 16:00:16 PDT 2017
Shutdown scheduled for Fri 2017-06-23 16:01:16 PDT, use 'shutdown -c' to cancel.
En l'absence d'argument, il planifie un arrêt 60 secondes plus tard, et même si vous n'êtes pas root, vous ne disposez que d'un compte créé avec les privilèges d'administrateur.
Blâme canonique.
Pour shutdown (reboot, halt et connexe): J'ai une copie avec demandez-moi si je suis vraiment sûr (et ça ne fait rien quand même). Je stocke ces scripts dans /usr/local/sbin. Sur Debian, cela a la priorité autre /sbin (c'est le premier répertoire de PATH).
Les scripts système utilisent un chemin d'accès complet, de sorte que hack m'empêche d'arrêter un serveur distant au lieu d'une machine locale (un mauvais comportement de Awesome WM), mais n'a pas d'autre effet indirect, et je peux toujours les utiliser comme/sbin/shutdown quand vraiment nécessaire.
Le fichier Sudoers autorise un niveau de granularité bien plus fin que celui que * * est autorisé à utiliser Sudo '*. Vous pouvez notamment utiliser des alias de commande pour créer des listes blanches de groupes de commandes auxquelles un utilisateur ou un groupe donné est soumis. J'ai travaillé avec des serveurs distants limités à l'accès ssh et autorisés à utiliser Sudo sans mot de passe (nous avions besoin de clés ssh protégées par mot de passe). Il y a de bonnes raisons à cela, mais cela présente des dangers. Nous avons donc utilisé des alias de commande pour permettre un accès illimité à ce qu'ils doivent faire (redémarrage de serveurs, etc.) sans leur accorder de privilèges.
Il existe également une syntaxe pour dire 'ne peut pas exécuter cette commande' . Cela peut être corrigé, donc cela ne devrait pas être utilisé comme une véritable mesure de sécurité, mais cela fonctionnerait pour le scénario que vous avez décrit.
Man Sudoers a de bons exemples sur la façon de tout mettre en place.
Bien sûr, cela nécessite d’utiliser Sudo, mais cela devrait aller de soi.
Pour l'arrêt, il y a molly-guard. Il vous suffit de l'installer et lorsque vous essayez de vous arrêter via ssh, il vous demande de taper le nom d'hôte.
Pour supprimer des fichiers, il existe des solutions telles que libtrash, qui émule une corbeille via une bibliothèque LD_PRELOAD.
Et vous pouvez tester quels fichiers vous modifiez/supprimez/... avec le programme peut-être . C'est plutôt cool quand on teste quelque chose.