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

[Damien Miller]

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