Mailing List Archive

On Wed, Mar 04, 2009 at 04:38:18PM -0700, Jialing Liang wrote:
> I have ssh login to two Linux - Openssh server. They share one $Home
> directory. server1 runs Redhat 3 with Openssh 3.6.1 and sever2 runs
> Redhat 5 with Openssh 4.3

You probably mean Red Hat Enterprise, not Red Hat. Red Hat 5.x (December
1997) is unlikely to have such a new version of OpenSSH, and Red Hat 3.x
is pretty ancient (May 1996).

> The problem is: If I type "ssh server1 set" in a local host it shows the
> variable defined in $HOME/.kshrc. However, the "ssh server2 set" does
> not show the variable defined in the same $HOME/.kshrc file.

Check the user's shell and make sure it's actually ksh.

> $ cat $HOME/.ssh/environment
> ENV=$HOME/.kshrc

If the user's shell is (for example) bash or sh or csh, this variable
won't have any effect.

On Wed, 2009-03-04 at 16:38 -0700, Jialing Liang wrote:
> I have ssh login to two Linux - Openssh server. They share one $Home
> directory. server1 runs Redhat 3 with Openssh 3.6.1 and sever2 runs
> Redhat 5 with Openssh 4.3
>
> The problem is: If I type "ssh server1 set" in a local host it shows the
> variable defined in $HOME/.kshrc. However, the "ssh server2 set" does
> not show the variable defined in the same $HOME/.kshrc file. How can I
> make the server2 works the same as server1? Here the user name in local,
> svrever1 and server2 are the same.
>
> Settings of both server1 and server2:
>
> # cat /etc/ssh/sshd_config | grep PermitUserEnvironment
> PermitUserEnvironment yes
>
>
> $ cat $HOME/.ssh/environment
> ENV=$HOME/.kshrc
>
> $ cat $HOME/.kshrc
> LIC_HOST=licserv; export LIC_HOST;
>
>
> Results of ssh command:
>
> localhost$ ssh server1 echo $LIC_HOST
> licserv
> localhost$ ssh server2 echo $LIC_HOST
>
>
> Thanks in advance for any discussions.
>
> Jialing Liang

Silly question, I know - but given that they're Redhat boxes - have you
double-checked the account shell on the 'broken' box is /bin/ksh and
not /bin/bash? In the latter case, that .kshrc would not get sourced
without manual intervention.

--
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org>
* Unix SysAdmin / Data Center & Servers / Enterprise Technology
* Providence Health & Services, 11308 SW 68th Parkway, Tigard, OR 97223
*/


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.

Glad to discuss with you again.

>You probably mean Red Hat Enterprise, not Red Hat.
You are right. It should be "Red Hat Enterprise Linux".

>Check the user's shell and make sure it's actually ksh.
It is ksh:
Localhost$ ssh server1 echo $SHELL
/usr/bin/ksh
Localhost$ ssh server2 echo $SHELL
/usr/bin/ksh

Jialing

-----Original Message-----
From: Greg Wooledge [mailto:wooledg@eeg.ccf.org]
Sent: Thursday, March 05, 2009 10:56 AM
To: Jialing Liang
Cc: secureshell@securityfocus.com
Subject: Re: Activity of the $HOME/.kshrc

On Wed, Mar 04, 2009 at 04:38:18PM -0700, Jialing Liang wrote:
> I have ssh login to two Linux - Openssh server. They share one $Home
> directory. server1 runs Redhat 3 with Openssh 3.6.1 and sever2 runs
> Redhat 5 with Openssh 4.3

You probably mean Red Hat Enterprise, not Red Hat. Red Hat 5.x
(December
1997) is unlikely to have such a new version of OpenSSH, and Red Hat 3.x
is pretty ancient (May 1996).

> The problem is: If I type "ssh server1 set" in a local host it shows
the
> variable defined in $HOME/.kshrc. However, the "ssh server2 set" does
> not show the variable defined in the same $HOME/.kshrc file.

Check the user's shell and make sure it's actually ksh.

> $ cat $HOME/.ssh/environment
> ENV=$HOME/.kshrc

If the user's shell is (for example) bash or sh or csh, this variable
won't have any effect.

On Thu, Mar 05, 2009 at 11:43:39AM -0700, Jialing Liang wrote:

> > I have ssh login to two Linux - Openssh server. They share one $Home
> > directory. server1 runs Redhat 3 with Openssh 3.6.1 and sever2 runs
> > Redhat 5 with Openssh 4.3

> >Check the user's shell and make sure it's actually ksh.
> It is ksh:
> Localhost$ ssh server1 echo $SHELL
> /usr/bin/ksh
> Localhost$ ssh server2 echo $SHELL
> /usr/bin/ksh

In that case, look for the manuals for OpenSSH 3.6.1 and 4.3 and make
sure the features you're relying on (~/.ssh/environment) are actually
available in both versions. Also, check the server configs to make
sure PermitUserEnvironment is set to yes (the default is ``no'').

There is no difference in login process for both version's sshd manual:

LOGIN PROCESS
When a user successfully logs in, sshd does the following:

1. If the login is on a tty, and no command has been
specified,
prints last login time and /etc/motd (unless prevented
in
the configuration file or by ~/.hushlogin; see the FILES
section).

2. If the login is on a tty, records login time.

3. Checks /etc/nologin; if it exists, prints contents and
quits
(unless root).

4. Changes to run with normal user privileges.

5. Sets up basic environment.

6. Reads the file ~/.ssh/environment, if it exists, and
users
are allowed to change their environment. See the
PermitUserEnvironment option in sshd_config(5).

7. Changes to user's home directory.

8. If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc
exists,
runs it; otherwise runs xauth. The ``rc'' files are
given
the X11 authentication protocol and cookie in standard
input.
See SSHRC, below.

9. Runs user's shell or command.


The fact is if I do a "real" login (ssh without command), server2 has
the variable be set:

Localhost$ ssh server2 echo $LIC_HOST

Localhost$ ssh server2
$ hostname
server2
$ cat $HOME/.kshrc
LIC_HOST=licserv; export LIC_HOST;
$ echo $LIC_HOST
licserv

When running "ssh ssh_server command", I guess the difference between
the two versions is at step 9, where server1 runs the command with
user's shell but server2 runs the command with a "default shell".

I am not sure how the latest Openssh dose on this point. If the user can
not specify different environment/shell variables for different server
when doing "ssh ssh_server command", that is a restriction for remote
application submission.

Jialing


-----Original Message-----
From: Greg Wooledge [mailto:wooledg@eeg.ccf.org]
Sent: Thursday, March 05, 2009 11:54 AM
To: Jialing Liang
Cc: secureshell@securityfocus.com
Subject: Re: Activity of the $HOME/.kshrc

On Thu, Mar 05, 2009 at 11:43:39AM -0700, Jialing Liang wrote:

> > I have ssh login to two Linux - Openssh server. They share one $Home
> > directory. server1 runs Redhat 3 with Openssh 3.6.1 and sever2 runs
> > Redhat 5 with Openssh 4.3

> >Check the user's shell and make sure it's actually ksh.
> It is ksh:
> Localhost$ ssh server1 echo $SHELL
> /usr/bin/ksh
> Localhost$ ssh server2 echo $SHELL
> /usr/bin/ksh

In that case, look for the manuals for OpenSSH 3.6.1 and 4.3 and make
sure the features you're relying on (~/.ssh/environment) are actually
available in both versions. Also, check the server configs to make
sure PermitUserEnvironment is set to yes (the default is ``no'').

On Thu, Mar 05, 2009 at 03:35:08PM -0700, Jialing Liang wrote:
> There is no difference in login process for both version's sshd manual:
>
> LOGIN PROCESS
> [...]
> 6. Reads the file ~/.ssh/environment, if it exists, and
> users
> are allowed to change their environment. See the
> PermitUserEnvironment option in sshd_config(5).

> The fact is if I do a "real" login (ssh without command), server2 has
> the variable be set:
>
> Localhost$ ssh server2 echo $LIC_HOST
>

Here, you can see evidence that it is NOT in fact reading ~/.ssh/environment.
Compare with what I have:

imadev:~/.ssh$ grep Environment /usr/local/etc/sshd_config
PermitUserEnvironment yes
imadev:~/.ssh$ cat environment
JUBJUB=bandersnatch
imadev:~/.ssh$ ssh localhost 'echo $JUBJUB'
wooledg@localhost's password:
bandersnatch


> Localhost$ ssh server2
> $ hostname
> server2
> $ cat $HOME/.kshrc
> LIC_HOST=licserv; export LIC_HOST;
> $ echo $LIC_HOST
> licserv

In this second example, you are running an actual Korn shell, which
reads ~/.kshrc simply because it is a Korn shell -- not because it
was told to by ~/.ssh/environment. (Actually this depends on the
version of Korn shell. In ksh88, you must explicitly set ENV; in
ksh93, ENV has a default value of $HOME/.kshrc if you don't set ENV.
But you might also have set ENV=$HOME/.kshrc in your .profile which
you haven't shown.)

So, I still believe you've forgotten to set PermitUserEnvironment to yes.

>>Silly question, I know - but given that they're Redhat boxes - have
you
>>double-checked the account shell on the 'broken' box is /bin/ksh and
>>not /bin/bash? In the latter case, that .kshrc would not get sourced
>>without manual intervention.

I am not so low level as unable to tell ksh and bash.


-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of Kevin Brott
Sent: Thursday, March 05, 2009 11:00 AM
To: secureshell@securityfocus.com
Subject: Re: Activity of the $HOME/.kshrc

On Wed, 2009-03-04 at 16:38 -0700, Jialing Liang wrote:
> I have ssh login to two Linux - Openssh server. They share one $Home
> directory. server1 runs Redhat 3 with Openssh 3.6.1 and sever2 runs
> Redhat 5 with Openssh 4.3
>
> The problem is: If I type "ssh server1 set" in a local host it shows
the
> variable defined in $HOME/.kshrc. However, the "ssh server2 set" does
> not show the variable defined in the same $HOME/.kshrc file. How can I
> make the server2 works the same as server1? Here the user name in
local,
> svrever1 and server2 are the same.
>
> Settings of both server1 and server2:
>
> # cat /etc/ssh/sshd_config | grep PermitUserEnvironment
> PermitUserEnvironment yes
>
>
> $ cat $HOME/.ssh/environment
> ENV=$HOME/.kshrc
>
> $ cat $HOME/.kshrc
> LIC_HOST=licserv; export LIC_HOST;
>
>
> Results of ssh command:
>
> localhost$ ssh server1 echo $LIC_HOST
> licserv
> localhost$ ssh server2 echo $LIC_HOST
>
>
> Thanks in advance for any discussions.
>
> Jialing Liang

Silly question, I know - but given that they're Redhat boxes - have you
double-checked the account shell on the 'broken' box is /bin/ksh and
not /bin/bash? In the latter case, that .kshrc would not get sourced
without manual intervention.

--
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org>
* Unix SysAdmin / Data Center & Servers / Enterprise Technology
* Providence Health & Services, 11308 SW 68th Parkway, Tigard, OR 97223
*/


DISCLAIMER:
This message is intended for the sole use of the addressee, and may
contain information that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the addressee you are
hereby notified that you may not use, copy, disclose, or distribute to
anyone the message or any information contained in the message. If you
have received this message in error, please immediately advise the
sender by reply email and delete this message.

On Fri, 2009-03-06 at 10:33 -0700, Jialing Liang wrote:
> >> Silly question, I know - but given that they're Redhat boxes - have you
> >> double-checked the account shell on the 'broken' box is /bin/ksh and
> >> not /bin/bash? In the latter case, that .kshrc would not get sourced
> >> without manual intervention.
>
> I am not so low level as unable to tell ksh and bash.

Please don't misunderstand, I was not questioning your skill. The
default shell is /bin/bash on RedHat systems, and mistakes happen.

However, based on your reply to Greg, if the shell is /bin/ksh on both
systems, then I think Greg is on the right track. I would do a diff
on /etc/ssh/sshd_config for each system and see if there are differences
in the ssh daemon config.

--
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org>
* Unix SysAdmin / Data Center & Servers / Enterprise Technology
* Providence Health & Services, 11308 SW 68th Parkway, Tigard, OR 97223
*/


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.

>I would do a diff on /etc/ssh/sshd_config for each system and see if
there >are differences in the ssh daemon config.

I have done a differ:
$ diff sshd_config.svrver1 sshd_config.svrver2 > diff.sshd_config

But I can not see anything related to this issue. The diff.sshd_config
file is attached.

Jialing

-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of Kevin Brott
Sent: Friday, March 06, 2009 11:07 AM
To: secureshell@securityfocus.com
Subject: RE: Activity of the $HOME/.kshrc

On Fri, 2009-03-06 at 10:33 -0700, Jialing Liang wrote:
> >> Silly question, I know - but given that they're Redhat boxes - have
you
> >> double-checked the account shell on the 'broken' box is /bin/ksh
and
> >> not /bin/bash? In the latter case, that .kshrc would not get
sourced
> >> without manual intervention.
>
> I am not so low level as unable to tell ksh and bash.

Please don't misunderstand, I was not questioning your skill. The
default shell is /bin/bash on RedHat systems, and mistakes happen.

However, based on your reply to Greg, if the shell is /bin/ksh on both
systems, then I think Greg is on the right track. I would do a diff
on /etc/ssh/sshd_config for each system and see if there are differences
in the ssh daemon config.

--
#include <stddisclaimer.h>
/* Kevin Brott <Kevin.Brott@Providence.org>
* Unix SysAdmin / Data Center & Servers / Enterprise Technology
* Providence Health & Services, 11308 SW 68th Parkway, Tigard, OR 97223
*/


DISCLAIMER:
This message is intended for the sole use of the addressee, and may
contain information that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the addressee you are
hereby notified that you may not use, copy, disclose, or distribute to
anyone the message or any information contained in the message. If you
have received this message in error, please immediately advise the
sender by reply email and delete this message.