SSH sin fuente .bashrc

Question

Estaba experimentando con mi .bashrcarchivo mientras iniciaba sesión de forma remota en un servidor a través de SSH. Inadvertidamente dejé un mensaje exitallí que provocó que todos los inicios de sesión posteriores se desconectaran inmediatamente. Estaba efectivamente bloqueado. Pude recuperar el acceso con la intervención de alguien con privilegios de root, pero ¿habría sido posible sin la ayuda de otra persona?

Intenté hacer cosas como ejecutar ssh <server> 'bash --norc --noprofile'y ssh <server> 'mv .bashrc bashrc-backup', e incluso tratar de sobrescribirlo a la fuerza con scp empty-file <server>:.bashrc. Sin embargo, todas estas opciones parecen depender de buscar primero lo roto .bashrcantes de ejecutar el comando, por lo que ninguna funcionó.

Bien puede darse el caso de que no haya salida a este tipo de situación. ¿Pero es eso por diseño? ¿Hay alguna razón por la que sea tan fácil bloquear un sistema, por ejemplo, simplemente ejecutándolo ssh <server> 'echo exit > .bashrc'? ¿Hay formas de mitigar este tipo de error?

Answer 1

Como se discutió en la otra respuesta, cuando un cliente SSH se conecta al servidor OpenSSH, el servidor OpenSSH generalmente iniciará una sesión de shell en nombre del cliente, utilizando el shell de inicio de sesión del usuario:

1. Si el cliente solicita una sesión interactiva, el servidor iniciará el shell de inicio de sesión del usuario.
2. Si el cliente solicita ejecutar un comando, el servidor utilizará el shell de inicio de sesión del usuario para ejecutar el comando como un comando de shell.
3. Las utilidades como scp, rsyncy gitque usan ssh para el transporte solicitarán que se ejecute un comando en el sistema remoto, por lo que se incluyen en el n. ° 2.

Si tiene algo en los archivos de inicio del shell del usuario remoto que hace que el shell se cierre, entonces tendrá problemas para ingresar.

SFTP, sin embargo, es un caso especial. El servidor OpenSSH puede configurarse para admitir SFTP sin ejecutar un comando externo. Si ese es el caso, entonces podrá usar sftp para conectarse al servidor y eliminar, cambiar el nombre o alterar el .bashrcarchivo que está causando el problema.

Depende de cómo esté configurado el servidor para admitir sftp. Puede dar servicio a las sesiones sftp iniciando un programa externo (llamado sftp-server). En este caso, tendría el mismo problema para ingresar que tiene con programas como scp. O, el servidor puede dar servicio a la sesión sftp mediante algo denominado "internal-sftp" , que no requiere invocar un shell. Solo depende de cómo esté configurado el servidor SSH en particular.

Answer 2

La razón por la que esto sucede es porque sshd, el componente del lado del servidor, invoca procesos usando su shell. Si está generando un shell interactivo, lo genera como un shell de inicio de sesión; de lo contrario, usa el -cargumento para generar un shell no interactivo para ejecutar el comando que especifique.

Todas las operaciones que especificó (comandos especificados y scp) son operaciones no interactivas, por lo que normalmente bash no se cargaría .bashrc, pero bash tiene mayúsculas especiales para cuando lo invoca, de sshdmodo que lo invoca de todos modos. Si estuviera usando zsh, entonces .zshenv(que se invoca para todos los shells) se cargaría, pero .zshrc(que es solo para shells interactivos) no se cargaría a menos que estuviera cargando específicamente una sesión de shell.

En este caso, si está usando bash, no tiene suerte. No hay forma de invocar un comando SSH en el lado del servidor sin usar el shell; esto es cierto incluso para scp y sftp. La mayoría de las veces, desea usar el shell porque configura cosas como PATHpara varios programas y permite una cantidad razonable de secuencias de comandos de comandos complejos, por lo que OpenSSH siempre lo usa.

Esto también tiene algunos beneficios de seguridad: si intenta iniciar sesión en una cuenta del sistema que de alguna manera tiene una contraseña válida pero un shell de /usr/sbin/nologino /bin/false, entonces no puede hacer nada, que es probablemente lo que pretendía el administrador del sistema.

Hay formas de mitigar esto. Muchas personas mantienen un repositorio Git de sus archivos de puntos y los desarrollan en un sistema, luego los implementan en otros. Por ejemplo, siempre desarrollo archivos de puntos en mi computadora portátil. Es de suponer que notaría este problema un poco antes si, en cualquier momento, abriera una nueva ventana de terminal, esta saliera inmediatamente y podría tener acceso de root para solucionarlo usted mismo.

Si necesita probar una configuración que podría bloquearlo, como la configuración del shell o un sudoerscambio, puede dejar un shell (normal o root, respectivamente) abierto y luego hacer algunas pruebas, por lo que si rompe algo, todavía tiene un camino para deshacerlo.