Hmm, I thought we had turned off validation when the URL mask was supplied.
I guess I was wrong.
So I'd have expected the log to have said something one way or another
about keys, whether it had one or didn't, and whether or not it succeeded.
An "EOF in transport thread" usually means something else went wrong. We'll
need to figure out what that is.
In this particular case, we're not using rbssh for the communication, but
rather Paramiko (the library rbssh wraps), which is being used from Review
Board itself. This fortunately means we don't have to mess around with
getting log output from rbssh, but also means what we're seeing is about as
good as it gets from the logging.
Can you try a few things?
1) Make sure that /path/to/site/data/.ssh/id_dsa is accessible by the web
2) Temporarily use this as your own SSH key and try to do a clone with that
repository path, to make sure that a clone with actual git + SSH works as
3) Then, do the same thing with: GIT_SSH=rbsh DEBUG_RBSSH=1 git clone ......
#2 should work so long as your configuration is correct on the Git server.
If it fails, something is wrong there.
If #2 works and #3 fails, then look in the current directory for ab
rbssh*.log file. See if it has anything more useful to say.
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com
On Wed, Jan 8, 2014 at 1:10 PM, Erika Redmark <maniacmonkeyinsp...@gmail.com
> I read about the issue involving git and I had previously used a local
> clone, but ended up with errors where it would not find diff changes for
> new branches. I do have a mask I can use that works with Stash:
> But the error comes up whether I use a mask or not when I supply the
> actually remote location for the 'Path' field. I have two options: SSH and
> HTTPS. The error I get above is when I use the SSH clone uri. I simply just
> get a "Repository Not Found" if I use the HTTPS clone uri (along with the
> proper password for my user).
> It doesn't matter if I provide the mask or not. The error is occurring
> based on what I supply to Path. If I leave it blank and just supply the
> mask, it tells me Path is a required field.
> On Wednesday, January 8, 2014 3:40:01 PM UTC-5, Christian Hammond wrote:
>> Hi Erika,
>> So the first big thing to know about Git is that you *must* either use a
>> local clone, or provide the raw file mask. Ideally the latter. Git has no
>> protocol support for fetching the content of an individual file at a given
>> revision, which means you can't just provide a remote path to Review Board
>> and have it work. This is truly annoying, but there's little we can do
>> about it.
>> So, the thing to focus on is figuring out if there's a URL you can use to
>> fetch the contents of a file at a path + revision that Review Board can
>> access through either anonymous access or using Basic HTTP auth. If there
>> is, plug that in and things should work, but if not, you'll need another
>> service that can provide that for you.
>> Basically, rbssh shouldn't really factor into this at this point.
>> Christian Hammond - chi...@chipx86.com
>> Review Board - http://www.reviewboard.org
>> Beanbag, Inc. - http://www.beanbaginc.com
>> On Wed, Jan 8, 2014 at 7:09 AM, Erika Redmark <maniacmon...@gmail.com>wrote:
>>> This question is almost identical to https://groups.google.com/
>>> forum/#!topic/reviewboard/UmXYqdsKTXY, however that thread ended
>>> without resolution.
>>> We have ReviewBoard 1.7.20 set up on Ubuntu 12.04. I am trying to set up
>>> a repository on ReviewBoard against a git repository on stash, but I run
>>> into the "[Errno -5] No address associated with hostname" error. This
>>> happens when I have a valid ssh clone link in my Path field. For this I am
>>> leaving all the other fields empty. My log is almost identical to the one
>>> posted on the other topic. I have redacted the actual links to our server.
>>> GitTool: Attempting ssh connection with host: [redacted]:7999, username:
>>> 2014-01-08 14:22:17,188 - DEBUG - - starting thread (client mode):
>>> 2014-01-08 14:22:17,208 - INFO - - Connected (version 2.0, client
>>> 2014-01-08 14:22:17,236 - DEBUG - - kex
>>> 'diffie-hellman-group1-sha1'] server key:['ssh-rsa'] client
>>> encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc'] server
>>> encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc'] client mac:['hmac-md5',
>>> 'hmac-sha1', 'hmac-md5-96', 'hmac-sha1-96'] server mac:['hmac-md5',
>>> 'hmac-sha1', 'hmac-md5-96', 'hmac-sha1-96'] client compress:['none'] server
>>> compress:['none'] client lang:[''] server lang:[''] kex follows?False
>>> 2014-01-08 14:22:17,236 - DEBUG - - Ciphers agreed: local=aes128-cbc,
>>> 2014-01-08 14:22:17,236 - DEBUG - - using kex
>>> diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local
>>> aes128-cbc, remote aes128-cbc; mac: local hmac-sha1, remote hmac-sha1;
>>> compression: local none, remote none
>>> 2014-01-08 14:22:17,371 - DEBUG - - Switch to new keys ...
>>> 2014-01-08 14:22:17,472 - DEBUG - - EOF in transport thread
>>> As in the other topic, initially this looks like a key problem because
>>> it never once says anything about key authenticated, or key denied; it just
>>> ends. However, the line:
>>> Connected (version 2.0, client SSHD-CORE-0.7.0-ATLASSIAN-M2)
>>> It sees this is stash, so I gather that it is properly getting to the
>>> right address (otherwise it wouldn't know). So having verified that is
>>> actually getting to the host in question, things go back to the keys.
>>> On Stash, I made a user, let's call him ReviewBoardUser. On ReviewBoard,
>>> I generated a key using the SSH tab on the left. I took this key and gave
>>> it to the ReviewBoardUser. What I expect would happen is that ReviewBoard
>>> would authenticate with Stash with the key, Stash would map it to this
>>> special ReviewBoardUser that has read access to all repositories that
>>> ReviewBoard needs, and then everything would be fine. (On that note, I
>>> would be using the form
>>> as the mask for Stash, so I don't believe there would be a need for cgit or
>>> anything. I won't know until I get this working and can actually try it).
>>> The previous topic user was also using Stash from the looks of the logs.
>>> One last point regarding the previous topic; I am not sure how to use
>>> rbssh properly, so I couldn't get any extra info from using that tool. I
>>> would appreciate a nice example syntax for using it, as I can't tell if I
>>> am making an error, or if it is itself reporting a valid error with the
>>> Let me know if there is any more information that is needed, I will be
>>> happy to provide it.
>>> - Erika
>>> Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
>>> Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
>>> Happy user? Let us know at http://www.reviewboard.org/users/
>>> You received this message because you are subscribed to the Google
>>> Groups "reviewboard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to reviewboard...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
> Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
> Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
> Happy user? Let us know at http://www.reviewboard.org/users/
> You received this message because you are subscribed to the Google Groups
> "reviewboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
Happy user? Let us know at http://www.reviewboard.org/users/
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.