OpenSSH (muy probablemente lo que está ejecutando) decide si crear o no un shell de inicio de sesión, y solo lo hace si no está ejecutando un comando específico. Desde man ssh :
If command is specified, it is executed on the remote host instead of a login shell.
Por lo tanto, es una opción de implementación para el servidor ssh si desea crear un shell de inicio de sesión o no, y si le da un comando para ejecutarlo, no lo hace.
Mientras ssh realiza un inicio de sesión, si está haciendo que ejecute un comando y salga, en realidad es mucho más similar a crear un shell solo para ejecutar ese comando que obtener un entorno de inicio de sesión. Parece, dado eso, que las personas que escriben OpenSSH decidieron tratarlo como ese tipo de tarea.
Crean un shell no interactivo y sin inicio de sesión para ejecutar el comando, porque ese es el espíritu de ejecutar un comando en otro contexto/shell. Sin embargo, normalmente, los shells no interactivos no obtendrían automáticamente ~/.bashrc lo que claramente está sucediendo aquí. bash en realidad está tratando de ayudarnos aquí. De los documentos
Invocado por un demonio de shell remoto
Bash intenta determinar cuándo se está ejecutando con su entrada estándar conectada a una conexión de red, como cuando lo ejecuta el demonio de shell remoto, generalmente rshd, o el demonio de shell seguro sshd. Si Bash determina que se está ejecutando de esta manera, lee y ejecuta comandos desde ~/.bashrc, si ese archivo existe y se puede leer. No hará esto si se invoca como sh. La opción --norc se puede usar para inhibir este comportamiento, y la opción --rcfile se puede usar para forzar la lectura de otro archivo, pero ni rshd ni sshd generalmente invocan el shell con esas opciones ni permiten que se especifiquen.
El por qué de este comportamiento se encuentra en un nivel más bajo que los shells:ssh host (el caso del "shell de inicio de sesión") utiliza un pseudoterminal en el host remoto, para comunicarse entre los sshd proceso del servidor y el shell; ssh host command usa conductos entre sshd y command , en cambio. Los pseudoterminales son necesarios para hacer un uso interactivo de un intérprete de comandos, como un shell, o el modo "leer-evaluar-imprimir" de un lenguaje de secuencias de comandos; implementan un montón de características amigables para los humanos, como poder retroceder por errores tipográficos. Pero tienen más sobrecarga y (dependiendo de la configuración) no permiten el paso de datos arbitrarios sin modificar, por lo que SSH evita usarlos cuando la interacción no va a ocurrir.
A veces, la heurística de comando/no comando de SSH se equivoca; se puede anular con el -t y -T interruptores Por ejemplo, para iniciar sesión en una máquina remota e inmediatamente volver a conectar un screen suspendido sesión, debe hacer ssh -t host screen -R; ssh host screen -R causará screen para quejarse de no estar conectado a un terminal. No puedo pensar en una situación en la que realmente querrías usar -T , pero está ahí si alguna vez encuentras uno.