openssh bugs - Feb 2023 - [Bug 3542] New: Allow to redirect stderr only even with tty

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

            Bug ID: 3542
           Summary: Allow to redirect stderr only even with tty
           Product: Portable OpenSSH
           Version: 9.1p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: cadeaudeelie at gmail.com

The use case:

We use bastion that will enter `exec su -` and enter the root password
when login with a tty. This help us having `PermitRootLogin no`
however once in tty stdout and stderr are multiplexed in this tty.

this elevation scenario doesn't execute when scp or sftp is used. The
solution is to send raw data to first call `stty raw` to transform the
tty as pipe and the we exec the command `dd of=target` (maybe their is
a better way).
The command are sended with GNU expect and `interact` that connect
expect stdin to the ssh tty' stdin.

For splitting stdout and stderr we have can use solution like this:

https://unix.stackexchange.com/questions/653431/ssh-with-separate-stdin-stdout-stderr-and-tty

or use process substitution
https://tldp.org/LDP/abs/html/process-sub.html
with `2> >(sed 's|.*|stderr:&|')` and then resplit locally.
This does
incur a bit overhead.





The request:
- could we have regular fd (guarded behind a flag because it seems
uncommon) and having tty.
- Or allow fd 2 to not be attached to the tty

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

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

--- Comment #1 from cadeaudeelie at gmail.com ---
I searched in the GitHub Pr and didn't seen someone trying to implement
nor some other ticket with the same thing. I volunteer to implement
this with some guidance.

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

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

cadeaudeelie at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cadeaudeelie at gmail.com

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
How would you implement this? I don't see any clear way to do it.

You can't use pipes/socketpair for the stderr, as any process that used
stderr for ioctl() fstat() etc would not be talking to a tty. This
would be very brittle.

You couldn't use another pty, as then the process would have two pty
states to contend with and only one of these would be a controlling
pty.

IMO you're trying to force ssh around an access management system that
it doesn't fit. Maybe you should reconsider your access management
system instead?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #3 from cadeaudeelie at gmail.com ---
The original stackexchange post link to another question with
suggestions: https://unix.stackexchange.com/q/226638/246754

--forwardfd=10:3

The default stderr is untouched. We have one tty but we explicitly
request another fd we can use for the launched application. Either in
interactive shell or in command mode. If the launched process hardcode
fd3 we can still change in the CLI the number we choose.

I am unsure but newfd in dup2 can be arbitrary value so we could have
the desired fd unless already taken for other things. It will even
allow people who know stderr won't be used with ioctl to override
destination of fd2.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #4 from cadeaudeelie at gmail.com ---
Hello,

update on our side:
Since changing the access management system isn't an option (because of
the number of users). I have enough and reversed-engineered the bastion
(hopefully in this component it was some python bytecode and not
hardcore C++). I was able to get a source file close enough to real
code so I just modified it and send the patch on support channel. Hope
they consider the intention well and accept the patch.

I will try to convince my boss to accept it in prod (not much hope
since it is an appliance we would break support term). So at some point
this feature request might become less blocking.

I still consider an appreciable feature but I could understand you
close it since it will cause brittle state.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

butirsky at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |butirsky at gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.