openssh PTY allocation

[Morty Abzug]

On Tue, Aug 02, 2011 at 06:16:14PM +1000, Damien Miller wrote:
> 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.

Then they must have increased the buffer between 5.3.0r3.0 and
5.4.0r20.0.

> > 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.

ScreenOS isn't a *nix.  In practice, even with a PTY allocation
failure error, its command-line function acts as much like a PTY as it
ever does.  For example, you can do full command-line editing and
scroll through command history even after getting a PTY allocation
failure error.  I suspect ScreenOS is making a bunch of hardcoded
assumptions about terminal-like behaviors that completely violate
normal *nix conventions, but make sense in a non-*nix environment that
needs to play well with *nix.  So the PTY allocation failure really
does appear to be meaningless in the case of a ScreenOS device.

> 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.

I've already reported this to our Juniper SE, who says he passed it on
to their maintenance engineering.  However, I'll echo what Chris Adams
said in an earlier message:

  Unfortunately, there are a ton of ScreenOS devices out there, and
  even if Juniper fixed the SSH bugs tomorrow, all those devices won't
  be updated overnight (if ever).  This will be a serious irritation
  for network admins as OS distributions update to newer OpenSSH
  versions (where most users get their OpenSSH).

In a lot of environments, upgrading openssh is a whole lot easier than
upgrading firewalls.  Firewalls are customer-facing service devices
with monetary repercussions for downtime, whereas openssh on a network
engineering station is an internal application that customers don't
care about.

And for that matter, openssh is what changed -- older openssh worked
fine with these same revisions of ScreenOS.  This may be
Juniper/Netscreen's mistake, but this is most easily patched on
openssh's side.

> > 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.

Again, this formerly worked.  I have scripts that were built around
scp to ScreenOS devices.  Older openssh worked fine.  The addition of
the "--" option to the remote scp invocation is what appears to have
broken interop between openssh's scp and ScreenOS's scp.

- Morty