Bug#332198: [Pkg-shadow-devel] login: unable to determine TTY name, got /dev/pts/1

Fri Oct 7 05:53:05 UTC 2005

On Thu, Oct 06, 2005 at 10:00:59PM +0300, Alexander Gattin <xrgtn at yandex.ru> 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 root at fuji 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 root at fuji 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
      ---==---(_)__  __ ____  __      pcg at goof.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE