openssh PTY allocation

[Damien Miller]

On Tue, 2 Aug 2011, Morty Abzug wrote:

> Thanks.  I tried this.  It only works for one of the two devices I've
> been testing with.  The device that works runs ScreenOS 6.3.0r7.0.
> The device that's still broken runs ScreenOS 5.3.0r3.0.

I tested it with ns5gt.5.4.0r20.0.

> Knocking the threshold down from 256 to 128, though, yields joy with
> both devices.  129 and 130 work, while 131 doesn't; presumably the
> success of 129 and 130 is due to fenceposts.  Presumably the earlier
> version of ScreenOS had a version with a 128 limit; ScreenOS ran into
> interop problems at the time; ScreenOS coders bumped it to 256; and
> now they/we are having interop problems again.  Maybe some even-older
> version of ScreenOS had an even lower limit.  Hence why I'm thinking
> that it might be better to make PTY allocation failure a non-fatal
> error rather than trying to guess the other side's worst case buffer
> len.

That could be unpredictable, the ScreenOS end refuses the whole pty-req
so it is working under the assumption of no PTY whereas the client would
(by ignoring the failure) continue to expect one there.

Really, I'd prefer that Juniper just fix the bug (it is probably
trivial for them to do so) rather than peppering our tree with compat
hacks that must be maintained in perpetuity.

> Note that this doesn't do anything for scp.  The compat hack stuff
> does not seem to be available within scp.c, probably because it
> doesn't look directly at the ssh banner.

scp is inherently unfixable as a protocol.

-d