openssh unix dev - Apr 2003 - OpenSSH 3.6.1p1 on NCR MP-RAS v4.3, several weird terminal problems

I compiled OpenSSH 3.6.1p1 on NCR MP-RAS v4.3 (or at least
"uname -a"'s output of 4.0.3.0 suggests v4.3, I'm not
positive).

I was able to compile zlib (1.1.4) and openssl (0.9.7a) with little
trouble.

OpenSSH took hand-hacking the includes.h file as follows:

diff -cr openssh-3.6.1p1/includes.h openssh-3.6.1p1-customized/includes.h
*** openssh-3.6.1p1/includes.h  Sun Oct 20 20:50:26 2002
--- openssh-3.6.1p1-customized/includes.h       Mon Apr  7 17:32:04 2003
***************
*** 104,110 ****
--- 104,114 ----
  #ifdef HAVE_SYS_TIME_H
  # include <sys/time.h> /* For timersub */
  #endif
+ #define _XOPEN_SOURCE
+ #define _XOPEN_SOURCE_EXTENDED 1
  #include <sys/resource.h>
+ #undef _XOPEN_SOURCE_EXTENDED
+ #undef _XOPEN_SOURCE
  #ifdef HAVE_SYS_SELECT_H
  # include <sys/select.h>
  #endif

Other than that, things *appeared* to compile and install fine.

Then I logged in to this NCR MP-RAS machine using SSH (from Van Dyke's
SecureCRT v4.0.4) and saw this:

$ man ls | more
Cannot reopen stdout: No such device or address

$ PAGER=more
$ export PAGER
$ man ls
Cannot reopen stdout: No such device or address
Cannot reopen stdout: No such device or address


Even worse than the pipe problem: Control-C ANYWHERE - at the command
prompt, while a command is running, inside 'vi', anywhere - will kill
the
SSH connection completely! Ick...

$ ssh -l username MP-RAS_host
username at MP-RAS_host's password: ********
<login banners and motd>
$ ^C
Connection to MP-RAS_host closed by remote host. Connection to MP-RAS_host
closed.


One more thing: on exiting the shell normally (pressing Control-D), the
SSH session does not fully close; I see "^D" displayed in the remote
shell
and the shell has exited, but the actual remote connection from the SSH
client to the SSH server remains open until killed.

$ ssh -l username MP-RAS_host
username at MP-RAS_host's password: ********
<login banners and motd>
$ ^D
<cursor goes down to the beginning of the next line .. and just sits there
for longer than I'm willing to be patient, until I enter <CR>~. to
close
it manually>


There's no job control when logged in under SSH:

$ ed
^Z
?
q
$

 .. as compared to under telnet:

$ ed
^Z
[1] + Stopped
$ fg
ed
q
$



I logged in with telnet in another session (also from SecureCRT v4.0.4)
and compared some things:

* /dev/pts/xx have the same owner, group, and modes in the two sessions
* environments differ slightly:
  + Only the telnet session has
    HZ=100
    TIMEOUT=0
  + The PATH is slighly different, with the SSH session adding the
    binary directory where OpenSSH is installed (/opt/openssh/bin),
    and also inserting /bin (which the telnet session lacked)
    SSH: PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/openssh/bin:/usr/ccs/bin
    Telnet: PATH=/usr/bin:/usr/sbin:/usr/ccs/bin
  + Only the SSH session contains:
    SSH_TTY=/dev/pts/xx
    SSH_CONNECTION="srcIP srcport dstIP dstport"
    SSH_CLIENT="srcIP srcport dstport"
    USER=jlibove
  + The MAIL variable in the SSH session has an extra '/' in it:
    MAIL=/var/mail//jlibove
    compared to the telnet session
    MAIL=/var/mail/jlibove

None of these seem critical, though the MAIL setting does imply some
additional misunderstanding of NCR MP-RAS' peculiarities in by the OpenSSH
code.

I compared the output of "stty -a", and found the only difference to
be
that the telnet session thought of itself as being on a 9600 baud
terminal, while the SSH session thought of itself as 38400 baud.

$ stty -a
speed 38400 baud;
rows = 34; columns = 80; ypixels = 0; xpixels = 0;
intr = ^c; quit = ^|; erase = ^h; kill = ^u;
eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^q; stop = ^s; susp = ^z; dsusp = <undef>;
rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -parext
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc
ixon -ixany -ixoff -imaxbel
isig icanon -xcase echo echoe echok -echonl -noflsh
-tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3



I have confirmed that these same problems occur when the client is
OpenSSH v3.1p1 on a Linux machine, so it is not related to the SecureCRT
client - it is definitely the way the OpenSSH code compiles/runs on the
NCR MP-RAS server.


Ideas and previous experience in getting OpenSSH to work correctly on NCR
MP-RAS will be most welcome!

Thanks
-Jay Libove, CISSP
libove at felines.org

I tried the suggested config.h modification of

 #define STREAMS_PUSH_ACQUIRES_CTTY 1

 .. and it seems to have fixed all of the problems that I reported below
(^C killing the session, logging out not fully closing the connection,
lack of job control, and command line pipes being broken).


So, in addition to the one includes.h diff that I included below to get
the SSH rand helper to compile (or something prettier that accomplishes
the same effect), something needs to add STREAMS_PUSH_ACQUIRES_CTTY for
NCR MP-RAS systems.

`uname` output on this system is not very conclusive:

$ uname -a
dwtest905 SMP090-5 4.0 3.0 4400 Pentium III(TM)-ISA/PCI

This tells us the configured node name (dwtest905), something which is
maybe a cluster name (SMP090-5), a release (4.0) and version (3.0), a
hardware indicator (4400), and a processor/bus architecture (Pentium
III(TM)-ISA/PCI).  None of this screams "NCR", though the configure
script
seems to use the 4400 (as 3[34]00) as its indicator. Some better way of
identifying the NCR MP-RAS platform might be in order too.

Thanks for the assistance!
-Jay Libove, CISSP
Delta Air Lines
libove at felines.org


On Tue, 8 Apr 2003, Jay Libove wrote:
> Date: Tue, 8 Apr 2003 14:24:10 -0400
> From: Jay Libove <libove at felines.org>
> To: openssh-unix-dev at mindrot.org
> Subject: OpenSSH 3.6.1p1 on NCR MP-RAS v4.3, several weird terminal proble
ms
>
> I compiled OpenSSH 3.6.1p1 on NCR MP-RAS v4.3 (or at least
> "uname -a"'s output of 4.0.3.0 suggests v4.3, I'm not
positive).
>
> I was able to compile zlib (1.1.4) and openssl (0.9.7a) with little
> trouble.
>
> OpenSSH took hand-hacking the includes.h file as follows:
>
> diff -cr openssh-3.6.1p1/includes.h
> openssh-3.6.1p1-customized/includes.h
> *** openssh-3.6.1p1/includes.h  Sun Oct 20 20:50:26 2002
> --- openssh-3.6.1p1-customized/includes.h       Mon Apr  7 17:32:04 2003
> ***************
> *** 104,110 ****
> --- 104,114 ----
>   #ifdef HAVE_SYS_TIME_H
>   # include <sys/time.h> /* For timersub */
>   #endif
> + #define _XOPEN_SOURCE
> + #define _XOPEN_SOURCE_EXTENDED 1
>   #include <sys/resource.h>
> + #undef _XOPEN_SOURCE_EXTENDED
> + #undef _XOPEN_SOURCE
>   #ifdef HAVE_SYS_SELECT_H
>   # include <sys/select.h>
>   #endif
>
> Other than that, things *appeared* to compile and install fine.
>
> Then I logged in to this NCR MP-RAS machine using SSH (from Van Dyke's
> SecureCRT v4.0.4) and saw this:
>
> $ man ls | more
> Cannot reopen stdout: No such device or address
>
> $ PAGER=more
> $ export PAGER
> $ man ls
> Cannot reopen stdout: No such device or address
> Cannot reopen stdout: No such device or address
>
>
> Even worse than the pipe problem: Control-C ANYWHERE - at the command
> prompt, while a command is running, inside 'vi', anywhere - will
kill
> the
> SSH connection completely! Ick...
>
> $ ssh -l username MP-RAS_host
> username at MP-RAS_host's password: ********
> <login banners and motd>
> $ ^C
> Connection to MP-RAS_host closed by remote host. Connection to
> MP-RAS_host
> closed.
>
>
> One more thing: on exiting the shell normally (pressing Control-D), the
> SSH session does not fully close; I see "^D" displayed in the
remote
> shell
> and the shell has exited, but the actual remote connection from the SSH
> client to the SSH server remains open until killed.
>
> $ ssh -l username MP-RAS_host
> username at MP-RAS_host's password: ********
> <login banners and motd>
> $ ^D
> <cursor goes down to the beginning of the next line .. and just sits
> there
> for longer than I'm willing to be patient, until I enter <CR>~.
to close
> it manually>
>
>
> There's no job control when logged in under SSH:
>
> $ ed
> ^Z
> ?
> q
> $
>
>  .. as compared to under telnet:
>
> $ ed
> ^Z
> [1] + Stopped
> $ fg
> ed
> q
> $
>
>
>
> I logged in with telnet in another session (also from SecureCRT v4.0.4)
> and compared some things:
>
> * /dev/pts/xx have the same owner, group, and modes in the two sessions
> * environments differ slightly:
>   + Only the telnet session has
>     HZ=100
>     TIMEOUT=0
>   + The PATH is slighly different, with the SSH session adding the
>     binary directory where OpenSSH is installed (/opt/openssh/bin),
>     and also inserting /bin (which the telnet session lacked)
>     SSH:
> PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/openssh/bin:/usr/ccs/bin
>     Telnet: PATH=/usr/bin:/usr/sbin:/usr/ccs/bin
>   + Only the SSH session contains:
>     SSH_TTY=/dev/pts/xx
>     SSH_CONNECTION="srcIP srcport dstIP dstport"
>     SSH_CLIENT="srcIP srcport dstport"
>     USER=jlibove
>   + The MAIL variable in the SSH session has an extra '/' in it:
>     MAIL=/var/mail//jlibove
>     compared to the telnet session
>     MAIL=/var/mail/jlibove
>
> None of these seem critical, though the MAIL setting does imply some
> additional misunderstanding of NCR MP-RAS' peculiarities in by the
> OpenSSH
> code.
>
> I compared the output of "stty -a", and found the only difference
to be
> that the telnet session thought of itself as being on a 9600 baud
> terminal, while the SSH session thought of itself as 38400 baud.
>
> $ stty -a
> speed 38400 baud;
> rows = 34; columns = 80; ypixels = 0; xpixels = 0;
> intr = ^c; quit = ^|; erase = ^h; kill = ^u;
> eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
> start = ^q; stop = ^s; susp = ^z; dsusp = <undef>;
> rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
> -parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -parext
> -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc
> ixon -ixany -ixoff -imaxbel
> isig icanon -xcase echo echoe echok -echonl -noflsh
> -tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten
> opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3
>
>
>
> I have confirmed that these same problems occur when the client is
> OpenSSH v3.1p1 on a Linux machine, so it is not related to the SecureCRT
> client - it is definitely the way the OpenSSH code compiles/runs on the
> NCR MP-RAS server.
>
>
> Ideas and previous experience in getting OpenSSH to work correctly on
> NCR
> MP-RAS will be most welcome!
>
> Thanks
> -Jay Libove, CISSP
> libove at felines.org
>

Hi Darren -

Cc: list -

 

There's not much that I can tell you about NCR MP-RAS, other than that
it is a SysV r4.3 derivative, and the hardest UNIX to port to that I've
encountered since my Xenix 286 days.

 

Here is an excerpt from the setsid() manual page:

 

     WARNING

          If the calling process is the  last  member  of  a  pipeline

          started  by  a  job  control  shell,  the shell may make the

          calling process a process group leader.  The other processes

          of  the  pipeline  become  members of that process group. In

          this case, the call to setsid will fail.  For this reason, a

          process  that  calls  setsid  and  expects  to  be part of a

          pipeline should always first fork; the  parent  should  exit

          and  the child should call setsid, thereby insuring that the

          process will work reliably when started by both job  control

          shells and non-job control shells.

 

I noticed in sshpty.c that the call to setsid() follows a section which
will call ioctl(fd, TIOCNOTTY, NULL) #ifdef TIOCNOTTY. Looking in
/usr/include/sys/*.h I find that termios.h and ttold.h #define
TIOCNOTTY.

 

termios.h will only #define TIOCNOTTY if all three of _SYS_TTOLD_H,
_POSIX_SOURCE,  and  _XOPEN_SOURCE  are not defined.

 

ttold.h will only #define TIOCNOTTY if _SYS_TERMIOS_H is not defined.

 

I do see termios.h included in the compile on this platform. I do not
see ttold.h included. Therefore, I assume that the section in sshpty.c
which would call ioctl() with TIOCNOTTY is NOT being executed. I did a
test by commenting out the #ifdef TIOCNOTTY to ensure that the ioctl()
call does happen, and took out the #define STREAMS_PUSH_ACQUIRES_CTTY.
It did not fix the problem, so calling or not calling the ioctl() with
TIOCNOTTY doesn't affect this problem. (Just casting about here).

 

Regarding O_NOCTTY, the man page for open() describes O_NOCTTY as:

 

          O_NOCTTY      If  set  and  the  file  is  a  terminal,  the

                        terminal  will not be allocated as the calling

                        process's controlling terminal.

 

If you have any specific questions regarding the platform, I'm happy to
dig in manual pages, run tests, and report back.

 

-Jay

 

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Wednesday, April 09, 2003 20:18
To: Jay Libove
Cc: openssh-unix-dev at mindrot.org
Subject: Re: OpenSSH 3.6.1p1 on NCR MP-RAS v4.3, several weird terminal
problems

 

Jay Libove wrote: 
> I tried the suggested config.h modification of 
> 
>  #define STREAMS_PUSH_ACQUIRES_CTTY 1 
> 
>  .. and it seems to have fixed all of the problems that I reported
below 
> (^C killing the session, logging out not fully closing the connection,
> lack of job control, and command line pipes being broken). 
        This means that MP-RAS somehow re-acquires a controlling
terminal after 
forking and calling setsid() the first time.  In the Solaris case, a bug

in the pty driver caused it to happen when pushing a STREAMS module 
(hence the #define name).  Linux/glibc5 has the same symptoms but it 
doesn't have STREAMS so it must be acquiring it some other way (not 
honouring O_NOCTTY maybe?) 

        What can you tell us about MP-RAS?  Is it a SysV derivative? 

        Should we just change the define to HAVE_BROKEN_O_NOCTTY.  We
could 
have configure do a run-tine test for it but it'd need a lot of the code

from pty_allocate(). 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030410/76bd5a28/attachment.html