Questão Como desativar comandos de terminal assustadores?


Como você desativa comandos de terminal assustadores?

Eu estava usando o SSH para acessar um servidor Ubuntu remoto sem acesso ao servidor físico. Eu pensei que estava digitandoshutdown'no servidor NoSQL rodando no sistema operacional Ubuntu, mas na verdade eu disse ao servidor Ubuntu para desligar. Então eu tive que dizer ao administrador do servidor o que eu fiz para que ele pudesse iniciar o servidor físico para mim. Isso foi embaraçoso!

Como posso evitar que isso aconteça novamente?


82


origem


Isso tem sido discutido em comprimentos, geralmente com relação a rm que tem efeitos colaterais piores do que shutdown. Conclusão: não é possível impedir que coisas ruins aconteçam se você continuar executando comandos aleatórios como root. - Dmitry Grigoryev
Como outras pessoas notaram a respeito do aliasing, isso pode fazer com que as pessoas "adquiram o hábito de um comando trabalhando de maneira não padronizada". Então, parece ruim para qualquer outra pessoa que o bobo servidor NoSQL use esse comando? - bmb
O servidor NoSQL que eu estava usando é o Redis. - MelodiousFires
Apenas não trabalhe sob a conta root. - alk
Eu ouso dizer que você aprendeu a lição, então não terá que sentir a necessidade de desabilitar qualquer comando novamente. Eu também adicionaria que você não é um GNU / Linux à prova de idiotas, você só fica melhor que o bobo.


Respostas:


A resposta padrão é "não faça login como root". Todos os comandos executados como root são assustadores. Se isso não é uma opção você pode colocar alguns comandos de alias em seu .bashrc desabilitar comandos que você acha especialmente assustador. Por exemplo:

for scary in shutdown halt  reboot rm
do
    alias $scary="echo If you really want to do that, type: `which $scary`"
done

Então, se você digitar shutdown, receberá a seguinte mensagem:

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

(Certificar-se de que seu .bashrc foi carregado primeiro, antes de tentar isso em um servidor de produção)

Sair do seu atual ssh sessão e login novamente, ou usando . ~/.bashrc deve carregar / executar .bashrc. Talvez tente correr rm sem argumentos para garantir que seu servidor não tenha sido desativado automaticamente .bashrc em logins ou similar.

Observe que, se você estiver preocupado principalmente com a parada e o desligamento, considere instalar guarda molly, o que fará com que você digite o nome do host antes de desligar a máquina. Isso é mais útil se você desligar regularmente os sistemas operacionais inteiros na linha de comando, mas quiser ter certeza de que está desligando o sistema certo.

Você também pode testar isso com um comando menos assustador, como logout ou exit.


204



não faça login como root: isso não ajudará se você estiver confundindo a máquina na qual você está conectado. Eu sugeriria alterando o prompt para algo que lhe daria uma sugestão visual. - isanae
Aliasing "assustador" comandos para ter um comportamento "seguro" é, na minha experiência, uma má idéia. Isso ocorre porque as pessoas tendem a adquirir o hábito de um comando que funciona de maneira não padronizada, o que pode fazê-las fazer algumas coisas muito lamentáveis ​​quando estão em um sistema de baunilha. Resposta simples é pisar com muito cuidado quando logado como root. - TimGJ
@ isanae O atalho que usei para abrir um terminal com ssh para o servidor de produção tornaria a luz de fundo do terminal vermelha. Isso me fez prestar atenção. - Peter A. Schneider
source é um alias para . e não é suportado por todos os shells. - gronostaj
Note também que enquanto o Debian e, por extensão, o Ubuntu tem o ~/.bash_profile fonte .bashrc, isso não é um comportamento padrão e na maioria dos sistemas, .bashrc não é lido ao fazer o login via ssh, então isso não fará diferença lá. É muito melhor adicionar os aliases para ~/.profile ou ~/.bash_profile em vez de. - terdon


sudo existe por um motivo - use-o. Quando seu comando (neste caso, uma CLI interativa) estiver concluído, você será devolvido ao seu shell de nível de usuário, não a um shell de root. Existem muito poucas razões para estar em um shell de root. (Estou surpreso que isso já não seja uma resposta ...)

Dito isto, não seja um muppet que usa sudo para tudo. Entenda o que você está fazendo e entenda por que ele não requer privilégios de root.


Além disso, você pode diferenciar seu prompt para shells root / user. Isso também torna mais óbvio que você está de volta ao prompt do shell e não "algum outro CLI". O meu é muito colorido, e tem muita informação útil (como o nome do host), o que torna muito É simples saber em que host o comando será executado, e também facilita a análise de seu histórico e a localização de prompts - um shell raiz usa o prompt padrão.

My PS1

Isso é mais adequado para usar em "seu"conta, mas se você está levando a segurança / administração de sistemas a sério, então você não estará compartilhando senhas / contas, e você não estará sentado em um shell de root sem estar plenamente ciente.


Como as pessoas dizem, e de novo e de novo "aliasing comandos para criar um ambiente seguro é uma má ideia". Você ficará confortável em seu ambiente seguro, digitando os comandos 'assustadores' onde não deveria. Então, um dia, você mudará de emprego, ou acessará uma nova máquina e, em seguida,"whoopsy, eu não queria, me desculpe"...


73



sudo é a sua vez de pegar o café. - ivan_pozdeev
Ele não teria o mesmo problema com sudo shutdown? Se ele o executar na máquina errada, ainda assim será um desastre. - Barmar
@Barmar O NoSQL entende o comando sudo? - Taemyr
@Taemyr sudo é um comando shell, não tem nada a ver com o banco de dados. - Barmar
@ Barmar: Na verdade, acho que o OP pretendia digitá-lo em um programa cmdline NoSQL, não em bash. Então eles não teriam digitado sudo shutdown, desde que eu assumo sudo não é um comando NoSQL. Não estar em um shell de raiz teria resolvido totalmente esse problema e sido uma boa ideia. Então, seria necessário observar atentamente o prompt antes de executar comandos importantes. - Peter Cordes


O pacote 'molly-guard' (pelo menos em sistemas derivados do Debian) instalará um wrapper em torno de shutdown, halt, poweroff e reboot. Se detectar que o terminal é remoto, ele solicitará o nome do host. Se não corresponder, o comando será cancelado.


44



e outras coisas (possivelmente mais assustadoras) como rm -rf /? - marcellothearcane
@marcellothearcane set -u pode ajudar com isso em alguns casos, como ao escrever rm -rf /$SOME_VARIABLE_WHICH_I_THOUGHT_EXISTS_BUT_DOESNT. - Alex Hall
@marcellothearcane Em qualquer coisa que se assemelhe a um sistema Linux moderno, isso precisa --no-preserve-root que é improvável que você digite por acidente. - Michael Kjörling
quem é Molly, eu me pergunto ... provavelmente o gato de alguém. - the0ther
@ the0ther, uma criança de 2 anos, que acionou o interruptor SCRAM em uma máquina de dinossauro, duas vezes no mesmo dia. As pessoas na sala colocaram uma capa no interruptor. catb.org/jargon/html/M/molly-guard.html - CSM


Eu aceitei uma resposta que eu gosto muito, no entanto, se alguém está lendo e quer uma resposta mais simples, aqui está a minha.

Encontre o arquivo .bashrc e coloque como a última linha:

alias shutdown=notforuse

Então, quando você digita o desligamento, você recebe algo como ~bash: notforuse is not a command

Isso pode ser bobo, mas é simples e funciona. Eu aprecio respostas com melhores maneiras de fazer isso no entanto!


4



Hm, eu costumava fazer isso com rm troll pessoas - alias rm='echo "You can't use rm!" #' - MD XF
Eu acho que esta é uma má ideia, por três razões. Primeiro, é confuso para qualquer outra pessoa que tenha acesso root à máquina. Em segundo lugar, ele treina para você que não há problema em digitar "shutdown" e pressionar enter, o que significa que você provavelmente cometerá o mesmo erro no próximo sistema em que tiver acesso root. Em terceiro lugar, isso se tornará extremamente confuso se houver um comando válido chamado notforuse no caminho. - David Richerby
Eu estou com @DavidRicherby neste. Não é uma boa ideia. - Tico
Se você realmente quiser usar os aliases, você pode pelo menos colocar todos aqueles comando de assustar aliases em um arquivo, digamos ~/.SaveMyReputation e adicione como última linha do seu .bashrc uma linha como [ -f ~/.SaveMyReputation ] && source ~/,SaveMyReputation. Você pode eventualmente adicionar uma linha extra echo "#Scaring command protected shell, comment the last line of .bashrc and log again to have a full working shell" dentro desse arquivo. Pelo menos você pode trazer esse arquivo de alias em outra máquina (deve ser .bash_aliases, mas neste "descontinuada" caso é melhor usar outro nome). - Hastur
Se você for fazer isso, torne-o menos confuso usando um nome como alias shutdown=shutdown-disabled-by-an-alias. (Isso apenas aborda o terceiro e menor problema que @DavidRicherby apontou.) Embora, provavelmente, leve apenas 2 segundos para a próxima pessoa deixar de ver notforuse is not a command correr type -a shutdown e encontrando o alias, depois digitando sudo \shutdown para desabilitar a expansão de alias. (Assumindo que eles tinham sudo com alias para sudo='sudo ' então expande aliases em seu primeiro arg). - Peter Cordes


Você pode ter sido vítima de alguma nova estupidez do Ubuntu.

Ubuntu costumava ter o normal, clássico shutdown comando que leva um argumento de tempo obrigatório.

Aqui está o que acontece no Ubuntu 12 se eu digitar shutdown, mesmo como usuário comum:

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

Então

$ shutdown +100
shutdown: need to be root.

Agora, aqui está o Ubuntu 16.10. Eu não sou 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.

Sem argumentos, ele programa um desligamento por 60 segundos depois, e mesmo se você não for root - apenas uma conta feita com privilégios de administrador.

Culpa da Canonical.


2



/sbin/shutdown  É fornecido por systemd-sysv pacote por padrão, então não é a estupidez do Ubuntu, é systemd estupidez, e não vem do Ubuntu, mas pelo menos do Debian, que, por sua vez, parece levar o todo systemd movimento da Red Hat. Quando culpar, culpe a entidade correta - não apenas aquela que você não gosta. - Ruslan
@Ruslan Ninguém que empacote essa porcaria em sua distro escapa da culpa da estupidez. - Kaz


Para shutdown (reboot, halt e relacionado): Eu tenho uma cópia perguntando se tenho certeza (e não faz nada de qualquer maneira). Eu guardo esses scripts em /usr/local/sbin. No Debian isso tem prioridade /sbin (é o primeiro diretório do PATH).

Os scripts do sistema usam o caminho completo, portanto, hackear impedir-me de parar um servidor remoto em vez da máquina local (um mau comportamento Impressionante WM), mas não tem outro efeito indireto, e eu ainda posso usá-los como / sbin / shutdown quando realmente necessário.


1



Tais hacks só funcionam se você aplicá-los em todos os computadores em que você se conecta ... o que geralmente é pouco prático, e você não descobrirá até que seja tarde demais: digitando shutdown em um sistema crítico que faz não tenha seu hack. - jpaugh
@ jpaugh: Sim, é um hack, e eu o uso apenas para meus servidores pessoais, onde frequentemente faço login, e os terminais permanecem abertos por muito tempo. [Nota: eu também uso prompts de cores diferentes para minhas máquinas pessoais: raiz remota, usuário remoto, raiz local, usuário local]. Para servidores reais e máquinas remotas, evito root e zango o mínimo possível, e com certeza, sem me esquecer de sair deles. Só estou usando os meus controles remotos como "cloud" (antes do hype da nuvem, então é tratado da maneira antiga). - Giacomo Catenazzi


O arquivo Sudoers permite um nível muito mais fino de granularidade do que apenas * 'é permitido usar o sudo' *, em particular, você pode usar aliases de comando para criar listas brancas de grupos de comandos restritos a um usuário ou grupo específico. Eu trabalhei com servidores remotos que eram restritos ao acesso ssh e permitiam sudo sem senha (nós solicitamos chaves ssh protegidas por senha). Existem algumas boas razões para fazer isso, mas ele tem perigos, então usamos aliases de comando para permitir acesso irrestrito a coisas que eles precisam fazer (reiniciar servidores etc) sem conceder privilégios a eles.

Há também a sintaxe a dizer 'não pode executar este comando'. Ele pode ser contornado, por isso não deve ser usado como uma medida de segurança real, mas funcionaria para o cenário que você descreveu.

Man sudoers tem alguns bons exemplos de como configurar tudo isso.

Claro que isso requer o uso de sudo, mas isso não deveria ser dito.


1





Para o desligamento, há guarda-molly. Você só precisa instalá-lo e quando você tenta desligar através do ssh, ele pede para você digitar o nome do host.

Para a exclusão de arquivos, há soluções como libtrash, que emula uma lixeira por meio de LD_PRELOAD biblioteca.

E você pode testar quais arquivos você está alterando / excluindo / ... com o talvez programa. Isso é muito legal quando se testa alguma coisa.


0



este maybe a coisa parece ser quebrada pelo design: arrancar alguns syscalls com no-ops irá travar qualquer programa não-trivial que dependa do sucesso desses syscalls. - Dmitry Grigoryev


Tente isto: quando você estiver em um shell remoto, toda vez que estiver prestes a digitar a tecla "return", pare por 5 segundos, com o dedo pairando sobre a tecla "return", e releia o comando que você está prestes a enviar. Está tudo bem? Você tem certeza?

Isso parece duro, mas, por outro lado, não devemos gastar muito tempo em shells remotos. Devemos encontrar todas as formas de automatizar nosso trabalho de manutenção para que raramente, ou nunca, precisemos efetuar login em um servidor remoto.


-2



Tentei isso, não está funcionando. eu entrei shutdown, parou por 5 segundos, releu o comando (em voz alta!) e tenho certeza de que estava correto. Em seguida, aperte enter e o comando acabou de ser executado. Então, isso não desabilitou os comandos assustadores, receio. Vou tentar com esse dedo pairando coisa, talvez a distância era muito pequena / grande. - wojciech_rak