cvs login failure
We had a Linux machine hosting a secure CVS archive, for some Windows and Linux development. Then the Linux PC died. Fortunately, the CVS archive was on its own drive, so we just put it into a 2nd Linux machine, and re-did all the ssh and inetd configuration. The Windows machines access the CVS archive via the pserver method, using ssh. The Linux machines just set CVSROOT to use the archive directory (it's auto-mounted). But the CVS archive isn't working for the Windows machines anymore; any attempt to do a cvs login gets the error below: CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive Started ssh, so now you need to cvs login: (Logging in to luke@localhost) CVS password: cvs [login aborted]: authorization failed: server localhost rejected access Is there any way to find out why the cvs client (or is it the server?) rejected the login? Is there any kind of logging information that can be examined? One fact that is probably a red herring, is that the window in which the ssh connection to the CVS server is made, displays errors like: $ DUPRE.: Connection to port 2401 forwarding to localhost:2401 requested. Address 127.0.0.1 maps to dupre, but this does not map back to the address - POSSIBLE BREAKIN ATTEMPT! But we used to get errors like this with the now-dead Linux PC, and everything worked fine. We're using cvs version 1.10.6 under Red Hat Linux 6.1, and the cvs client version is 1.10. The only change was the replacement of one Linux PC with another. Any suggestions? luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
On Fri, Oct 13, 2000 at 02:42:15PM +1100, Luke Kendall wrote: > But the CVS archive isn't working for the Windows machines anymore; > any attempt to do a cvs login gets the error below: > > CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive > Started ssh, so now you need to cvs login: > (Logging in to luke@localhost) > CVS password: > cvs [login aborted]: authorization failed: server localhost rejected access Wait. You are using ssh to log back into the Windows machine? (luke@localhost) That doesn't seem to make a lot of sense. Or were you just obscurring information there? Why don't you use :ext:luke@linuxhost:/home/mantovani/cvs-archive And set CVS_RSH to ssh. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
Luke Kendall writes: > > CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive > Started ssh, so now you need to cvs login: > (Logging in to luke@localhost) > CVS password: > cvs [login aborted]: authorization failed: server localhost rejected access > > Is there any way to find out why the cvs client (or is it the server?) > rejected the login? Is there any kind of logging information that can be > examined? Like the message says, it's the server that rejected the login. When you get just that message with no additional information, it means that either the user exists but the password didn't match, or the repository you specified does not match one of the --allow-root= arguments specified for the server (in /etc/inetd.conf, presumably). The current development version now has an additional message for the latter case, so you'll be able to tell which it is in the future. -Larry Jones Another casualty of applied metaphysics. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
> > Luke Kendall writes: > > > > CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive > > Started ssh, so now you need to cvs login: > > (Logging in to luke@localhost) > > CVS password: > > cvs [login aborted]: authorization failed: server localhost rejected access > > > > Is there any way to find out why the cvs client (or is it the server?) > > rejected the login? Is there any kind of logging information that can be > > examined? > > Like the message says, it's the server that rejected the login. When > you get just that message with no additional information, it means that > either the user exists but the password didn't match, If it was using the user CISRA/luke instead of luke (i.e. if for some reason it was insisting on using the Windows domain name plus user name), the password would fail to match. Is there any way to force it to use a specific user name? > or the repository > you specified does not match one of the --allow-root= arguments > specified for the server (in /etc/inetd.conf, presumably). No, it looks like: cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs --allow-root=/home/handy/cvs-archive pserver Although the machine "handy" died, and was replaced by "mantovani", the auto mounter has been adjusted to pretend matovani is handy. We also tried explicitly changing the inetd.conf to refer to mantovani, and killed inetd processes, but it made no difference. :-( > The current > development version now has an additional message for the latter case, > so you'll be able to tell which it is in the future. Sounds helpful. But are there any log messages we can use to find the exact username it was using? I'm suspicious of that. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
Mike Castle wrote: > On Fri, Oct 13, 2000 at 02:42:15PM +1100, Luke Kendall wrote: > > But the CVS archive isn't working for the Windows machines anymore; > > any attempt to do a cvs login gets the error below: > > > > CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive > > Started ssh, so now you need to cvs login: > > (Logging in to luke@localhost) > > CVS password: > > cvs [login aborted]: authorization failed: server localhost rejected access > > Wait. You are using ssh to log back into the Windows machine? > (luke@localhost) That doesn't seem to make a lot of sense. Or were you > just obscurring information there? No, that's exactly what I used; it's the output from a script wrapped around it that only starts an ssh connection to the cvs server machine if there isn't already one running, and also sets some environment variables. Fundamentally it does this: wterm sh -c "ssh -l $LOGNAME -L 2401:localhost:2401 mantovani" & CVSROOT=":pserver:$LOGNAME@localhost:/home/mantovani/cvs-archive" CVS_SERVER="/usr/bin/cvs" export CVS_SERVER cvs login This means that at localhost on the client, and on localhost on the server, an ssh connection to port 2401 is made. So all cvs communications are sent via ssh. We use this because we're working on a clean room project; it just happens to be the same system we use if working off site. > Why don't you use :ext:luke@linuxhost:/home/mantovani/cvs-archive > > And set CVS_RSH to ssh. See above. Plus, it used to work until we changed the CVS server from one Linux machine to another. And this way still works when talking to another server serving another CVS archive. A very significant fact: when logged into the cvs server, if we use CVSROOT=":pserver:$LOGNAME@localhost:/home/mantovani/cvs-archive" cvs login fails there! Doing a trace of it, all we see is the server sending the message "I HATE YOU". So the password validation appears to be failing. In summary: I think we're using ssh for good reasons; it used to work; changing from one Linux machine to another (and re-doing the config) stopped it working; we can still use the technique to talk to another server serving another CVS archive. Any hints about how we diagnose this? Does cvs provide any verbose logging or debug mode? AFAIK, cvs login takes no options. My next step otherwise will be to modify the cvs source to generate some information to trace what's going on. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
Luke Kendall wrote: > Mike Castle wrote: > > > On Fri, Oct 13, 2000 at 02:42:15PM +1100, Luke Kendall wrote: > > > But the CVS archive isn't working for the Windows machines anymore; > > > any attempt to do a cvs login gets the error below: > > > > > > CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive > > > Started ssh, so now you need to cvs login: > > > (Logging in to luke@localhost) > > > CVS password: > > > cvs [login aborted]: authorization failed: server localhost rejected access > > > > Wait. You are using ssh to log back into the Windows machine? > > (luke@localhost) That doesn't seem to make a lot of sense. Or were you > > just obscurring information there? > > No, that's exactly what I used; it's the output from a script wrapped > around it that only starts an ssh connection to the cvs server machine > if there isn't already one running, and also sets some environment > variables. That sure looks like the standard error message. Are you sure you are sending the right user name? You said you move the CVS repository. Are you sure your ssh is still forwarding the connection to the correct machine and not to another without your name in the password file? Are you sure the repository root (--allow-root=...) hasn't changed and is it still being specified correctly to the pserver command? Play with CVS_CLIENT_LOG and see if you can trace more of the authentication. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- The cost of living hasn't affected its popularity. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
On 17 Oct, Derek R. Price wrote: > > No, that's exactly what I used; it's the output from a script wrapped > > around it that only starts an ssh connection to the cvs server machine > > if there isn't already one running, and also sets some environment > > variables. > > That sure looks like the standard error message. Are you sure you are sending the > right user name? >From the "(Logging in to luke@localhost)" message, it seems so. > You said you move the CVS repository. Yes; we moved it from /home/handy/cvs-archive to /home/mantovani/cvs-archive. We set up amd to export /home/mantovani and also to make a synonymous entry called /home/handy (since handy is now defunct), as a convenience. We tried both, incidentally, in the inetd.conf file (killing inetd appropriately), but that made no difference. > Are you sure your ssh is > still forwarding the connection to the correct machine and not to another without >your > name in the password file? Absolutely. We use NIS for passwords. They're only kept on one machine. And yes, the ssh forwards are always to localhost, so neither the machine name at the client nor the server has to be hard-coded as it were. > Are you sure the repository root (--allow-root=...) hasn't > changed and is it still being specified correctly to the pserver command? Yep: cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs --allow-root=/home/handy/cvs-archive pserver > Play with CVS_CLIENT_LOG and see if you can trace more of the authentication. Ah! This is what I was asking about and hoping for. Some way to get some extra logging or debug info. I assume that the client defines this env variable to be a filename, and log info is written to it. I'll give that a try right now. Thanks. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
On 18 Oct, To: Derek R. Price wrote: > > Play with CVS_CLIENT_LOG and see if you can trace more of the authentication. > > Ah! This is what I was asking about and hoping for. Some way to get > some extra logging or debug info. I assume that the client defines > this env variable to be a filename, and log info is written to it. > > I'll give that a try right now. Thanks. Under Windows (U/Win) I tried exporting CVS_CLIENT_LOG as d:/home/luke/cvs-client.txt and tried to cvs login. I couldn't find a file whose name included the string cvs-client.txt on any local drive. (D: is a local drive.) I also tried setting it to just plain "cvs-client.txt". Same result. On Linux, I tried setting it to /tmp/xxx and CVSROOT as: CVSROOT=":pserver:$LOGNAME@localhost:/home/handy/cvs-archive" Then did a cvs login (which succeeded, BTW), but no /tmp/xxx file had been created. 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. But nothing's happening. Obviously I'm dramatically misunderstanding how you're supposed to use CVS_CLIENT_LOG. Can someone enlighten me? Ta, luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
[EMAIL PROTECTED] 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: #!/bin/sh CVS_CLIENT_LOG=/tmp/xxx export CVS_CLIENT_LOG cvs ... login Should produce two files, /tmp/xxx.in & /tmp/xxx.out . The names are server relative (YES, I know it's called a client log. This one's a pet peeve of mine - maybe I'll fix it someday), so *.in is a full transcript of what went into the server (what was sent by the client) and *.out is a full transcript of what was sent by the server (what was read by the client). And I know it was working under Linux in 1.10.8 and in an almost 1.11 dev version, so you shouldn't be having any problems there. 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. 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. Is LOGNAME set differently on the two machines? 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. Also, try again to make sure that handy's IP address is the same regardless of which machine you look it up on. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not celebrate meaningless milestones. I will not celebrate meaningless milestones. I will not celebrate meaningless milestones... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
(Oops. Thought I had sent this off days ago... Sorry.)
Some interesting news, below. Good but puzzling.
On 18 Oct, Derek R. Price wrote:
> [EMAIL PROTECTED] 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 "/$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
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
