Come disabilitare i comandi del terminale spaventoso?


82

Come si disabilitano i comandi del terminale spaventoso?

Stavo usando SSH per accedere a un server Ubuntu remoto senza accesso al server fisico. Pensavo di scrivere ' shutdown' nel server NoSQL in esecuzione sul sistema operativo Ubuntu, ma in realtà ho detto al server Ubuntu di spegnersi. Quindi ho dovuto dire all'amministratore del server cosa ho fatto in modo che potesse avviare il server fisico per me. È stato imbarazzante!

Come posso evitare che ciò accada di nuovo?


100
Questo è stato discusso a lungo, di solito in relazione al rmquale ha effetti collaterali peggiori di shutdown. In conclusione: qui non c'è modo di impedire che accadano cose brutte se si continuano a eseguire comandi casuali come root.
Dmitry Grigoryev,

5
Come altre persone hanno notato per quanto riguarda l'aliasing, farlo può far sì che le persone "prendano l'abitudine di un comando che funzioni in modo non standard". Quindi sembra male a chiunque altro che il server NoSQL sciocco usi questo comando?
bmb,

Il server NoSQL che stavo usando è Redis.
MelodiousFires

60
Basta non funzionare con l'account di root.
alk il

12
Oserei dire che hai imparato la lezione, quindi non dovrai sentire di nuovo la necessità di disabilitare alcun comando. Aggiungerei anche tu GNU / Linux non infallibile, stai solo meglio del matto.

Risposte:


204

La risposta standard è "non accedere come root". Tutti i comandi eseguiti come root sono spaventosi. Se questa non è un'opzione, potresti mettere alcuni comandi alias nel tuo .bashrcper disabilitare i comandi che trovi particolarmente spaventosi. Per esempio:

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

Quindi, se si digita shutdown verrà visualizzato il seguente messaggio:

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

( Assicurati che il tuo .bashrcè stato caricato prima, prima di provare questo su un server di produzione)

Uscire dalla sshsessione corrente e accedere nuovamente o utilizzare . ~/.bashrcdovrebbe caricare / eseguire .bashrc. Forse prova a eseguire rmsenza argomenti per assicurarti che il tuo server non abbia disabilitato il caricamento automatico .bashrcagli accessi o simili.

Si noti che se si è principalmente interessati all'arresto e all'arresto, è possibile prendere in considerazione l'installazione di molly-guard , che ti farà digitare il nome host prima di spegnere la macchina. Questo è più utile se spegni regolarmente interi sistemi operativi dalla riga di comando, ma vuoi assicurarti di chiudere quello giusto.

Puoi anche provare questo con un comando meno spaventoso come logout o exit.


70
non effettuare il login come root : questo non aiuta se si confonde la macchina a cui si è effettuato l'accesso. Suggerirei di cambiare il prompt in qualcosa che ti darebbe un segnale visivo.
Isanae,

145
Alias ​​comandi "spaventosi" per avere un comportamento "sicuro" è, nella mia esperienza, una cattiva idea. Questo perché le persone tendono ad abituarsi a un comando che funziona in modo non standard, il che può far loro fare alcune cose deplorevoli quando si trovano su un sistema vanilla. La semplice risposta è quella di procedere con molta attenzione quando si accede come root.
TimGJ,

22
@isanae La scorciatoia che ho usato per aprire un terminale con ssh sul server di produzione avrebbe reso il terminale in rosso chiaro. Questo mi ha fatto prestare attenzione.
Peter - Ripristina Monica il

6
sourceè un alias .e non è supportato da tutte le shell.
gronostaj,

4
Si noti inoltre che mentre Debian e, per estensione, Ubuntu hanno la ~/.bash_profilefonte defaullt .bashrc, che non è un comportamento standard e sulla maggior parte dei sistemi, .bashrcnon viene letta quando si accede tramite ssh, quindi questo non farà differenza. È molto meglio aggiungere gli alias ~/.profileo ~/.bash_profileinvece.
terdon,

73

sudoesiste per un motivo: usalo. Al termine del comando (in questo caso una CLI interattiva), viene eseguito il dump alla shell a livello di utente, non a una shell di root. Ci sono pochissime ragioni degne di essere in una shell di root. (Sono sorpreso che questa non sia già una risposta ...)

Detto questo, non essere un muppet che usa sudoper tutto . Comprendi cosa stai facendo e capisci perché richiede / non richiede i privilegi di root.


Inoltre, è possibile differenziare la richiesta di shell root / utente. Questo rende anche più ovvio che sei tornato al prompt della shell e non " qualche altra CLI ". Il mio è molto colorato e ha molte informazioni utili (come il nome host), il che rende molto semplice sapere su quale host verrà eseguito il comando, e rende anche più facile guardare indietro nella cronologia e individuare i prompt - una radice shell utilizza il prompt predefinito.

La mia PS1

Questo è più adatto da usare sul " tuo " account, ma se stai prendendo sul serio sicurezza / sysadminning, allora non condividerai password / account e non sarai seduto in una shell di root senza esserne pienamente consapevole.


Come le persone hanno detto più volte, e ancora e ancora " aliasing i comandi per creare un ambiente sicuro è una cattiva idea ". Ti sentirai a tuo agio nel tuo ambiente sicuro, digitando quei comandi 'spaventosi' dove non dovresti. Quindi un giorno cambierai lavoro o effettuerai il login su una nuova macchina, e poi boom " whoopsy, non volevo, mi dispiace " ...



2
Non avrebbe lo stesso problema con sudo shutdown? Se lo esegue sulla macchina sbagliata, sarà comunque un disastro.
Barmar,

2
@Barmar NoSQL comprende il comando sudo?
Taemyr,

2
@Taemyr sudoè un comando shell, non ha nulla a che fare con il database.
Barmar,

4
@Barmar: In realtà penso che l'OP abbia significato digitarlo in un programma cmdline NoSQL, non in bash. Quindi non avrebbero digitato sudo shutdown, dato che presumo sudonon sia un comando NoSQL. Non essere in una shell di root avrebbe risolto completamente quel problema ed sarebbe stata un'ottima idea. Quindi esaminerei attentamente il prompt prima di eseguire comandi importanti.
Peter Cordes,

44

Il pacchetto 'molly-guard' (almeno sui sistemi derivati ​​Debian) installerà un wrapper attorno a shutdown, halt, poweroff e reboot. Se rileva che il terminale è remoto, richiederà il nome dell'host. Se non corrisponde, il comando viene annullato.


4
che dire di altre cose (probabilmente più spaventose) come rm -rf /?
marcellothearcane,

9
@marcellothearcane set -upotrebbe aiutare in alcuni casi, come quando si scrive rm -rf /$SOME_VARIABLE_WHICH_I_THOUGHT_EXISTS_BUT_DOESNT.
Alex Hall,

4
@marcellothearcane Su qualsiasi cosa che assomigli a un moderno sistema Linux, ha bisogno --no-preserve-rootche difficilmente si digiti per caso.
un CVn del

3
chi è Molly, mi chiedo ... probabilmente il gatto di qualcuno.
altro

7
@ the0ther, un bambino di 2 anni, che ha attivato l'interruttore SCRAM su una macchina per dinosauri, due volte nello stesso giorno. La gente nella stanza ha sistemato una copertura sull'interruttore. catb.org/jargon/html/M/molly-guard.html
CSM

4

Ho accettato una risposta che mi piace molto, tuttavia, se qualcun altro sta leggendo e desidera una risposta più semplice, ecco la mia.

Trova il file .bashrc e inseriscilo come ultima riga:

alias shutdown=notforuse

Quindi quando digiti shutdown ottieni qualcosa di simile ~bash: notforuse is not a command

Questo potrebbe essere sciocco ma è semplice e funziona. Apprezzo comunque le risposte con modi migliori per farlo!


4
Ehm, lo facevo rmper trollare le persone -alias rm='echo "You can't use rm!" #'
MD XF,

52
Penso che questa sia una cattiva idea, per tre motivi. Innanzitutto, è fonte di confusione per chiunque abbia accesso root alla macchina. In secondo luogo, ti insegna che è OK digitare "shutdown" e premere invio, il che significa che probabilmente farai lo stesso errore sul prossimo sistema a cui hai accesso root. Terzo, questo diventerà estremamente confuso se ci sarà mai un comando valido chiamato notforusesul percorso.
David Richerby,

5
Sono con @DavidRicherby su questo. Non è una buona idea.
Tico,

Se vuoi davvero usare gli alias, puoi almeno mettere tutti quegli alias di comando spaventosi in un file, diciamo ~/.SaveMyReputatione aggiungiamo come ultima riga della tua .bashrclinea come [ -f ~/.SaveMyReputation ] && source ~/,SaveMyReputation. Potresti eventualmente aggiungere una riga aggiuntiva echo "#Scaring command protected shell, comment the last line of .bashrc and log again to have a full working shell"all'interno di quel file. Almeno potresti portare con te questo file alias su un'altra macchina (dovrebbe essere .bash_aliases, ma in questo caso "deprecato" è meglio usare un altro nome).
Hastur,

Se hai intenzione di farlo, rendilo meno confuso usando un nome come alias shutdown=shutdown-disabled-by-an-alias. (Questo risolve solo il terzo e più piccolo problema che @DavidRicherby ha sottolineato.) Anche se probabilmente ci vorranno solo 2 secondi perché la persona successiva passi dal vedere notforuse is not a commandalla corsa type -a shutdowne trovare l'alias, quindi digitando sudo \shutdownper disabilitare l'espansione dell'alias. (Supponendo che si fossero sudoaliasati in sudo='sudo 'modo da espandere gli alias nel suo primo argomento).
Peter Cordes,

1

Per shutdown( reboot, halte correlati): Ho una copia con mi chiede se io sono davvero sicuro (e non fa nulla comunque). Conservo tali script in /usr/local/sbin. Su Debian questo ha altra priorità /sbin(è la prima directory di PATH).

Gli script di sistema usano un percorso completo, quindi un tale hack mi impedisce di arrestare un server remoto invece di una macchina locale (un comportamento scorretto da Awesome WM), ma non ha altri effetti indiretti, e posso ancora usarli come / sbin / shutdown quando veramente necessario .


Tali hack funzionano solo se li applichi a tutti i computer a cui accedi mai ... questo è spesso poco pratico e non lo scoprirai fino a quando non è troppo tardi: digitando shutdownsu un sistema critico che non ha il tuo hack.
jpaugh il

@jpaugh: sì, è un trucco, e lo uso solo per i miei server personali, dove spesso ho effettuato l'accesso e i terminali rimangono aperti per troppo tempo. [Nota: utilizzo anche prompt di colori diversi per i miei computer personali: root remoto, utente remoto, root locale, utente locale]. Per server reali e macchine remote, evito root e vado root il meno possibile, e di sicuro, senza dimenticare di uscire da loro. Sto solo usando i miei telecomandi come "cloud" (prima dell'hype cloud, quindi gestito alla vecchia maniera).
Giacomo Catenazzi,

1

Il file Sudoers consente un livello di granularità molto più fine rispetto a * * è consentito utilizzare sudo '*, in particolare è possibile utilizzare gli alias di comando per creare liste bianche di gruppi di comandi a cui un determinato utente o gruppo è limitato. Ho lavorato con server remoti che erano limitati all'accesso ssh e consentivano sudo senza password (avevamo bisogno di chiavi ssh protette da password). Ci sono alcuni buoni motivi per farlo, ma presenta dei pericoli, quindi abbiamo usato gli alias di comando per consentire l'accesso illimitato alle cose che devono fare (riavviare i server ecc.) Senza concedere loro privilegi per le cose che non avevano.

C'è anche una sintassi per dire "impossibile eseguire questo comando" . Può essere aggirato, quindi non dovrebbe essere usato come una vera misura di sicurezza ma funzionerebbe per lo scenario che hai descritto.

Man sudoers ha alcuni buoni esempi su come impostare tutto questo.

Naturalmente questo richiede l'uso di sudo, ma ciò dovrebbe essere ovvio.


1

Potresti essere caduto vittima di una nuova stupidità di Ubuntu.

Ubuntu aveva il normale shutdowncomando classico che richiede un argomento temporale obbligatorio.

Ecco cosa succede su Ubuntu 12 se scrivo shutdown, anche come utente normale:

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

Poi

$ shutdown +100
shutdown: need to be root.

Ora, ecco Ubuntu 16.10. Non sono 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.

Senza argomenti, pianifica un arresto per 60 secondi dopo, e anche se non sei root, solo un account creato con privilegi di amministratore.

Colpa di Canonical.


6
/sbin/shutdown è fornito dal systemd-sysvpacchetto di default, quindi non è stupidità di Ubuntu, è systemdstupidità, e non proviene da Ubuntu, ma almeno da Debian, che, a sua volta, sembra prendere l'intero systemdmovimento da Red Hat. Quando dai la colpa, dai la colpa all'entità corretta, non solo a quella che non ti piace.
Ruslan,

1
@Ruslan Nessuno che impacchetta questa merda nella loro distribuzione sfugge alla colpa della stupidità.
Kaz,

0

Per lo spegnimento c'è Molly-Guard. Devi solo installarlo e quando provi a chiudere via ssh, ti chiede di digitare il nome host.

Per eliminare file ci sono soluzioni come libtrash, che emula un cestino tramite una LD_PRELOADlibreria.

E puoi testare quali file stai modificando / eliminando / ... con il programma maybe . È abbastanza bello quando testare qualcosa.


1
Questa maybecosa sembra essere rotta dal design: stubbing alcune syscalls con no-op sta andando in crash qualsiasi programma non banale che si basa su queste syscalls per avere successo.
Dmitry Grigoryev il

-2

Prova questo: quando sei su una shell remota, ogni volta che stai per digitare il tasto "Invio", fermati per 5 secondi, con il dito che passa sul tasto "Invio" e rileggi il comando che stai per inviare. Va bene? Sei sicuro?

Sembra difficile, ma d'altra parte non dovremmo passare molto tempo su shell remote. Dovremmo trovare tutti i modi per automatizzare il nostro lavoro di manutenzione in modo che raramente, se mai, sia necessario accedere a un server remoto.


Ho provato quello, non funziona. Sono entrato shutdown, mi sono fermato per 5 secondi, ho riletto il comando (ad alta voce!) E sono sicuro che fosse corretto. Quindi premi invio e il comando è appena stato eseguito. Quindi questo non ha disabilitato i comandi spaventosi, temo. Proverò con questa cosa in bilico, forse la distanza era troppo piccola / grande.
wojciech_rak,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.