On Thu, Oct 06, 2005 at 10:00:59PM +0300, Alexander Gattin <[EMAIL PROTECTED]> wrote: > > What are versions of dash, rsh-client and rsh-server > > used? > > Do you use rsh-redone-server or rsh-server? > Do you use rsh-redone-client or rsh-client? > What is in your /etc/pam.d/rsh? /etc/pam.d/rlogin?
My original report is somewhat confusing, I see now, as I only tested rlogin (rsh without a command), so rsh should not matter, here is pam.d/rsh: # # The PAM configuration file for the rsh (Remote Shell) service # # Due to limitations in the rsh protocol, modules depending on the conversation # function to work cannot be used. This includes authentication modules such # as pam_unix.so. auth required pam_rhosts_auth.so suppress no_hosts_equiv auth required pam_nologin.so auth required pam_env.so account required pam_unix_acct.so session required pam_limits.so session required pam_unix_session.so And here is pam.d/rlogin (as given earlier): #%PAM-1.0 #auth requisite pam_securetty.so auth sufficient pam_rhosts_auth.so suppress no_hosts_equiv auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_unix.so nullok use_authtok obscure min=4 max=8 session required pam_unix.so If it matters, I also use .rhosts-based authentication. > > > > Oct 5 06:12:36 cerebro in.rlogind: Connection from [EMAIL > > > > PROTECTED] for root > > Well, I don't have such lines from in.rlogind in > my auth.log (I try on localhost)... That was due to rsh-redone-server (sorry again, I was convinced I had it replaced everywhere). With rsh-server, it looks like this: Oct 7 07:43:26 cerebro pam_rhosts_auth[25505]: allowed to [EMAIL PROTECTED] as root Oct 7 07:43:26 cerebro login[25506]: (pam_unix) session opened for user root by (uid=0) Oct 7 07:43:26 cerebro login[25507]: ROOT LOGIN on `pts/7' from `fuji' > > > > "/dev/pts/1" looks like a perfectly fine tty name to me. Subsequent rsh > > > > calls work fine. > > Subsequent rsh calls _on /dev/pts/1_? Can't say, but very likely uses a different tty name. I also grepped through my logs: Oct 5 06:12:36 cerebro login[453]: unable to determine TTY name, got /dev/pts/1 Sep 23 02:42:46 cerebro login[453]: unable to determine TTY name, got /dev/pts/2 Sep 22 14:00:34 cerebro login[453]: unable to determine TTY name, got /dev/pts/2 Sep 20 12:36:59 cerebro login[453]: unable to determine TTY name, got /dev/pts/2 May 18 15:00:03 cerebro login[442]: unable to determine TTY name, got /dev/pts/1 Apr 25 06:44:50 cerebro login[601]: unable to determine TTY name, got /dev/tty3 Mar 18 14:20:37 cerebro login[468]: unable to determine TTY name, got /dev/pts/4 Feb 24 13:25:00 cerebro login[443]: unable to determine TTY name, got /dev/pts/2 Feb 18 11:56:16 cerebro login[483]: unable to determine TTY name, got /dev/pts/4 Feb 1 14:09:13 cerebro login[411]: unable to determine TTY name, got /dev/pts/2 Jan 21 17:18:24 cerebro login[465]: unable to determine TTY name, got /dev/pts/3 Nov 29 13:48:43 cerebro login[462]: unable to determine TTY name, got /dev/tty5 Sep 30 13:36:22 cerebro login[394]: unable to determine TTY name, got /dev/pts/0 Sep 14 22:41:27 cerebro login[404]: unable to determine TTY name, got /dev/pts/0 Sep 14 22:34:23 cerebro login[404]: unable to determine TTY name, got /dev/pts/0 Aug 31 12:35:40 cerebro login[378]: unable to determine TTY name, got /dev/pts/1 Aug 29 10:19:51 cerebro login[378]: unable to determine TTY name, got /dev/pts/1 Jul 28 14:05:28 cerebro login[402]: unable to determine TTY name, got /dev/pts/86 Jul 12 17:20:03 cerebro login[552]: unable to determine TTY name, got /dev/tty5 As you can see, it's not exactly a frequent message, and seems independent of the actual tty name and mostly of the login version (I upgrade at least once/week, and one system is mostly following testing, the other unstable). However, I was under the impression that the problem occurs slightly more often than the message, but such impressions might or might not be wrong, I certainly don't remember for sure. It also "haunts" me for a long time, although it wasn't exactly pressing enough to report it, because I cannot reproduce it. I thought the message would help finding the problem, but ... :) > Marc, could you shed more light on your configuration, > please? Anything you want to know! The only thing I cannot provide is quick reproducability, as it works most of the time (you can assume that I log-in after reboot daily). Also, it happens even when the machine was already up for, say, 10 minutes, so it doesn't seem like a race between login and the boot sequence. -- 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]