Possible options that a ssh subsystem can do when client allocate pty via pty-req when its protocol doesn't expect it
djm at mindrot.org
Thu Jul 9 09:31:33 AEST 2020
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
> 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
> 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.
More information about the openssh-unix-dev