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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
