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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux