openssh bugs - Oct 2025 - [Bug 3883] New: /etc/profile is always executes

https://bugzilla.mindrot.org/show_bug.cgi?id=3883

            Bug ID: 3883
           Summary: /etc/profile is always executes
           Product: Portable OpenSSH
           Version: 9.9p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: butirsky at gmail.com

That is, even for non-login and non-interactive shells.

According to man bash, /etc/profile can only be executed for login
shell.

To reproduce:
- on server, place something to /etc/profile[.d/*] file which produces
error or output
- on client, try to connect with any non-interactive command.

In my case:
$ ssh server tty
/etc/profile.d/aaa.sh: line 1: [: too many arguments
not a tty

So we see /etc/profile.d/aaa.sh is actually executed, while it
shouldn't.

I couldn't reproduce the problem by manually run "bash -c ..."
command,
which makes me think it might be SSH issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3883

butirsky at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|/etc/profile is always      |/etc/profile is always
                   |executes                    |executed

--- Comment #1 from butirsky at gmail.com ---
So it's apparently ~/.bashrc which is actually being invoked, and this
behavior described in bash manual:

       Bash attempts to determine when it is being run with its
standard input connected to a network connection, as when executed by
the historical remote shell daemon, usually rshd, or the secure shell
daemon
       sshd.  If bash determines it is being run non-interactively in
this fashion, it reads and executes commands from ~/.bashrc, if that
file exists and is readable.  It will not do this  if  invoked  as  sh.
       The  --norc  option  may be used to inhibit this behavior, and
the --rcfile option may be used to force another file to be read, but
neither rshd nor sshd generally invoke the shell with those options or
       allow them to be specified.

Not sure what are solutions here, though.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3883

Jim Knoble <jmknoble at pobox.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmknoble at pobox.com

--- Comment #2 from Jim Knoble <jmknoble at pobox.com>
---
> bash [...] executes commands from ~/.bashrc, if that file exists and is
readable
> [...]
> Not sure what are solutions here, though.
This sounds like your ~/.bashrc is somehow sourcing /etc/profile.

I'm unable to reproduce this behavior on (admittedly old) macOS 10.15.7
with OpenSSH 8.1p1.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3883

butirsky at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #3 from butirsky at gmail.com ---
Right.
I hoped to keep the vendor-provided (Fedora) files insane, but in this
case I see no other "solution" rather than commenting out the sourcing
lines:

$ cat .bashrc
# .bashrc

# Source global definitions
#if [ -f /etc/bashrc ]; then
#    . /etc/bashrc
#fi
...

Thank you for your time, and sorry for the noise. Closing.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.