Re: cvs login failure

[luke]

(Oops.  Thought I had sent this off days ago...  Sorry.)

Some interesting news, below.  Good but puzzling.

On 18 Oct, Derek R. Price wrote:
>  address@hidden wrote:
>  
> > I did a strings on the Windows cvs.exe and on /usr/bin/cvs on Linux,
> > and both have CVS_CLIENT_LOG, so I assume the facility works similarly
> > as in the source to cvs 1.10.8 that I have handy: it just opens
> > $CVS_CLIENT_LOG.in and $CVS_CLIENT_LOG.out and writes in there.
>  
>  No, that's about it.  I'm not sure what shell you are using, but in Bourne, 
> Bash, and
>  Korn, you need to export environment variables for a child process to see 
> them:

Sure.  That's why I said I "exported" CVS_CLIENT_LOG.

>  Whoops.   Just checked myself and CVS doesn't start writing to the client 
> log until
>  after authentication, probably for the obvious reasons, but it does work 
> under both
>  Linux & Windows in 1.11.

So wouldn't get any debug for the part that's going wrong, anyway.

>  Anyway, I'd say your options are compiling a debug version under Windows and
>  attempting to trace the failed attempt or figure out what the difference 
> between your
>  Windows & Linux CVSROOT specs are, since the Linux version worked.

I'll admit that it seems difficult to see how to setup the cvs server
to be run from gdb.  Hmm, maybe I could attach to it once it was
running...

>  Is LOGNAME set
>  differently on the two machines?

No.

>  Try a CVSROOT with no variables in it.  CVS
>  shouldn't be filling anything into CVSROOT on either platform, so if the 
> problem lies
>  there you should be able to fix it on the command line.

I think that's a small red herring.  I tried without a CVSROOT, using
the -d option, with the same result.

>  Also, try again to make sure that handy's IP address is the same regardless 
> of which
>  machine you look it up on.

Handy is defunct; "mantovani" is the stand-in.  There is an amd entry
so that /home/handy is the same as /home/mantovani.  But our network is
solid and clean, and I'd be flabbergasted if mantovani's IP address
changed while the machine was running (the IP addresses are assigned
dynamically from a server).

And now for the good but puzzling news.  It's now working.

Now, keep in mind that this all used to work when Handy was alive; and
failed when Mantovani replaced it.  Both were running the same version
of Linux with the same versions of the same utilities installed.

Also involved is an old version of ssh compiled for Windows.

The problem only occurs if we don't explicitly specify the login id when
we make the ssh connection from the Windows box to the Linux CVS
server.  The ssh login succeeds, but when we later try to cvs login,
the cvs server on the Linux box rejects the login with the message
"authentication failure".

The mechanism works like this - let me use Win to stand for the Windows
client and Lin for the Linux server:

On Win we do: ssh -L 2401:localhost:2401 Lin

I gather this makes a loopback connection on port 2401 on localhost
(Win),  talking to a 2nd loopback ssh connection on port 2401 on Lin,
and because of our /etc/{services,inetd.conf} and pserver CVSROOT, cvs
talks via ssh.

With the ssh -l $LOGNAME it all works.  Without the -l $LOGNAME we get
the "authentication failure" error when the windows user tries to cvs
login - *even though the ssh login works*.

Each user only has a single login id.

Puzzles are:

1) If the -l $LOGNAME is needed, why did it work at all previously?

2) How can the ssh login succeed but the cvs login fail?  Where does the
   cvs server get the login id from?  The client?  If so, how does the
   ssh login id affect it?

I twigged to this after trying a new ssh compiled under U/Win 2.25,
which just happens to default to using "<DOMAIN>/$LOGNAME" as the login
id.  This forced me to specify -l $LOGNAME to make even the ssh login
succeed.  And after that, the cvs login worked.

So, we're happy that it's now working, but don't really understand what
went wrong, or why it now works.

luke