Bug 144395
| Summary: | REMOTEHOST not always set correctly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lars Damerow <lars> | ||||
| Component: | tcsh | Assignee: | Miloslav Trmač <mitr> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Bill Huang <bhuang> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 2 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-04-16 13:33:35 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 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... What shell are you using? We use tcsh, version 6.12-8. cheers, lars 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. 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 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. 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 "[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? 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 I just had this happen from a machine where I know I closed the session properly. 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 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. cheers, lars 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. |
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.