Provide a way to source shell-specific startup files for noninteractive commands

[Jochen Bern]

On 22.05.22 00:52, Ivan Pozdeev wrote:
> However, the distro maintainers' decision to enable it looks like a 
> workaround for the fact that sshd does not provide a way to run the 
> standard shell startup files when running noninteractive commands. This 
> makes `ssh user at host <command>` rather useless because the <command> 
> would run in an incomplete -- and most importantly, different -- 
> environment than a usual shell command, leading to all sorts of 
> surprising breakage and counterintuitive behavior.

And simultaneously makes it a useful simulation of having said command 
executed by cron (where the shell is a non-interactive one, the 
environment different, stdin "not a tty", yadda yadda, too) for debugging.

> I see two ways to fix this underlying problem and hopefully eliminate 
> the need for workarounds like that.
> 
> 1) Run noninteractive shells as login shells just like interactive ones 
> (e.g. `bash -lc` instead of `bash -c`).

Let's see, what does this server here do all day in terms of SSH ... ?

> # grep Accepted /var/log/secure | awk '{ print $9; }' | sort | uniq -c
>     403 accounting
>   21813 nagios
>       3 root

I wonder what /var/log/wtmp and the output of "last" would look like if 
all the Nagios checks were to be forced to use an interactive shell?

On 22.05.22 01:00, Thorsten Glaser wrote:
> usually, this means use the ssh(1) -t option.

Hmm, are you sure about that?

 From (my) bash manpage:

> INVOCATION
>        A login shell is one whose first character of argument zero is
>        a -, or one started with the --login option.
> 
>        An  interactive shell is one started without non-option arguments
>        and without the -c option whose standard input and error are both
>        connected to terminals (as determined by isatty(3)), or one
>        started with the -i option. PS1 is set and $- includes i if bash
>        is interactive
[...]
>        When  bash  is  invoked as an interactive login shell, or as a
>        non-interactive shell with the --login option, it first [...]
>        After [...], it looks for ~/.bash_profile, ~/.bash_login, and
>        ~/.profile, in that order, and reads and executes commands from
>        the first one that exists and is readable.
[...]
>        When  an  interactive  shell that is not a login shell is started,
>        bash reads and executes commands from ~/.bashrc, if that file exists.

Let's try that ... :

> $ ssh SameServer 'echo $-'
> hBc
> $ ssh -t SameServer 'echo $-'
> hBc

However, note that with bash and forwarded env vars, at least, one could 
work around SSH not providing a means to manually set --login or -i 
options for the remote shell:

>        When bash is started non-interactively, to run a shell script, for
>        example, it looks for the variable BASH_ENV in the environment,
>        expands its value if it appears there, and uses the expanded value
>        as the name of a file to read and execute.
Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220523/ee865f44/attachment-0001.p7s>