Bug 3542 - Allow to redirect stderr only even with tty
Summary: Allow to redirect stderr only even with tty
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 9.1p1
Hardware: All Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-18 02:45 AEDT by cadeaudeelie
Modified: 2023-02-20 19:24 AEDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cadeaudeelie 2023-02-18 02:45:25 AEDT
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
Comment 1 cadeaudeelie 2023-02-18 02:47:03 AEDT
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.
Comment 2 Damien Miller 2023-02-20 14:54:26 AEDT
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?
Comment 3 cadeaudeelie 2023-02-20 19:24:03 AEDT
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.