Red Hat Bugzilla – Bug 144395
REMOTEHOST not always set correctly
Last modified: 2007-11-30 17:10:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5)
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):
Steps to Reproduce:
1. open a new gnome terminal
2. echo $REMOTEHOST
Actual Results: Sometimes REMOTEHOST is set and contains the wrong
machine is usually one particular machine--MY machine, unfortunately
Expected Results: REMOTEHOST should never be set if the user is just
opening shells on
their own desktop.
It's certainly possible that I've done something stupid in configuring
these machines, but I haven't done anything pertaining to REMOTEHOST
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.
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
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...
What shell are you using?
We use tcsh, version 6.12-8.
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.
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.
Will do. Thanks!
I finally got a utmpdump from a misbehaving shell. I'll attach it here. The IP
of the machine it's from is 188.8.131.52, and REMOTEHOST got incorrectly set to
184.108.40.206. An admin had logged into 220.127.116.11 remotely from
18.104.22.168 not long beforehand.
Created attachment 111766 [details]
The output of utmpdump /var/run/utmp from a misbehaving shell.
I have a couple more examples of utmpdump output; let me know if they'd be
helpful and I'll attach them.
Thanks for the dump, it makes the problem (but not the bug) obvious.
If other dumps are similar (several "valid", i.e. starting with "", 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?
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.
I just had this happen from a machine where I know I closed the session properly.
Any progress on this one? I hate to be a pest, but this is happening with a
pretty high frequency for us.
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.
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.
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.