openssh unix dev - Jul 2020 - Possible options that a ssh subsystem can do when client allocate pty via pty-req when its protocol doesn't expect it

I have a subsystem which is intended?to be directly connected to the ssh server
via pipes.


Similar to stfp/scp

However?if the client side allocated a?pty?via "pty-req" just prior to
invoking the subsystem this will cause the subsystem protocol?to appear to be
broken do to the allocated pseudo-terminal and resulting line discipline device.

I did not find any evidence of the sftp service side code doing any validation
of its stdin/stdout to confirm if they were connected to a tty device isatty().

Some of the options my subsystem could do:

1. exit the subsystem if a?pty?was allocated for its session. i.e SSH_TTY is set
for example.
2. reconfigure the line discipline setting in order to still make the protocol
still work. (ex: stty -opost). This would probably be unacceptable since the
client is fully capable of doing this configuration and any re-configuration by
the server may interfere which the clients configuration.
3. Are there any options in OpenSSH to "undo the?pty" allocation and
revert to a non-pty?command ? I can use the PermitTTY=no? setting, but this
cannot be isolated to this subsystem.
4. do nothing and consider this a garbage in/garbage out use-case.

Furthermore, in my use-case the same ssh listening port is used for both regular
shell access as well as subsystem access. Therefore in the case of regular shell
access a PTY is required.

On Wed, 8 Jul 2020, Ladouceur Jeffrey wrote:
> I have a subsystem which is intended?to be directly connected to the
> ssh server via pipes.
>
>
> Similar to stfp/scp
>
> However?if the client side allocated a?pty?via "pty-req" just
prior
> to invoking the subsystem this will cause the subsystem protocol?to
> appear to be broken do to the allocated pseudo-terminal and resulting
> line discipline device.
>
> I did not find any evidence of the sftp service side code doing any
> validation of its stdin/stdout to confirm if they were connected to a
> tty device isatty().
sftp-server doesn't bother to do this, it assumes its output is 8-bit
clean. The sftp client doesn't offer any way to allocate a TTY (why
would it?) and users would need to go out of their way to create a
broken setup.
> Some of the options my subsystem could do:
>
> 1. exit the subsystem if a?pty?was allocated for its session. i.e
> SSH_TTY is set for example.
This is IMO a good approach if you're worried about users who have
messed up their configurations to demand a TTY for subsystems.
> 2. reconfigure the line discipline setting in order to still make
> the protocol still work. (ex: stty -opost). This would probably
> be unacceptable since the client is fully capable of doing this
> configuration and any re-configuration by the server may interfere
> which the clients configuration.
There's another related option here: have your subsystem communicate
exclusively with characters that will not be interpreted by the tty.
E.g. base64-encode everything.

Note that I am not recommending this approach ^_^
> 3. Are there any options in OpenSSH to "undo the?pty" allocation
and
> revert to a non-pty?command ? I can use the PermitTTY=no? setting, but
> this cannot be isolated to this subsystem.
OpenSSH's ssh client will not request a tty by default when executing
a command or requesting a subsystem. It is possible for the user to
override this.
> 4. do nothing and consider this a garbage in/garbage out use-case.
sftp-server does #4 - given that the user has to take deliberate
action to break the setup, IMO this is reasonable.
> Furthermore, in my use-case the same ssh listening port is used for
> both regular shell access as well as subsystem access. Therefore in
> the case of regular shell access a PTY is required.
I don't that adds much to the problem - regardless of whether the
service is shared, the user needs to take steps to make their
configuration not work.

-d