Bug#332198: [Pkg-shadow-devel] Bug#332198: login: unable to determine TTY name, got /dev/pts/1
On Wed, Oct 05, 2005 at 06:13:58PM +0200, Christian Perrier [EMAIL PROTECTED] wrote: Can you try reproducing this with login and passwd packages from sid ? It happens with this version, too: ii login 4.0.11.1-1 system login tools ii passwd 4.0.11.1-1 change and administer password and group data If you want, I can test with 4.0.12 if there are important changes between 4.0.11 and .12. It also seems that you're trying to rsh from root to root on another host. Yes. Despite being highly insecure, Despite this being untrue and not substantiatable, people like to repeat this kind of non-fact often, just like parrots :) What might be insecure is not rsh, but, say, your root-password, or your wire, or ..., but rsh/rlogin are not generally less secure than, say, ssh. Claiming it is does not improve security, because it only makes issues more confusing. If you meant that seriously, you should first understand what the insecurities are that are involved in remote login are, and it's not the rlogin protocol. At least ssh is not generally more secure (it supports the same modes of authentication, and not every wire can be tapped, nor does tapping, in generally, lower the security of rsh/rlogin), and people don't complain about ssh being highly insecure, either. have you checked the contents of /etc/securetty on the target machine? It does not contain any pts/* entries, but that doesn't matter, because my pam.d/rlogin file looks like this (should have attached it to the original report, sorry), and has securetty checks disabled: #%PAM-1.0 #auth requisite pam_securetty.so authsufficient pam_rhosts_auth.so suppress no_hosts_equiv authrequiredpam_unix.so nullok authrequiredpam_nologin.so account requiredpam_unix.so passwordrequiredpam_unix.so nullok use_authtok obscure min=4 max=8 session requiredpam_unix.so I actually think that the unable to determine TTY name from login is maybe not *the* cause of the problem. That might very well be. I do not see that message, however, when it works (probably 99.999% of the time), and I have the syslog from my machines onscreen most of the time, so it is at least a hint on the problem, even if it's just another symptom. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332198: [Pkg-shadow-devel] Bug#332198: login: unable to determine TTY name, got /dev/pts/1
On Thu, Oct 06, 2005 at 01:58:05AM +0300, Alexander Gattin [EMAIL PROTECTED] wrote: What are versions of dash, rsh-client and rsh-server used? One both machines: ii dash 0.5.2-5The Debian Almquist Shell ii rsh-redone-server 66-1 Reimplementation of rshd and rlogind ii rsh-client 0.17-13rsh clients. It happens in either direction. I am myself a bit surprised that those two are still using rsh-redone-server (both rsh-redone-server and -client caused me much grieve on my production machines), and I'll switch to the standard rsh-server and rsh-client packages (the machines with the problem are my desktop machine and laptop, where I log in remotely less often). I also installed 1:4.0.12-6 versions of both passwd and login on both machines, and will have a look on the problem (it is hard to reproduce, though, as it only happens one every few weeks or so, at daily reboots). Can you try reproducing this with login and passwd packages from sid ? I tried with new login, rlogin-ed OK on pts/0 and pts/1... // sh - bash on my system BTW dash here, as you already knew :) -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332198: [Pkg-shadow-devel] Bug#332198: login: unable to determine TTY name, got /dev/pts/1
On Wed, Oct 05, 2005 at 06:13:58PM +0200, Christian Perrier [EMAIL PROTECTED] wrote: I actually think that the unable to determine TTY name from login is maybe not *the* cause of the problem. Lucky day: cerebro ~/pserv# fuji rlogin: connection closed. cerebro ~/pserv# apt-get install xmltv E: Could not get lock /var/lib/apt/lists/lock - open (11 Resource temporarily unavailable) E: Unable to lock the list directory [Exit 100] cerebro ~/pserv# [Exit 100] cerebro ~/pserv# fuji fuji ~# tail /var/log/messages Oct 7 07:51:22 fuji named[1126]: USAGE 1128664282 1128426682 CPU=0.050992u/0.041993s CHILDCPU=0.050992u/0.034994s Oct 7 07:51:22 fuji named[1126]: NSTATS 1128664282 1128426682 A=152 PTR=86 Oct 7 07:51:22 fuji named[1126]: XSTATS 1128664282 1128426682 RR=84 RNXD=7 RFwdR=12 RDupR=1 RFail=0 RFErr=0 RErr=1 RAXFR=0 RLame=0 ROpts=0 SSysQ=79 SAns=145 SFwdQ=103 SDupQ=840 SErr=34 RQ=238 RIQ=0 RFwdQ=103 RDupQ=16 RTCP=0 SFwdR=12 SFail=0 SFErr=0 SNaAns=127 SNXD=42 RUQ=0 RURQ=0 RUXFR=0 RUUpd=0 Oct 7 07:57:11 fuji pam_rhosts_auth[6540]: allowed to [EMAIL PROTECTED] as root Oct 7 07:57:11 fuji login[6541]: (pam_unix) session opened for user root by (uid=0) Oct 7 07:57:11 fuji login[6542]: ROOT LOGIN on `pts/10' from `cerebro' Oct 7 07:57:11 fuji login[6541]: (pam_unix) session closed for user root Oct 7 07:57:18 fuji pam_rhosts_auth[6547]: allowed to [EMAIL PROTECTED] as root Oct 7 07:57:18 fuji login[6548]: (pam_unix) session opened for user root by (uid=0) Oct 7 07:57:18 fuji login[6549]: ROOT LOGIN on `pts/10' from `cerebro' Just happened a few minutes ago: I tried to install xmltv on fuji, and as you can see the first try failed, the second worked. It was on the same tty, and long after bootup, and NOT the first login, and finally did not complain about the tty name. So there seem to be two problems, my log-in problem and a suboptimal error message, which are probably independent of each other. Unfortunately, that was before upgrading to 4.0.12, i.e. still with 4.0.3 (so far it happens with 4.0.11 and 4.0.3). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332198: [Pkg-shadow-devel] Bug#332198: login: unable to determine TTY name, got /dev/pts/1
Quoting Marc Lehmann ([EMAIL PROTECTED]): Package: login Version: 1:4.0.3-35 Severity: normal Directly after a fresh reboot eeboot, rsh rebooted-host results in an immediate connection close, and the syslog on the remote host says: Oct 5 06:12:36 cerebro in.rlogind: Connection from [EMAIL PROTECTED] for root Oct 5 06:12:36 cerebro pam_rhosts_auth[452]: allowed to [EMAIL PROTECTED] as root Oct 5 06:12:36 cerebro login[453]: (pam_unix) session opened for user root by root(uid=0) Oct 5 06:12:36 cerebro login[453]: unable to determine TTY name, got /dev/pts/1 Oct 5 06:12:36 cerebro in.rlogind[452]: Closing connection with [EMAIL PROTECTED] /dev/pts/1 looks like a perfectly fine tty name to me. Subsequent rsh calls work fine. I think at least the error message should be clearer, right now it is wrong, as it did correctly determine the tty name, and something else Can you try reproducing this with login and passwd packages from sid ? Etch (testing) currently still has the old 4.0.3 version we had in sarge and the gap with 4.0.12 which is in sid is huge. It also seems that you're trying to rsh from root to root on another host. Despite being highly insecure, have you checked the contents of /etc/securetty on the target machine? I actually think that the unable to determine TTY name from login is maybe not *the* cause of the problem.
Bug#332198: [Pkg-shadow-devel] Bug#332198: login: unable to determine TTY name, got /dev/pts/1
tags 332198 moreinfo thanks What are versions of dash, rsh-client and rsh-server used? On Wed, Oct 05, 2005 at 06:13:58PM +0200, Christian Perrier wrote: Quoting Marc Lehmann ([EMAIL PROTECTED]): Version: 1:4.0.3-35 Directly after a fresh reboot eeboot, rsh rebooted-host results in an immediate connection close, and the syslog on the remote host says: Oct 5 06:12:36 cerebro in.rlogind: Connection from [EMAIL PROTECTED] for root Oct 5 06:12:36 cerebro pam_rhosts_auth[452]: allowed to [EMAIL PROTECTED] as root Oct 5 06:12:36 cerebro login[453]: (pam_unix) session opened for user root by root(uid=0) Oct 5 06:12:36 cerebro login[453]: unable to determine TTY name, got /dev/pts/1 Oct 5 06:12:36 cerebro in.rlogind[452]: Closing connection with [EMAIL PROTECTED] /dev/pts/1 looks like a perfectly fine tty name to me. Subsequent rsh calls work fine. I think at least the error message should be clearer, right now it is wrong, as it did correctly determine the tty name, and something else Can you try reproducing this with login and passwd packages from sid ? I tried with new login, rlogin-ed OK on pts/0 and pts/1... // sh - bash on my system BTW I actually think that the unable to determine TTY name from login is maybe not *the* cause of the problem. But after RTFS, I think this error msg is really misleading... -- WBR, xrgtn
