¿Cómo deshabilitar los comandos de terminal de miedo?

¿Cómo deshabilita los comandos de terminal de miedo?

Estaba usando SSH para acceder a un servidor Ubuntu remoto sin acceso al servidor físico. Pensé que estaba escribiendo ' shutdown' en el servidor NoSQL que se ejecuta en el sistema operativo Ubuntu, pero en realidad le dije al servidor Ubuntu que se apagara. Luego tuve que decirle al administrador del servidor lo que hice para que él pudiera iniciar el servidor físico por mí. ¡Eso fue embarazoso!

¿Cómo puedo evitar que esto vuelva a suceder?

La respuesta estándar es "no iniciar sesión como root". Todos los comandos ejecutados como root dan miedo. Si esa no es una opción, podría poner algunos comandos de alias en su .bashrcpara deshabilitar los comandos que encuentre especialmente atemorizantes. Por ejemplo:

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

Luego, si escribe shutdown, recibirá el siguiente mensaje:

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

( Asegúrese de que su .bashrcha cargado en primer lugar, antes de probar esto en un servidor de producción)

Salir de su sshsesión actual e iniciar sesión nuevamente, o usar . ~/.bashrcdebería cargar / ejecutar .bashrc. Quizás intente ejecutar rmsin ningún argumento para asegurarse de que su servidor no haya deshabilitado la carga automática .bashrcen inicios de sesión o similares.

Tenga en cuenta que si su principal preocupación es detener y apagar, podría considerar instalar molly-guard , lo que le hará escribir el nombre de host antes de apagar la máquina. Esto es más útil si apaga regularmente sistemas operativos completos en la línea de comandos, pero desea asegurarse de que está cerrando el correcto.

También puede probar probar esto con un comando menos aterrador como cerrar sesión o salir.

sudoexiste por una razón: úsala. Cuando finaliza su comando (en este caso, una CLI interactiva), regresa a su shell de nivel de usuario, no a un shell raíz. Hay muy pocas razones valiosas para estar en un shell de raíz. (Me sorprende que esto ya no sea una respuesta ...)

Habiendo dicho eso, no seas un muppet que usa sudopara todo . Comprenda lo que está haciendo y comprenda por qué requiere o no privilegios de root.

Además, puede diferenciar su solicitud de shells raíz / usuario. Esto también hace que sea más obvio que está de vuelta en el indicador de comandos de shell y no " alguna otra CLI ". El mío es muy colorido y tiene mucha información útil (como el nombre de host), lo que hace que sea muy simple saber en qué host se ejecutará el comando, y también hace que sea más fácil mirar hacia atrás a través de tu historial y localizar indicaciones, una raíz Shell utiliza el indicador predeterminado.

Esto es más adecuado para usar en " su " cuenta, pero si se está tomando en serio la seguridad / administración de sistemas, entonces no compartirá contraseñas / cuentas, y no estará sentado en un shell de raíz sin ser completamente consciente.

Como la gente ha dicho una y otra y otra vez, " alias de comandos para crear un entorno seguro es una mala idea ". Te sentirás cómodo en tu entorno seguro, escribiendo esos comandos 'aterradores' donde no deberías. Entonces, un día cambiarás de trabajo, o iniciarás sesión en una nueva máquina, y luego boom " whoopsy, no quise hacerlo, lo siento " ...

El paquete 'molly-guard' (al menos en los sistemas derivados de Debian) instalará un contenedor para apagar, detener, apagar y reiniciar. Si detecta que el terminal es remoto, solicitará el nombre del host. Si no coincide, el comando se cancela.

Acepté una respuesta que me gusta mucho, sin embargo, si alguien más está leyendo y quiere una respuesta más simple, aquí está la mía.

Encuentra el archivo .bashrc y ponlo como la última línea:

alias shutdown=notforuse

Luego, cuando escribes apagado, obtienes algo como ~bash: notforuse is not a command

Esto puede ser una tontería, pero es simple y funciona. Sin embargo, agradezco las respuestas con mejores formas de hacerlo.

Para shutdown( reboot, halty afines): Tengo una copia de preguntarme si estoy realmente seguro (y no hace nada de todos modos). Almaceno tales guiones en /usr/local/sbin. En Debian, esto tiene otra prioridad /sbin(es el primer directorio de PATH).

Las secuencias de comandos del sistema usan la ruta completa, por lo que este truco me impide detener un servidor remoto en lugar de una máquina local (un mal comportamiento de Awesome WM), pero no tiene otro efecto indirecto, y todavía puedo usarlos como / sbin / shutdown cuando realmente lo necesito .

El archivo Sudoers permite un nivel de granularidad mucho más fino que solo * 'puede usar sudo' *, en particular puede usar alias de comando para crear listas blancas de grupos de comandos a los que un usuario o grupo en particular está restringido. He trabajado con servidores remotos que estaban restringidos al acceso ssh y permitían sudo sin contraseña (requerimos claves ssh protegidas con contraseña). Hay algunas buenas razones para hacerlo, pero tiene peligros, por lo que utilizamos alias de comando para permitir el acceso sin restricciones a las cosas que tienen que hacer (reiniciar servidores, etc.) sin otorgarles privilegios por lo que no hicieron.

También hay una sintaxis para decir 'no se puede ejecutar este comando' . Se puede evitar, por lo que no se debe usar como una medida de seguridad real, pero funcionaría para el escenario que describió.

Man Sudoers tiene algunos buenos ejemplos sobre cómo configurar todo esto.

Por supuesto, esto requiere usar sudo, pero eso debería ser evidente.

Es posible que haya sido víctima de una nueva estupidez de Ubuntu.

Ubuntu solía tener el shutdowncomando normal y clásico que requiere un argumento de tiempo obligatorio.

Esto es lo que sucede en Ubuntu 12 si escribo shutdown, incluso como usuario habitual:

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

Entonces

$ shutdown +100
shutdown: need to be root.

Ahora, aquí está Ubuntu 16.10. No soy 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.

Sin argumentos, programa un apagado para 60 segundos más tarde, e incluso si no es root, solo una cuenta hecha con privilegios de administrador.

La culpa canónica.

Para el apagado hay molly-guard. Solo necesita instalarlo y cuando intenta cerrar a través de ssh, le pide que escriba el nombre de host.

Para eliminar archivos hay soluciones como libtrash, que emula una papelera a través de una LD_PRELOADbiblioteca.

Y puede probar qué archivos está cambiando / eliminando / ... con el programa quizás . Eso es genial cuando se prueba algo.

Intente esto: cuando esté en un shell remoto, cada vez que esté a punto de escribir la tecla "retorno", pare durante 5 segundos, con el dedo sobre la tecla "retorno", y vuelva a leer el comando que está a punto de enviar. ¿Está bien? ¿Estás seguro?

Esto parece duro, pero, por otro lado, no deberíamos pasar mucho tiempo en proyectiles remotos. Deberíamos encontrar todas las formas de automatizar nuestro trabajo de mantenimiento para que raramente, si alguna vez, necesitamos iniciar sesión en un servidor remoto.