Did you ever have anything filled out in the Password field for the
repository? Do you still have the username field set? If these were ever
filled out, be sure they're filled out now (re-type the password) and save
the repository again. I want to rule out a configuration issue on that end.

At this point, I don't think it's an issue with either rbssh or Review
Board, but rather some configuration issue somewhere. (Though I won't rule
it out completely.) The logs indicate to me that we've handed things over
to svnserve at this point, meaning we're no longer a factor. In that case,
it'd be something between libsvn and svnserve.

I haven't hit this problem in my testing so far.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Fri, Jan 4, 2013 at 7:53 AM, Dave Preston
<d.pres...@complianceease.com>wrote:

> I did upgrade the svn server after I started to have these problems. But
> everything else is the same.****
>
> ** **
>
> Dave****
>
> ** **
>
> *From:* reviewboard@googlegroups.com [mailto:reviewboard@googlegroups.com]
> *On Behalf Of *Christian Hammond
> *Sent:* Thursday, January 03, 2013 10:16 PM
>
> *To:* reviewboard@googlegroups.com
> *Subject:* Re: a couple of issues post 1.7.1 upgrade****
>
> ** **
>
> If it's process_stdin, it sounds like it's svnserve asking for the
> password, meaning the SSH authentication was successful. I assume it's
> doing this in the original log you showed as well, and the lack of stdin
> was causing the connection to be closed unexpectedly.****
>
> ** **
>
> I don't know why it'd be different from when you were using 1.6.9 (nor do
> I know what would have changed to break this in this way). Sounds like
> something changed, though.****
>
> ** **
>
> Were any other things upgraded along with Review Board? The SVN server, or
> pysvn/libsvn?****
>
> ** **
>
> Christian ****
>
>
> ****
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board - http://www.reviewboard.org
> VMware, Inc. - http://www.vmware.com****
>
> ** **
>
> On Thu, Jan 3, 2013 at 7:59 PM, Dave Preston <d.pres...@complianceease.com>
> wrote:****
>
> All those process_stdin is where it prompts for the password. I don't
> get why it seems to connect with the key ok and then fall back to
> password, if that's what is actually happening.****
>
>
> > -----Original Message-----
> > From: reviewboard@googlegroups.com
> > [mailto:reviewboard@googlegroups.com] On Behalf Of Christian Hammond****
>
> > Sent: Thursday, January 03, 2013 5:45 PM
> > To: reviewboard@googlegroups.com
> > Subject: Re: a couple of issues post 1.7.1 upgrade
> >****
>
> > At what point during the log is it asking for the password?
> >
> > It looks like it's connected. Maybe it's svnserve asking for the
> password?
> >
> > Christian
> >
> > --
> > Christian Hammond - chip...@chipx86.com
> > Review Board - http://www.reviewboard.org VMware, Inc. -
> > http://www.vmware.com
> >
> >
> > On Thu, Jan 3, 2013 at 5:32 PM, Dave Preston
> > <d.pres...@complianceease.com> wrote:
> >
> >
> >       You are correct, I've gotten a bit sloppy as the day has gone
> on.
> >
> >       So now when I execute svn cat it just keeps prompting me for a
> > password
> >       even though the key exists on the other side. The log shows that
> > pubkey
> >       is successful and then falls back to password.
> >
> >
> >       USER=www-data
> >       DEBUG_RBSSH=1
> >       DJANGO_SETTINGS_MODULE=reviewboard.settings
> >       HOME=/var/www/reviewboard.logiceasedev.com/data
> >       PYTHONPATH=/var/www/reviewboard.logiceasedev.com/conf
> >
> >       01-03 17:29 root               DEBUG    ['/tmp/rbssh',
> 'svnpoller@svn',
> >       'svnserve', '-t']
> >       01-03 17:29 root               DEBUG    PID 30058
> >       01-03 17:29 root               DEBUG    !!! svn, svnpoller,
> ['svnserve',
> >       '-t']
> >       01-04 01:29 paramiko.transport DEBUG    starting thread (client
> > mode):
> >       0x1144450L
> >       01-04 01:29 paramiko.transport INFO     Connected (version 2.0,
> client
> >       OpenSSH_5.3p1)
> >       01-04 01:29 paramiko.transport DEBUG    kex
> >       algos:['diffie-hellman-group-exchange-sha256',
> >       'diffie-hellman-group-exchange-sha1',
> 'diffie-hellman-group14-sha1',
> >       'diffie-hellman-group1-sha1'] server key:
> >       ['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-ctr',
> 'aes192-ctr',
> >       'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc',
> '3des-cbc',
> >       'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc',
> 'arcfou
> >       r', 'rijndael-...@lysator.liu.se'] server encrypt:['aes128-ctr',
> >       'aes192-ctr', 'aes256-ctr', 'arcfour256', 'arcfour128',
> 'aes128-cbc',
> >       '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'aes192-cbc',
> 'aes256-c
> >       bc', 'arcfour', 'rijndael-...@lysator.liu.se'] client
> mac:['hmac-md5',
> >       'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160',
> >       'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96']
> > server
> >       mac:['hm
> >       ac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160',
> >       'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96']
> > client
> >       compress:['none', 'z...@openssh.com'] server compress:['none',
> > 'zlib@o
> >       penssh.com'] client lang:[''] server lang:[''] kex follows?False
> >       01-04 01:29 paramiko.transport DEBUG    Ciphers agreed:
> >       local=aes128-ctr, remote=aes128-ctr
> >       01-04 01:29 paramiko.transport DEBUG    using kex
> >       diffie-hellman-group1-sha1; server key type ssh-rsa; cipher:
> local
> >       aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote
> hmac-
> > sha1;
> >       compression:
> >       local none, remote none
> >       01-04 01:29 paramiko.transport DEBUG    Switch to new keys ...
> >       01-04 01:29 paramiko.transport DEBUG    Trying SSH key
> >       f3a2e6c6b62eba6b6519578ce97e57cd
> >       01-04 01:29 paramiko.transport DEBUG    userauth is OK
> >       01-04 01:29 paramiko.transport INFO     Authentication
> (publickey)
> >       successful!
> >       01-04 01:29 paramiko.transport DEBUG    [chan 1] Max packet in:
> > 34816
> >       bytes
> >       01-04 01:29 paramiko.transport DEBUG    [chan 1] Max packet out:
> > 32768
> >       bytes
> >       01-04 01:29 paramiko.transport INFO     Secsh channel 1 opened.
> >       01-04 01:29 root               DEBUG    !!! Using PosixHandler
> >       01-04 01:29 root               DEBUG    !!! Sending command
> ['svnserve',
> >       '-t']
> >       01-04 01:29 paramiko.transport DEBUG    [chan 1] Sesch channel 1
> > request
> >       ok
> >       01-04 01:29 root               DEBUG    !! process_channel
> >
> >       01-04 01:29 root               DEBUG    !! process_stdin
> >
> >       01-04 01:29 root               DEBUG    !! process_stdin
> >
> >       01-04 01:29 root               DEBUG    !! process_stdin
> >       .. cut ...
> >       01-04 01:29 paramiko.transport DEBUG    [chan 1] EOF received
> (1)
> >       01-04 01:29 paramiko.transport DEBUG    [chan 1] EOF sent (1)
> >       01-04 01:29 root               DEBUG    !! process_channel
> >
> >
> >       > -----Original Message-----
> >       > From: reviewboard@googlegroups.com
> >       > [mailto:reviewboard@googlegroups.com] On Behalf Of Christian
> > Hammond
> >       > Sent: Thursday, January 03, 2013 4:17 PM
> >       > To: reviewboard@googlegroups.com
> >       > Subject: Re: a couple of issues post 1.7.1 upgrade
> >       >
> >       > I just noticed that the username it's trying to use when
> connecting
> > to
> >       the
> >       > remote host is www-data. That's probably not what you're
> > wanting.
> >       >
> >       > I know we have the username field, but it doesn't seem that
> > Subversion
> >       > provides the configured username to the SSH client. So, try
> > changing
> >       your
> >       > Path to be something more like:
> > svn+ssh://yourusername@host:/path.
> >       Then
> >       > change Mirror Path to be the previous version of the path
> without
> > the
> >       > username. That should ensure that rbssh will get some
> information
> > on
> >       the
> >       > correct username to use.
> >       >
> >       > Christian
> >       >
> >       > --
> >       > Christian Hammond - chip...@chipx86.com
> >       > Review Board - http://www.reviewboard.org
> >       > VMware, Inc. - http://www.vmware.com
> >       >
> >       >
> >       > On Thu, Jan 3, 2013 at 4:09 PM, Dave Preston
> >       > <d.pres...@complianceease.com> wrote:
> >       >
> >       >
> >       >       Nope, I had su'd as root.
> >       >
> >       >       su - www-data
> >       >
> >       >       Not a problem and I do appreciate your time on this.
> >       >
> >       >
> >       >       Dave
> >       >
> >       >       > -----Original Message-----
> >       >       > From: reviewboard@googlegroups.com
> >       >       > [mailto:reviewboard@googlegroups.com] On Behalf Of
> > Christian
> >       > Hammond
> >       >
> >       >       > Sent: Thursday, January 03, 2013 4:07 PM
> >       >       > To: reviewboard@googlegroups.com
> >       >       > Subject: Re: a couple of issues post 1.7.1 upgrade
> >       >       >
> >       >
> >       >       > Okay. So, when you're running the rbssh command
> manually
> > to
> >       > test this,
> >       >       are
> >       >       > you doing it as root? Otherwise, it won't be able to
> access
> >       the SSH
> >       >       key, which
> >       >       > would certainly cause what we're seeing in those logs.
> >       >       >
> >       >       > Sorry for all the back and forth on this. Hopefully
> we'll get
> >       to the
> >       >       bottom of it
> >       >       > soon. Today seems to be the day for strange
> SSH-related
> >       problems.
> >       >       >
> >       >       > Christian
> >
> >****
>
> > --
> > Want to help the Review Board project? Donate today at
> > http://www.reviewboard.org/donate/
> > Happy user? Let us know at http://www.reviewboard.org/users/
> > -~----------~----~----~----~------~----~------~--~---
> > To unsubscribe from this group, send email to
> > reviewboard+unsubscr...@googlegroups.com****
>
> > For more options, visit this group at
> > http://groups.google.com/group/reviewboard?hl=en
> >
> >
>
>
> --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com****
>
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
>
> ****
>
> ** **
>
> --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
>
>  ****
>
> --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
>
>
>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en


Reply via email to