[OFF] OpenSSH on OpenServer 5.0.6a
Bill Andersen
I've installed JPRadley's binaries for OpenSSH and "sshd"
seems to be loaded normally. However, I can't get a shell to work.
When I telnet in from a PC running a terminal emulator that
supports SSH on port 22, I get the following.
TERM = (vt100)
OK, that's normal. However, when I just hit enter to continue
it doesn't do anything. After the 4th enter, I get the following:
TERM = (vt100) tput: unknown "erminal "
Now, if I try to type "vt100" instead of hitting enter, I get cut off
after the 4th character and get the error below:
TERM = (vt100) tput: unknown "vt10"
Each time, I do get a prompt: # BUT, it does not respond to
any keyboard entry at all. Completely locked up.
To add to the wierdness, on my user account where my .profile automatically
runs "pine" email, it works fine. I can read email, move around with
no problem. However, when I exit back to the shell, it locks and will not
take any keyboard entry. Looks like a shell problem, but where do I start?
Also, I can telnet without SSH enabled on the Client side and everything
works fine. And the Terminal Emulator (Tera Term with SSH) works fine
with OpenSSH on 4 other machines I have access to running RH Linux.
Can anyone point me in the right direction?
TIA
Bill
Bob Rasmussen
> OK, that's normal. However, when I just hit enter to continue
> it doesn't do anything. After the 4th enter, I get the following:
>
> TERM = (vt100) tput: unknown "erminal "
>
> Now, if I try to type "vt100" instead of hitting enter, I get cut off
> after the 4th character and get the error below:
Try:
<ctrl-J>stty sane<ctrl-J>
When sshd connects with SCO, it doesn't establish a good set of stty
parameters. If the ssh client doesn't send them, you end up in the state you
are in.
AnzioWin handles this correctly, effective version 12.5m.
Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.
personal e-mail: r...@anzio.com
company e-mail: r...@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
Jean-Pierre Radley
| On Mon, 29 Apr 2002, Bill Andersen wrote:
|
| > OK, that's normal. However, when I just hit enter to continue
| > it doesn't do anything. After the 4th enter, I get the following:
| >
| > TERM = (vt100) tput: unknown "erminal "
| >
| > Now, if I try to type "vt100" instead of hitting enter, I get cut off
| > after the 4th character and get the error below:
|
| Try:
| <ctrl-J>stty sane<ctrl-J>
|
| When sshd connects with SCO, it doesn't establish a good set of stty
| parameters. If the ssh client doesn't send them, you end up in the state you
| are in.
|
| AnzioWin handles this correctly, effective version 12.5m.
Running ssh from OSR 5 to a Linux machine running sshd, or to another
OSR 5 box running sshd, I've never seen any stty problems of this sort.
Can you go into a bit more detail?
--
JP
Brian K. White
"Bill Andersen" <bi...@mwdental.com> wrote in message
news:NEBBLMPLNKHMEHJG...@mwdental.com...
vi /etc/profile
fairly early in the file (I put it right after the "trap" & "umask")
insert this line:
[ -n "$SSH_TTY" ] && stty sane
also, (this is purely cosmetic) you might want to edit
/usr/local/ssh/etc/sshd_config and uncomment PrintMotd and make it "no" so
you stop getting two copies of it.
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Bob Rasmussen
> Bob Rasmussen propounded (on Mon, Apr 29, 2002 at 04:02:52PM -0700):
> | When sshd connects with SCO, it doesn't establish a good set of stty
> | parameters. If the ssh client doesn't send them, you end up in the state you
> | are in.
> |
> | AnzioWin handles this correctly, effective version 12.5m.
>
> Running ssh from OSR 5 to a Linux machine running sshd, or to another
> OSR 5 box running sshd, I've never seen any stty problems of this sort.
> Can you go into a bit more detail?
OK. After sshd validates the user, it must interact with the OS to get a shell
prompt. It may use the "login" program for this, I don't recall. Let's assume
it does. When it gets a connection through login, the user sees a shell
prompt, through a pseudo tty session.
In other Unix/Linux systems, the login program seems to hand to sshd a pty
with the stty settings already configured in a sane manner. Thus an <enter>
key, which sends a CR, gets converted to a LF (icrnl). Not so with OSR 5. It
seems to hand off a pty with stty set to "all zeros".
Part of both the ssh1 and ssh2 protocols allows the client to send stty
settings to the server. Some Windows clients do this, some do not. I'm not
sure about OpenSSH client on Unix, but from your comments I assume it does.
So:
OSR5 to Linux: Linux hands off a sane pty, no problem.
OSR5 to OSR5, or Linux to OSR5: Login hands off a bad pty, but the ssh client
sends the stty settings, so no problem.
Some Windows SSH client to OSR5: Login hands off a bad pty, the client doesn't
send stty settings, so things don't work well.
AnzioWin SSH client (current version) to OSR5: Client sends stty settings, all
is good.
Bela Lubkin
> OK. After sshd validates the user, it must interact with the OS to get a shell
> prompt. It may use the "login" program for this, I don't recall. Let's assume
> it does. When it gets a connection through login, the user sees a shell
> prompt, through a pseudo tty session.
OpenSSH can be configured, both at compile and at runtime, whether to
use login or not. If it's compiled not to support login or
runtime-configured not to use it, it does its own pty setup.
> In other Unix/Linux systems, the login program seems to hand to sshd a pty
> with the stty settings already configured in a sane manner. Thus an <enter>
> key, which sends a CR, gets converted to a LF (icrnl). Not so with OSR 5. It
> seems to hand off a pty with stty set to "all zeros".
OSR5 /bin/login configures the pty in a sane manner. However, OpenSSH
"out of the box" (i.e. if you configure/make it yourself) does _not_ by
default use the OS's login program. This causes quite a few problems on
OSR5, one of the most visible of which is this pty settings problem.
> Part of both the ssh1 and ssh2 protocols allows the client to send stty
> settings to the server. Some Windows clients do this, some do not. I'm not
> sure about OpenSSH client on Unix, but from your comments I assume it does.
>
> So:
>
> OSR5 to Linux: Linux hands off a sane pty, no problem.
>
> OSR5 to OSR5, or Linux to OSR5: Login hands off a bad pty, but the ssh client
^^^^^ OpenSSH sshd
> sends the stty settings, so no problem.
>
> Some Windows SSH client to OSR5: Login hands off a bad pty, the client doesn't
^^^^^ OpenSSH sshd
> send stty settings, so things don't work well.
>
> AnzioWin SSH client (current version) to OSR5: Client sends stty settings, all
> is good.
>Bela<
Jean-Pierre Radley
| Bob Rasmussen wrote:
|
| > OK. After sshd validates the user, it must interact with the OS to
| > get a shell prompt. It may use the "login" program for this, I don't
| > recall. Let's assume it does. When it gets a connection through
| > login, the user sees a shell prompt, through a pseudo tty session.
|
| OpenSSH can be configured, both at compile and at runtime, whether
| to use login or not. If it's compiled not to support login or
| runtime-configured not to use it, it does its own pty setup.
|
| > In other Unix/Linux systems, the login program seems to hand to
| > sshd a pty with the stty settings already configured in a sane
| > manner. Thus an <enter> key, which sends a CR, gets converted to a
| > LF (icrnl). Not so with OSR 5. It seems to hand off a pty with stty
| > set to "all zeros".
|
| OSR5 /bin/login configures the pty in a sane manner. However,
| OpenSSH "out of the box" (i.e. if you configure/make it yourself)
| does _not_ by default use the OS's login program. This causes quite
| a few problems on OSR5, one of the most visible of which is this pty
| settings problem.
On jpradley.jpr.com, /usr/local/etc/sshd_config contains:
UseLogin no
Bela, what do you see for stty -a (and for that matter, for id -l) after
running ssh jpradley.jpr.com?
If in fact I change UseLogin to be 'yes', I can't even get in:
LOGIN: ERROR: Illegal option -- h
Usage: LOGIN [ -c ] [ [ -f ] username [ name=value ]... ]
or: LOGIN [ -c ] -r remhost remuser username [ name=value ]...
Connection to jpradley.jpr.com closed.
[OpenSSH_3.1p1]
--
JP
Bela Lubkin
> On jpradley.jpr.com, /usr/local/etc/sshd_config contains:
>
> UseLogin no
>
> Bela, what do you see for stty -a (and for that matter, for id -l) after
> running ssh jpradley.jpr.com?
stty settings look sane; but I'm coming from a Unix ssh client that will
have pushed sane settings. `id -l` says I'm root, and one consequence
is the message:
prwarn: Cannot update .prwarn_time in root's home directory
Permission denied
during login. The SecureWare security commands think I'm root -- I
doubt this is a good thing.
> If in fact I change UseLogin to be 'yes', I can't even get in:
>
> LOGIN: ERROR: Illegal option -- h
> Usage: LOGIN [ -c ] [ [ -f ] username [ name=value ]... ]
> or: LOGIN [ -c ] -r remhost remuser username [ name=value ]...
> Connection to jpradley.jpr.com closed.
>
> [OpenSSH_3.1p1]
This used to work in some older release of OpenSSH. Might still work, I
haven't looked at the code -- see if it has an #ifdef or other control
over whether it includes that "-h" option. It is trying to pass "-h
remote.host.dom" to login, which is then supposed to store that in utmp.
The nearest equivalent in OSR5's login is the "-r" flag, and it has an
important difference. You pass it "-r remote.host.dom remuser". It
then looks up whether that user is allowed to login with no password --
that is, it checks ~user/.rhosts and /etc/hosts.equiv.
I believe you _could_ use the -r flag, as long as you passed in an
"impossible" remote username, e.g. "-r remote.host.dom //sshd//". That
wouldn't match the local user's name, so hosts.equiv wouldn't come into
play; and "//sshd//" wouldn't appear in the local user's .rhosts. Or at
least if it did, it would be because the local user was _trying_ to
shoot himself in the foot.
So recompile sshd to either leave out the "-h remhost" part, or change
it to "-r remhost //sshd//"; see how it goes.
>Bela<
Jean-Pierre Radley
Neither choice works. They both lead to
No utmp entry. You must exec "LOGIN" from the lowest level "sh".
The rest of the options used by ssh don't seem to jibe with OSR's
/bin/login either:
if (options.use_login) {
/* Launch login(1). */
execl(LOGIN_PROGRAM, "login", "-h", hostname,
#ifdef LOGIN_NEEDS_TERM
(s->term ? s->term : "unknown"),
#endif /* LOGIN_NEEDS_TERM */
"-p", "-c", "-f", "--", pw->pw_name, (char *)NULL);
I tried removing the "-p" and the "--" ; neither helped.
As for luid, I see code that reads:
# if defined(HAVE_GETLUID) && defined(HAVE_SETLUID)
/* Sets login uid for accounting */
if (getluid() == -1 && setluid(pw->pw_uid) == -1)
error("setluid: %s", strerror(errno));
# endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */
'Configure' did define both HAVE_GETLUID and HAVE_SETLUID to 1.
--
JP
Bela Lubkin
> | So recompile sshd to either leave out the "-h remhost" part, or change
> | it to "-r remhost //sshd//"; see how it goes.
>
> Neither choice works. They both lead to
> No utmp entry. You must exec "LOGIN" from the lowest level "sh".
Like I said, this used to work with some older version of OpenSSH. They
changed what they expected login to do and didn't check that the results
worked with all the OSes OpenSSH can be built for.
"No utmp entry" means no utmp entry. See if there's code nearby, maybe
ifdef'd or runtime-configured out, that establishes a utmp entry for the
session it's trying to start.
> The rest of the options used by ssh don't seem to jibe with OSR's
> /bin/login either:
>
> if (options.use_login) {
> /* Launch login(1). */
> execl(LOGIN_PROGRAM, "login", "-h", hostname,
> #ifdef LOGIN_NEEDS_TERM
> (s->term ? s->term : "unknown"),
> #endif /* LOGIN_NEEDS_TERM */
> "-p", "-c", "-f", "--", pw->pw_name, (char *)NULL);
>
> I tried removing the "-p" and the "--" ; neither helped.
Ah, they're using "-f", so my advice about working around .rhosts issues
is probably irrelevant. Use "-r remhost remuser", i.e. supplying the
true names of both, if they are known.
OSR5 login supports "-p" and (since it uses getopt()) won't be thrown by
"--".
> As for luid, I see code that reads:
> # if defined(HAVE_GETLUID) && defined(HAVE_SETLUID)
> /* Sets login uid for accounting */
> if (getluid() == -1 && setluid(pw->pw_uid) == -1)
> error("setluid: %s", strerror(errno));
> # endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */
>
> 'Configure' did define both HAVE_GETLUID and HAVE_SETLUID to 1.
Then getluid() isn't returning -1. That means that sshd is running with
an LUID. How is it started -- by inetd? Then inetd must be running
with an LUID, and that's bad...
To check the LUID of a live process:
# ps -fp1,1309
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Apr-24 ? 00:00:07 /etc/init
belal 1309 1308 0 Apr-25 ttyp0 00:00:01 -ksh
# crash
> p #1 #1309
PROC TABLE SIZE = 130
SLOT ST PID PPID PGRP UID PRI CPU EVENT NAME FLAGS
1 s 1 0 0 0 66 0 u init load
74 s 1309 1308 1309 12039 73 0 proc+0x6370 ksh load ntrc
^^ SLOT NUMBER -- convert to hex == 1, 4A
> quit
# scodb
scodb> secinfo[1].si_luid_set
0 <-- process's LUID is not set
scodb> secinfo[4A].si_luid_set
1 <-- process's LUID is set
scodb> secinfo[4A].si_luid
2F07 <-- process's LUID is 0x2F07 = 12039
scodb> quit
>Bela<
Bela Lubkin
> As for luid, I see code that reads:
> # if defined(HAVE_GETLUID) && defined(HAVE_SETLUID)
> /* Sets login uid for accounting */
> if (getluid() == -1 && setluid(pw->pw_uid) == -1)
> error("setluid: %s", strerror(errno));
> # endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */
>
> 'Configure' did define both HAVE_GETLUID and HAVE_SETLUID to 1.
I forgot -- it shouldn't need to do this (and might be harmful, I'm not
sure) if it's using login.
>Bela<
Jean-Pierre Radley
|
| Then getluid() isn't returning -1. That means that sshd is running with
| an LUID. How is it started -- by inetd? Then inetd must be running
| with an LUID, and that's bad...
It's *normally* started by an rc2.d script, not from inetd.
But your question reminded me that since yesterday, as I've changed
sshd_config and/or recompiled ssh/sshd with assorted hacks to the source
code, I was repeatedly commanding '/etc/init.d/ssh stop' (or start).
If sshd is launched that way, a login's luid is always that of root.
So I rebooted so that sshd started from the /etc/rc2.d script (linked,
as is typical, to the /etc/init.d script), and now, with 'UseLogin no',
things look hunkier and dorier:
jpradley:jpr 26> ssh localhost
jpr@localhost's password:
You have mail
Agent pid 1627
jpradley:jpr 1> id -l
uid=201(jpr) gid=3(sys) luid=201(jpr) groups=3(sys),50(group)
^^^ <- quod erat desideratum
jpradley:jpr 2> prwarn
jpradley:jpr 3> exit
logout
unset SSH_AUTH_SOCK;
unset SSH_AGENT_PID;
echo Agent pid 1627 killed;
Connection to localhost closed.
jpradley:jpr 27>
Please try it yourself.
--
JP
Darryl Krasman
> I was repeatedly commanding '/etc/init.d/ssh stop' (or start).
>
> If sshd is launched that way, a login's luid is always that of root.
If I am stopping/starting sshd then I have an inittab entry such as:
sshd:c:once:/etc/rc2.d/S99sshd
then I:
# init c
This will start sshd without LUID set just as running from /etc/rc2.d
does.
--
Darryl Krasman
Ideal Computer Group Inc.
Bill Andersen
thread, I've got SSH working fine. Thanks everyone for all the help.
However, while search through the SCO knowledgebase, I ran across
the article below and wondered what the difference between the openSSH
you have available and the one off the caldera site would be?
http://stage.caldera.com/cgi-bin/ssl_reference?117533
It is the only reference to openSSH I can find at the SCO/Caldera
site, but it looks like they have an installable module for openSSH
that might have a security fix... any thoughts?
Just curious.
Bill
Bela Lubkin
> Jean-Pierre Radley wrote:
> > I was repeatedly commanding '/etc/init.d/ssh stop' (or start).
> >
> > If sshd is launched that way, a login's luid is always that of root.
>
> If I am stopping/starting sshd then I have an inittab entry such as:
>
> sshd:c:once:/etc/rc2.d/S99sshd
>
> then I:
>
> # init c
>
> This will start sshd without LUID set just as running from /etc/rc2.d
> does.
See sd(ADM). You can set up multiple such commands in
/tcb/files/no_luid/cmdtable and start them with e.g. `sd sshd`. init(M)
only offers the three lettes a/b/c, so it's pretty limiting.
>Bela<
Jean-Pierre Radley
| JP, I downloaded your tar file and using other info off this
| thread, I've got SSH working fine. Thanks everyone for all the help.
|
| However, while search through the SCO knowledgebase, I ran across
| the article below and wondered what the difference between the openSSH
| you have available and the one off the caldera site would be?
|
| http://stage.caldera.com/cgi-bin/ssl_reference?117533
|
| It is the only reference to openSSH I can find at the SCO/Caldera
| site, but it looks like they have an installable module for openSSH
| that might have a security fix... any thoughts?
All the security fixes alluded to in that TA are also in my binary, and
to boot, mine was compiled with yet another security patch (in zlib)
which came out just as Caldera was releasing that CSSA.
--
JP
Darryl Krasman
> See sd(ADM).
Will do, thanks.