Question Comment désactiver les commandes effrayantes du terminal?


Comment désactiver les commandes effrayantes du terminal?

J'utilisais SSH pour accéder à un serveur Ubuntu distant sans accès au serveur physique. Je pensais que je tapais 'shutdown'sur le serveur NoSQL fonctionnant sur le système d'exploitation Ubuntu, mais en fait j'ai dit au serveur Ubuntu de s'arrêter. Ensuite, j'ai dû dire à l'administrateur du serveur ce que je faisais pour qu'il puisse démarrer le serveur physique pour moi. C'était embarrassant!

Comment puis-je empêcher que cela se reproduise?


82
2018-06-18 14:52


origine


Cela a été discuté en longueur, généralement en relation avec rm qui a des effets secondaires pires que shutdown. Ligne du bas: il n'y a aucun moyen d'empêcher que de mauvaises choses ne se produisent si vous continuez à exécuter des commandes aléatoires en tant que root. - Dmitry Grigoryev
Comme d’autres personnes l’ont noté en ce qui concerne l’aliasing, cela peut inciter les gens à «prendre l'habitude de faire fonctionner une commande de manière non standard». Donc, est-ce que cela semble mauvais pour quelqu'un d'autre que le serveur idiot NoSQL utilise cette commande? - bmb
Le serveur NoSQL que j'utilisais est Redis. - MelodiousFires
Il suffit de ne pas travailler sous le compte root. - alk
J'ose dire que vous avez appris la leçon, vous n'aurez donc pas à ressentir le besoin de désactiver une commande à nouveau. J'ajoute également que vous ne faites pas preuve de bêtise contre GNU / Linux, vous ne faites que s'améliorer.


Réponses:


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 mettre des commandes 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 obtiendrez le message suivant:

If you really want to do that, type: /sbin/shutdown

(Assure-toi votre .bashrc a chargé en premier, avant d'essayer ceci sur un serveur de production)

Quitter votre courant ssh session et connexion à nouveau, ou en utilisant . ~/.bashrc devrait charger / exécuter .bashrc. Peut-être essayer de courir rm sans aucun argument pour vous assurer que votre serveur n'est pas désactivé automatiquement .bashrc sur les connexions ou similaires.

Notez que si vous êtes principalement concerné par l'arrêt et l'arrêt, vous pouvez envisager d'installer garde molly, ce qui vous fera taper le nom d'hôte avant d'éteindre la machine. Ceci est plus utile si vous fermez régulièrement des systèmes d’exploitation entiers sur la ligne de commande, mais que vous voulez vous assurer de fermer le bon système.

Vous pouvez également tester ceci avec une commande moins effrayante telle que la déconnexion ou la sortie.


204
2018-06-18 15:19



ne vous connectez pas en tant que root: cela ne vous aidera pas si vous confondez la machine dans laquelle vous vous êtes connecté. Je suggère changer l'invite à quelque chose qui vous donnerait un indice visuel. - isanae
Aliasing "effrayant" des commandes pour avoir un comportement "sûr" est, selon mon expérience, une mauvaise idée. Cela est dû au fait que les gens ont tendance à prendre l'habitude d'une commande qui fonctionne de manière non standard, ce qui peut les amener à faire des choses très regrettables lorsqu'ils sont sur un système vanille. La réponse simple est de faire très attention lorsque vous êtes connecté en tant que root. - TimGJ
@isanae Le raccourci que j'utilisais pour ouvrir un terminal avec ssh sur le serveur de production rendrait l'arrière-plan du terminal lumineux en rouge. Cela m'a fait faire attention. - Peter A. Schneider
source est un alias à . et n'est pas supporté par toutes les coques. - gronostaj
Notez également que tant que Debian et, par extension, Ubuntu ont la valeur par défaut ~/.bash_profile la source .bashrc, ce n'est pas un comportement standard et sur la plupart des systèmes, .bashrc n'est pas lu lors de la connexion via ssh, cela ne fera donc aucune différence. Il est de loin préférable d'ajouter les alias à ~/.profile ou ~/.bash_profile au lieu. - terdon


sudo existe pour une raison - utilisez-le. Lorsque votre commande (dans ce cas, une interface de ligne de commande interactive) est terminée, vous êtes renvoyé à votre shell de niveau utilisateur, pas à un shell racine. Il y a très peu de raisons valables d'être dans un shell root. (Je suis surpris que ce ne soit pas déjà une réponse ...)

Cela dit, ne soyez pas un fournisseur qui utilise sudo pour tout. Comprenez ce que vous faites et comprenez pourquoi il ne nécessite pas de privilèges root.


De plus, vous pouvez différencier votre invite pour les shells root / user. Cela rend également plus évident que vous êtes de retour à l'invite du shell et non "un autre CLI". Le mien est très coloré, et a beaucoup d'informations utiles (telles que le nom d'hôte), ce qui le rend très Il est simple de savoir sur quel hôte la commande s'exécutera, et il est également plus facile de parcourir l'historique et de localiser les invites - un shell racine utilise l'invite par défaut.

My PS1

Ceci est plus approprié à utiliser sur "votre"compte, mais si vous prenez au sérieux la sécurité / sysadminning, alors vous ne partagerez pas les mots de passe / comptes, et vous ne serez pas assis dans un shell root sans en avoir pleinement conscience.


Comme on l’a dit encore et encore, "aliaser les 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 allez changer de travail, ou vous connecter à une nouvelle machine, puis vous bouger"Whoopsy, je ne voulais pas dire, je suis désolé"...


73
2018-06-19 11:40



sudo c'est à vous de prendre le café. - ivan_pozdeev
N'aurait-il pas le même problème avec sudo shutdown? S'il l'exécute sur la mauvaise machine, ce sera toujours un désastre. - Barmar
@Barmar NoSQL comprend-il la commande sudo? - Taemyr
@Taemyr sudo est une commande shell, elle n’a rien à voir avec la base de données. - Barmar
@Barmar: En fait, je pense que l'OP voulait le saisir dans un programme NoSQL cmdline, pas dans bash. Donc, ils n'auraient pas tapé sudo shutdown, depuis que je suppose sudo n'est pas une commande NoSQL. Ne pas être dans un shell root aurait totalement résolu ce problème et était une très bonne idée. Donc, regarder attentivement l'invite avant d'exécuter des commandes importantes. - Peter Cordes


Le paquet «molly-guard» (au moins sur les systèmes dérivés de Debian) installera un wrapper autour de l'arrêt, de l'arrêt, de la mise sous tension et du redémarrage. S'il détecte que le terminal est distant, il vous demandera le nom de l'hôte. Si elle ne correspond pas, la commande est annulée.


44
2018-06-18 16:18



Qu'en est-il d'autres choses (sans doute plus effrayantes) comme rm -rf /? - marcellothearcane
@marcellothearcane set -u pourrait aider avec cela dans certains cas, comme lors de l'écriture rm -rf /$SOME_VARIABLE_WHICH_I_THOUGHT_EXISTS_BUT_DOESNT. - Alex Hall
@marcellothearcane Sur tout ce qui ressemble à un système Linux moderne, il faut --no-preserve-root que vous avez peu de chance de saisir par accident. - Michael Kjörling
qui est Molly, je me demande ... probablement le chat de quelqu'un. - the0ther
@ the0ther, un enfant de 2 ans, qui a déclenché le commutateur SCRAM sur une machine à dinosaures, deux fois dans la même journée. Ils étaient dans la pièce avec une couverture sur l’interrupteur. catb.org/jargon/html/M/molly-guard.html - CSM


J'ai accepté une réponse que j'aime 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 en dernière ligne:

alias shutdown=notforuse

Ensuite, lorsque vous tapez shutdown, vous obtenez quelque chose comme ~bash: notforuse is not a command

Cela 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!


4
2018-06-18 15:29



Hm, j'avais l'habitude de faire ça avec rm troller les gens - alias rm='echo "You can't use rm!" #' - MD XF
Je pense que c'est une mauvaise idée pour trois raisons. Premièrement, il y a de la confusion pour quiconque a un accès root à la machine. Deuxièmement, il vous dit que vous pouvez taper "shutdown" et appuyer sur enter, ce qui signifie que vous risquez de commettre la même erreur sur le prochain système auquel vous avez accès. Troisièmement, cela deviendra extrêmement déroutant si une commande valide est appelée notforuse Sur le chemin. - David Richerby
Je suis avec @DavidRicherby sur celui-ci. Pas une bonne idée. - Tico
Si vous voulez vraiment utiliser les alias, vous pouvez au moins mettre tous ces commande d'effarouchement alias dans un fichier, disons ~/.SaveMyReputation et ajouter comme dernière ligne de votre .bashrc une ligne comme [ -f ~/.SaveMyReputation ] && source ~/,SaveMyReputation. Vous voudrez éventuellement ajouter une ligne supplémentaire echo "#Scaring command protected shell, comment the last line of .bashrc and log again to have a full working shell" à l'intérieur de ce fichier. Au moins, vous pouvez apporter avec vous ce fichier d’alias sur une autre machine (il devrait être .bash_aliases, mais en cela "déconseillé" cas vaut mieux utiliser un autre nom). - Hastur
Si vous allez le faire, rendez-le moins compliqué en utilisant un nom comme alias shutdown=shutdown-disabled-by-an-alias. (Cela ne résout que le troisième problème le plus mineur signalé par @DavidRicherby.) Même si cela ne prendra probablement que 2 secondes, la prochaine personne notforuse is not a command à la course type -a shutdown et trouver l'alias, puis taper sudo \shutdown pour désactiver l'expansion des alias. (En supposant qu'ils avaient sudo alias à sudo='sudo ' il élargit donc les alias dans son premier argument). - Peter Cordes


Vous avez peut-être été victime d'une nouvelle stupidité d'Ubuntu.

Ubuntu avait l'habitude, classique shutdown commande qui prend un argument de temps obligatoire.

Voici ce qui se passe sur Ubuntu 12 si je tape shutdown, même en tant qu'utilisateur régulier:

$ shutdown
shutdown: time expected
Try `shutdown --help' for more information.

alors

$ 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.

Sans arguments, il programme un arrêt pour 60 secondes plus tard et même si vous n'êtes pas root, juste un compte avec des privilèges d'administrateur.

Blâme Canonical.


2
2018-06-23 22:54



/sbin/shutdown  est fourni par systemd-sysv paquet par défaut, ce n'est pas la bêtise d'Ubuntu, c'est systemd la bêtise, et cela ne vient pas d'Ubuntu, mais de Debian au moins, ce qui, à son tour, semble prendre l'ensemble systemd mouvement de Red Hat. En blâmant, blâmez la bonne entité - pas seulement celle que vous n'aimez pas. - Ruslan
@Ruslan Personne qui emballe cette merde dans leur distribution échappe au blâme de la stupidité. - Kaz


Pour shutdown (reboot, halt et liés): J'ai une copie avec me demander si je suis vraiment sûr (et il ne fait rien en tout cas). Je stocke ces scripts dans in /usr/local/sbin. Sur Debian, la priorité est autre /sbin (c'est le premier répertoire de PATH).

Les scripts système utilisent le chemin complet, donc pirater m'a empêché d'arrêter un serveur distant au lieu de la machine locale (un mauvais comportement de Impressionnant WM), mais n’a pas d’autres effets indirects, et je peux toujours les utiliser comme / sbin / shutdown lorsque cela est vraiment nécessaire.


1
2018-06-19 15:39



Ces hacks ne fonctionnent que si vous les appliquez à tous les ordinateurs auxquels vous vous connectez déjà, ce qui est souvent peu pratique, et vous ne le découvrirez pas avant qu'il ne soit trop tard: en tapant shutdown sur un système critique qui ne ne pas avoir votre hack. - jpaugh
@ jpaugh: oui, c'est un hack, et je l'utilise uniquement pour mes serveurs personnels, où je me suis souvent connecté, et les terminaux restent ouverts trop longtemps. [Remarque: j'utilise également des invites de couleur différentes pour mes ordinateurs personnels: root-remote, remote-user, local-root, local-user]. Pour les serveurs réels et les machines distantes, j'évite le root et je vais aussi peu que possible root, et bien sûr, sans oublier d'en sortir. J'utilise juste mes télécommandes comme "cloud" (avant le battage médiatique du cloud, donc manipulé à l'ancienne). - Giacomo Catenazzi


Le fichier Sudoers permet un niveau de granularité beaucoup plus fin que * * est autorisé à utiliser sudo '*, en particulier vous pouvez utiliser des alias de commandes pour créer des listes blanches de groupes de commandes auxquels un utilisateur ou un groupe particulier est limité. J'ai travaillé avec des serveurs distants limités à l'accès ssh et autorisé à 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 il comporte des dangers. Nous avons donc utilisé des alias de commandes pour autoriser un accès illimité aux tâches à effectuer (redémarrage des serveurs, etc.) sans leur accorder de privilèges.

Il y a aussi une syntaxe à dire 'ne peut pas exécuter cette commande'. Il peut être contourné, il ne devrait donc pas être utilisé comme une mesure de sécurité réelle, mais cela fonctionnerait pour le scénario que vous avez décrit.

Man sudoers a quelques bons exemples sur la façon de mettre tout cela en place.

Bien sûr, cela nécessite l'utilisation de sudo, mais cela devrait aller de soi.


1
2018-06-23 16:08





Pour la fermeture il y a molly-guard. Il vous suffit de l'installer et lorsque vous essayez d'arrêter via ssh, il vous demande de saisir le nom d'hôte.

Pour supprimer des fichiers, il existe des solutions telles que libtrash, qui émule une corbeille via un LD_PRELOAD bibliothèque.

Et vous pouvez tester quels fichiers vous modifiez / supprimez / ... avec le peut être programme. C'est plutôt cool de tester quelque chose.


0
2018-06-23 19:18



Ce maybe La conception semble briser quelque chose: la suppression de certains appels système avec no-ops va faire planter tout programme non trivial qui repose sur ces appels système pour réussir. - Dmitry Grigoryev


Essayez ceci: lorsque vous êtes sur un shell distant, chaque fois que vous êtes sur le point de taper la touche "retour", arrêtez-vous pendant 5 secondes, en plaçant votre doigt sur la touche "return" et relisez la commande que vous êtes sur le point d'envoyer. Est-ce que c'est bon? Êtes-vous sûr?

Cela semble dur, mais d'un autre côté, nous ne devrions pas passer beaucoup de temps sur des coques distantes. Nous devrions trouver tous les moyens d’automatiser notre travail de maintenance afin que nous ayons rarement, voire jamais, besoin de nous connecter à un serveur distant.


-2
2018-06-24 17:07



J'ai essayé ça, pas de travail. Je suis entré shutdown, arrêté pendant 5 secondes, relire la commande (à haute voix!) et je suis sûr que c'était correct. Puis appuyez sur Entrée et la commande vient d'être exécutée. Donc, cela n'a pas empêché les commandes effrayantes, j'ai peur. Je vais essayer avec cette chose en vol stationnaire, peut-être que la distance était trop petite / grande. - wojciech_rak