We recently upgraded to openss 5.8p2 from a somewhat older version. This broke openssh login to ScreenOS devices. These devices don't support PTY allocation. Apparently, ssh now reacts to PTY allocation failure by failing the login. This is a change from the previous behavior. The simple workaround is ssh -T $device. I see in the ChangeLog that some device would hang with PTY allocation disabled. So apparently, we have mutually exclusive bad behaviors.>From the ChangeLog:- djm at cvs.openbsd.org 2010/04/10 02:08:44 [clientloop.c] bz#1698: kill channel when pty allocation requests fail. Fixed stuck client if the server refuses pty allocation. ok dtucker@ "think so" markus@ There don't seem to be any ssh_config options that control PTY allocation behavior. Any way we can get some options? There should be at least one, maybe two ssh_config options to control PTY behavior: one to control the PTY failure behavior, something like ExitOnPTYFailure yes|no|no-warn, and one to give the equivalent of -T or -t, i.e. something like PTYEnable: yes|no|force-yes|yes-if-login. Note that, IME, for the ChangeLog case, that is a device that normally allows PTY creation and the PTY fails, the result looks like a hang but really isn't. Rather, what you have is a non-interactive shell. The shell works but doesn't display a prompt. So, for example, back under Solaris 2.6, if you allocated all 128 default PTYs and then login with ssh, the login will just sit there after login without displaying a prompt. But it really isn't hung -- you can run non-interactive commands and see the responses. Thanks. - Morty
On Sun, Jul 24, 2011 at 4:47 AM, Mordechai T. Abzug <morty at frakir.org> wrote:> We recently upgraded to openss 5.8p2 from a somewhat older version. > This broke openssh login to ScreenOS devices. ?These devices don't > support PTY allocation. ?Apparently, ssh now reacts to PTY allocation > failure by failing the login. ?This is a change from the previous > behavior. ?The simple workaround is ssh -T $device.[...]> There don't seem to be any ssh_config options that control PTY > allocation behavior. ?Any way we can get some options? ?There should > be at least one, maybe two ssh_config options to control PTY behavior: > one to control the PTY failure behavior, something like > ExitOnPTYFailure yes|no|no-warn, and one to give the equivalent of -T > or -t, i.e. something like PTYEnable: yes|no|force-yes|yes-if-login.Damien already added a config option ("RequestTTY") but there hasn't been a release since then (this problem didn't become apparent until after the 5.8 release when people used it with the problem devices). RequestTTY Specifies whether to request a pseudo-tty for the session. The argument may be one of: ``no'' (never request a TTY), ``yes'' (always request a TTY when standard input is a TTY), ``force'' (always request a TTY) or ``auto'' (request a TTY when opening a login session). This option mirrors the -t and -T flags for ssh(1). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4? 37C9 C982 80C7 8FF4 FA69 ? ? Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On Sat, 23 Jul 2011, Mordechai T. Abzug wrote:> We recently upgraded to openss 5.8p2 from a somewhat older version. > This broke openssh login to ScreenOS devices. These devices don't > support PTY allocation. Apparently, ssh now reacts to PTY allocation > failure by failing the login. This is a change from the previous > behavior. The simple workaround is ssh -T $device.The problem is a bug in ScreenOS, it refuses pty-req channel requests when the tty modes blob exceeds 256 bytes in length. If you want a workaround that preserves the usability of the tty, then comment out a couple of less-important modes in ttymodes.h and recompile -d