Bug 144395 - REMOTEHOST not always set correctly
REMOTEHOST not always set correctly
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: tcsh (Show other bugs)
2
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
Bill Huang
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-06 14:02 EST by Lars Damerow
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 09:33:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The output of utmpdump /var/run/utmp from a misbehaving shell. (2.86 KB, text/plain)
2005-03-07 21:30 EST, Lars Damerow
no flags Details

  None (edit)
Description Lars Damerow 2005-01-06 14:02:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5)
Gecko/20041203 Firefox/1.0

Description of problem:
For some of our users, the REMOTEHOST variable sometimes gets set to
a remote machine even though the users are just opening new shells on
their own desktop machines.

How does REMOTEHOST get set by default on Fedora? I looked at
pam_env.conf, but it's not setting REMOTEHOST there.

Version-Release number of selected component (if applicable):
gnome-terminal-2.6.0-2

How reproducible:
Sometimes

Steps to Reproduce:
1. open a new gnome terminal
2. echo $REMOTEHOST

    

Actual Results:  Sometimes REMOTEHOST is set and contains the wrong
machine. That
machine is usually one particular machine--MY machine, unfortunately
for me.

Expected Results:  REMOTEHOST should never be set if the user is just
opening shells on
their own desktop.

Additional info:

It's certainly possible that I've done something stupid in configuring
these machines, but I haven't done anything pertaining to REMOTEHOST
directly.
Comment 1 Lars Damerow 2005-01-25 16:07:20 EST
Any ideas on this? It still happens with a pretty high frequency?

If I could just have a hint as to how REMOTEHOST gets set, I can take
it from there.
Comment 2 Lars Damerow 2005-01-31 18:15:39 EST
We've found a little more information--it seems to be related to
previous logins on the machine. I haven't completely replicated the
problem yet, but it seems like when it occurs, REMOTEHOST is getting
set to the IP someone logged in from remotely before the local session
began.

It's likely to target my machine most often, since I'm the administrator
of these boxes and log into them over ssh all the time.

Sooo.... any hints or suggestions would be appreciated...
Comment 3 Ray Strode [halfline] 2005-02-01 17:51:12 EST
What shell are you using?
Comment 4 Lars Damerow 2005-02-01 17:54:21 EST
We use tcsh, version 6.12-8.

cheers,
lars
Comment 5 Ray Strode [halfline] 2005-02-07 11:27:54 EST
Hi,
So the tcsh man page says:

"[REMOTEHOST] The host from which the user has logged in remotely, if
this is the case and the shell is able to determine it."

It seems like in this case it's determining it incorrectly.  

I'm going to reassign this bug to the tcsh component.
Comment 6 Miloslav Trmač 2005-02-25 10:50:14 EST
Could you please attach the result of (utmpdump /var/log/utmp) when this happens?
Also a full strace of a tcsh (since the tcsh start) when this happens could
be useful, but probably harder to get.

Another possibility is misconfigured DNS - tcsh attempts to convert the
host name in utmp to the host's canonical name.
Comment 7 Lars Damerow 2005-02-25 12:26:01 EST
Will do. Thanks!
Comment 8 Lars Damerow 2005-03-07 21:29:53 EST
I finally got a utmpdump from a misbehaving shell. I'll attach it here. The IP
of the machine it's from is 138.72.19.119, and REMOTEHOST got incorrectly set to
138.72.42.169. An admin had logged into 138.72.19.119 remotely from
138.72.42.169 not long beforehand.
Comment 9 Lars Damerow 2005-03-07 21:30:55 EST
Created attachment 111766 [details]
The output of utmpdump /var/run/utmp from a misbehaving shell.
Comment 10 Lars Damerow 2005-03-08 20:32:53 EST
I have a couple more examples of utmpdump output; let me know if they'd be
helpful and I'll attach them.
Comment 11 Miloslav Trmač 2005-03-13 07:25:34 EST
Thanks for the dump, it makes the problem (but not the bug) obvious.
If other dumps are similar (several "valid", i.e. starting with "[7]", entries
for the same TTY), attaching them is not necessary.

The main question is why the admin's record was not marked as invalid;
This doesn't happen during normal work on my FC2 machine. Did the admin
disconnect in any unusual way (e.g. going offline without closing the session,
or killing the server process)?

I assume the admin connected using openssh; if so, what is the version of
the openssh-server RPM? Are you using privilege separation?
Comment 12 Lars Damerow 2005-03-14 12:25:08 EST
I did indeed connect with openssh; the openssh-server version is
openssh-server-3.6.1p2-34. We're not using privilege separation.

I'm usually pretty good about closing my sessions, and I haven't had to kill
sshd on any of these machines recently. I can't speak for the other admins, but
they're likely doing the same things I am.

Thanks,
lars
Comment 13 Lars Damerow 2005-03-14 16:31:20 EST
I just had this happen from a machine where I know I closed the session properly.
Comment 14 Lars Damerow 2005-03-23 12:41:38 EST
Hello,

Any progress on this one? I hate to be a pest, but this is happening with a
pretty high frequency for us.

Thanks!
-lars
Comment 15 Miloslav Trmač 2005-04-15 14:43:11 EDT
Sorry, I can't reproduce any utmp problems with FC2 and that version of
openssh, with or without privilege separation. Our openssh maintainer
suggested asking you to try to reproduce this on FC3.
Comment 16 Lars Damerow 2005-04-15 14:47:35 EDT
Thanks for trying! I've distributed more recent versions of openssh and tcsh to
our machines. Hopefully that'll help; since I can't upgrade all of the machines
to FC3 and this problem is intermittent, I can't make a reliable FC3 test case.

cheers,
lars
Comment 17 Miloslav Trmač 2005-04-16 09:33:35 EDT
I have sent a workaround (http://bugs.gw.com/view.php?id=17) for consideration
upstream. I'm not sure whether it will be accepted, working around this bug
may cause wrong behavior in presence of other bugs.

Note You need to log in before you can comment on or make changes to this bug.