Como desativar comandos de terminal assustadores?

Question

Como você desativa os comandos de terminal assustadores?

Eu estava usando o SSH para acessar um servidor Ubuntu remoto sem acesso ao servidor físico. Eu pensei que eu estava digitando ' shutdown ' 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?

    

Answer 1

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

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

Em seguida, se você digitar o desligamento, receberá a seguinte mensagem:

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

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

Encerre sua sessão atual de ssh e faça login novamente ou use . ~/.bashrc para carregar / executar .bashrc. Talvez tente executar rm sem nenhum argumento para garantir que seu servidor não tenha desativado o carregamento automático de .bashrc em logins ou similares.

Observe que, se você estiver preocupado principalmente com o desligamento e o desligamento, pode considerar a possibilidade de instalar molly- guarda , 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 fazer logout ou sair.

    

Answer 2

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 use sudo para tudo . Entenda o que você está fazendo e entenda por que ele não exige 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 muitas informações úteis (como o nome do host), o que o torna muito simples de saber em qual host o comando será executado, e também torna mais fácil olhar para o seu histórico e localizar prompts - um shell raiz usa o prompt padrão.

Issoémaisadequadoparausarnaconta" seu ", mas se você está levando a segurança / administração de sistemas a sério, você não estará compartilhando senhas / contas, e você não será sentado em um shell raiz sem estar plenamente consciente.

Como as pessoas dizem repetidamente, e de novo e de novo " aliasing comandos para criar um ambiente seguro é uma má idéia ". Você vai se sentir confortável em seu ambiente seguro, digitando os comandos 'assustadores' onde você não deveria. Então, um dia, você mudará de emprego, ou entrará em uma nova máquina e, em seguida, explodirá " whoopsy, eu não quis, me desculpe " ...

    

Answer 3

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.

    

Answer 4

Eu aceitei uma resposta que eu gosto muito, no entanto, se alguém mais 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, 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!

    

Answer 5

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

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

Aqui está o que acontece no Ubuntu 12 se eu digitar shutdown , mesmo como um 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 planeja um desligamento por 60 segundos depois, e mesmo se você não for root - apenas uma conta feita com privilégios de administrador.

Culpe a Canonical.

    

Answer 6

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

Scripts de sistema usam caminho completo, então tal hack impede que eu pare um servidor remoto em vez de máquina local (um mau comportamento de Awesome WM), mas não tem outro efeito indireto, e eu ainda posso usá-los como / sbin / shutdown quando realmente for necessário.

    

Answer 7

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.

Existe também a sintaxe para dizer 'não é possível 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.

    

Answer 8

Para 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 excluir arquivos, há soluções como libtrash, que emula uma lixeira por meio de uma biblioteca LD_PRELOAD .

E você pode testar quais arquivos você está alterando / excluindo / ... com o programa talvez . Isso é muito legal ao testar algo.

    

Answer 9

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 sobre o qual você está. enviar. Está tudo bem? Tem certeza?

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