OpenSSH on QNX4 -- su problem

While porting OpenSSH 2.3.0p1 to QNX 4.25, I encountered problems with ‘su’

When I ssh to a QNX4 server running sshd and attempt to su to root (or any other user account), the ‘su’ program does not even request a password, it just prints:

su: Sorry

I have compiled both the ssh client and sshd server executables with Watcom 10.6 and linked with the “privity” flag of “-T 1”. I have chmod’d these executables on the QNX server to have the ‘suid’ bit set. All to no effect.

Any help would be appreciated, especially from someone familiar with the QNX ‘su’ source, and the reasons why it might bail out without letting the user enter a password.

-Jim Parnell

Most likely you don’t have a controlling terminal. Utilities that
require that (such as su, passwd) will certainly fail. “who”
command probably won’t show your login session, or won’;t show
properly. QSSL will probably be able to help you on that, or you can
just use JC’s hack, which I still don’t understand why we
need it.
Frank

On Sat, 27 Jan 2001, Jim Parnell wrote:

While porting OpenSSH 2.3.0p1 to QNX 4.25, I encountered problems with ‘su’

When I ssh to a QNX4 server running sshd and attempt to su to root (or any other user account), the ‘su’ program does not even request a password, it just prints:

su: Sorry

I have compiled both the ssh client and sshd server executables with Watcom 10.6 and linked with the “privity” flag of “-T 1”. I have chmod’d these executables on the QNX server to have the ‘suid’ bit set. All to no effect.

Any help would be appreciated, especially from someone familiar with the QNX ‘su’ source, and the reasons why it might bail out without letting the user enter a password.

-Jim Parnell

Thanks Frank, that was a good clue. “who” run from the ssh session shows the following:

Userid Device Login Idle Command

root //0 Jan 29 10:23 —:–:-- sshd
root //0 Jan 29 10:24 —:–:-- who

All the other entries have a device name. I’ll follow up on this with the sshd code. Help would still be appreciated from QSSL.

Thanks,

-Jim

Frank Liu wrote:

Most likely you don’t have a controlling terminal. Utilities that
require that (such as su, passwd) will certainly fail. “who”
command probably won’t show your login session, or won’;t show
properly. QSSL will probably be able to help you on that, or you can
just use JC’s hack, which I still don’t understand why we
need it.
Frank

On Sat, 27 Jan 2001, Jim Parnell wrote:

While porting OpenSSH 2.3.0p1 to QNX 4.25, I encountered problems with ‘su’

When I ssh to a QNX4 server running sshd and attempt to su to root (or any other user account), the ‘su’ program does not even request a password, it just prints:

su: Sorry

I have compiled both the ssh client and sshd server executables with Watcom 10.6 and linked with the “privity” flag of “-T 1”. I have chmod’d these executables on the QNX server to have the ‘suid’ bit set. All to no effect.

Any help would be appreciated, especially from someone familiar with the QNX ‘su’ source, and the reasons why it might bail out without letting the user enter a password.

-Jim Parnell


Jim Parnell
WorldGate Communications, Inc.
(215) 354-5147 (Fax:1048)

The lack of a controlling terminal is the problem, but I do not know how to reliably
create a controlling terminal. The following sshd code attempts to do this (after forking off the sshd daemon).

  • The first ioctl(TIOCNOTTY) call which tries to disconnect from the old controlling tty returns the error ENOMSG.
  • The setsid() call returns EPERM. Note that getpgrp() returns the process pid (getpid()) – It looks like the session may already be the process leader?
  • The last ioctl(TIOCSCTTY) call returns ENOENT (an undocumented return value, BTW)
  • Lastly, the fopen on “/dev/tty” in O_WRONLY also returns ENOENT

Any help in this matter would be greatly appreciated.

-Jim


/* Makes the tty the processes controlling tty and sets it to sane modes. */

void
pty_make_controlling_tty(int *ttyfd, const char *ttyname)
{
int fd;
#ifdef USE_VHANGUP
void old;
#endif /
USE_VHANGUP */

/* First disconnect from the old controlling tty. /
#ifdef TIOCNOTTY
fd = open("/dev/tty", O_RDWR | O_NOCTTY);
if (fd >= 0) {
(void) ioctl(fd, TIOCNOTTY, NULL);
close(fd);
}
#endif /
TIOCNOTTY */
if (setsid() < 0)
error(“setsid: %.100s”, strerror(errno));

/*

  • Verify that we are successfully disconnected from the controlling
  • tty.
    /
    fd = open("/dev/tty", O_RDWR | O_NOCTTY);
    if (fd >= 0) {
    error(“Failed to disconnect from controlling tty.”);
    close(fd);
    }
    /
    Make it our controlling tty. /
    #ifdef TIOCSCTTY
    debug(“Setting controlling tty using TIOCSCTTY.”);
    /
  • We ignore errors from this, because HPSUX defines TIOCSCTTY, but
  • returns EINVAL with these arguments, and there is absolutely no
  • documentation.
    */
    ioctl(ttyfd, TIOCSCTTY, NULL);
    #endif /
    TIOCSCTTY /
    #ifdef HAVE_NEWS4
    if (setpgrp(0,0) < 0)
    error(“SETPGRP %s”,strerror(errno));
    #endif /
    HAVE_NEWS4 /
    #ifdef USE_VHANGUP
    old = signal(SIGHUP, SIG_IGN);
    vhangup();
    signal(SIGHUP, old);
    #endif /
    USE_VHANGUP */
    fd = open(ttyname, O_RDWR);
    if (fd < 0) {
    error("%.100s: %.100s", ttyname, strerror(errno));
    } else {
    #ifdef USE_VHANGUP
    close(*ttyfd);
    ttyfd = fd;
    #else /
    USE_VHANGUP /
    close(fd);
    #endif /
    USE_VHANGUP /
    }
    /
    Verify that we now have a controlling tty. */
    fd = open("/dev/tty", O_WRONLY);
    if (fd < 0)
    error(“open /dev/tty failed - could not set controlling tty: %.100s”,
    strerror(errno));
    else {
    close(fd);
    }
    }



    Jim Parnell wrote:

Thanks Frank, that was a good clue. “who” run from the ssh session shows the following:

Userid Device Login Idle Command

root //0 Jan 29 10:23 —:–:-- sshd
root //0 Jan 29 10:24 —:–:-- who

All the other entries have a device name. I’ll follow up on this with the sshd code. Help would still be appreciated from QSSL.

Thanks,

-Jim

Frank Liu wrote:

Most likely you don’t have a controlling terminal. Utilities that
require that (such as su, passwd) will certainly fail. “who”
command probably won’t show your login session, or won’;t show
properly. QSSL will probably be able to help you on that, or you can
just use JC’s hack, which I still don’t understand why we
need it.
Frank

On Sat, 27 Jan 2001, Jim Parnell wrote:

While porting OpenSSH 2.3.0p1 to QNX 4.25, I encountered problems with ‘su’

When I ssh to a QNX4 server running sshd and attempt to su to root (or any other user account), the ‘su’ program does not even request a password, it just prints:

su: Sorry

I have compiled both the ssh client and sshd server executables with Watcom 10.6 and linked with the “privity” flag of “-T 1”. I have chmod’d these executables on the QNX server to have the ‘suid’ bit set. All to no effect.

Any help would be appreciated, especially from someone familiar with the QNX ‘su’ source, and the reasons why it might bail out without letting the user enter a password.

-Jim Parnell

Jim Parnell (jparnell@wgate.com) wrote:
: The lack of a controlling terminal is the problem, but I do not know how to
: reliably create a controlling terminal. The following sshd code attempts to
: do this (after forking off the sshd daemon).

: * The first ioctl(TIOCNOTTY) call which tries to disconnect from the old controlling tty returns the error ENOMSG.
: * The setsid() call returns EPERM. Note that getpgrp() returns the process pid (getpid()) – It looks like the session may already be the process leader?
: * The last ioctl(TIOCSCTTY) call returns ENOENT (an undocumented return value, BTW)
: * Lastly, the fopen on “/dev/tty” in O_WRONLY also returns ENOENT

: Any help in this matter would be greatly appreciated.


Due to a tip from Frank Liu I had inserted a qsetlogin() - function in
pty.c, and now the creation of a controlling tty works (I’ve been working
on my own port last year). My version of the OpenSSH sources (2.2.0p1)
can be downloaded from
ftp://ds2.etech.fh-hamburg.de/pub/qnx/tcpip/openssh-2.2.0p1-qnx.tar.gz
Though there are still problems with my port. At first, there is a problem
with logging, and second the ssh daemon and the Dev.random device driver
sometimes have to be restarted because of an error as
Couldn’t open random pool “/dev/urandom”: Not enough memory
though the system is NOT out of memory.
If anyone knows help, please let me know.

-Andreas

Andreas,

Thanks for your reply. I’ll take a look at qsetlogin() tomorrow. Send() to Proc32, eh? I KNEW there had to be a secret handshake!

I think I found the logging problem, or at least one of them. In servconf.c find the section that initializes the facility and log level in function
read_server_config(). There is an assumption that the type of SyslogFacility and LogLevel are both integer-sized. They are not. Watcom’s default is to align on
a byte in structures, so options.log_level and .facility were being misread out of the structure. Even if you use the -zp4 flag to try to align, it fails, so
the right answer (I think) is the following:

case sLogFacility:
{
SyslogFacility *sptr;

sptr = (SyslogFacility *) &options->log_facility;
arg = strdelim(&cp);
value = log_facility_number(arg);
if (value == (SyslogFacility) -1)
fatal("%.200s line %d: unsupported log facility ‘%s’\n",
filename, linenum, arg ? arg : “”);
if (*sptr == -1)
*sptr = (SyslogFacility) value;
}
break;

case sLogLevel:
{
LogLevel *lptr;

lptr = (LogLevel *) &options->log_level;
arg = strdelim(&cp);
value = log_level_number(arg);
if (value == (LogLevel) -1)
fatal("%.200s line %d: unsupported log level ‘%s’\n",
filename, linenum, arg ? arg : “”);
if (*lptr == -1)
*lptr = (LogLevel) value;
}
break;

I have no idea why all the pointer jazz is necessary, but I think it is.

Regards,

-Jim

Andreas Schneider wrote:

Jim Parnell (> jparnell@wgate.com> ) wrote:
: The lack of a controlling terminal is the problem, but I do not know how to
: reliably create a controlling terminal. The following sshd code attempts to
: do this (after forking off the sshd daemon).

: * The first ioctl(TIOCNOTTY) call which tries to disconnect from the old controlling tty returns the error ENOMSG.
: * The setsid() call returns EPERM. Note that getpgrp() returns the process pid (getpid()) – It looks like the session may already be the process leader?
: * The last ioctl(TIOCSCTTY) call returns ENOENT (an undocumented return value, BTW)
: * Lastly, the fopen on “/dev/tty” in O_WRONLY also returns ENOENT

: Any help in this matter would be greatly appreciated.

Due to a tip from Frank Liu I had inserted a qsetlogin() - function in
pty.c, and now the creation of a controlling tty works (I’ve been working
on my own port last year). My version of the OpenSSH sources (2.2.0p1)
can be downloaded from
ftp://ds2.etech.fh-hamburg.de/pub/qnx/tcpip/openssh-2.2.0p1-qnx.tar.gz
Though there are still problems with my port. At first, there is a problem
with logging, and second the ssh daemon and the Dev.random device driver
sometimes have to be restarted because of an error as
Couldn’t open random pool “/dev/urandom”: Not enough memory
though the system is NOT out of memory.
If anyone knows help, please let me know.

-Andreas