Hi Ken,

Yea, I'd originally tried with the "ssh://" pre-pended since that seems 
like the proper format of a URL, but the error I got from the Admin UI in 
that case was: "[Errno -2] Name or service not known" so that seemed to be 
even less promising.

Now that I look again more closely, I see something interesting in the 
log... A) It shoes the proper port #.  B) There's an entry that indicates 
that there was a connection and the remote daemon clearly identifies itself 
as "Atlassian".  Some exchanges happen, then everything just ends abruptly. 
 See:

2014-04-29 21:22:29,981 - DEBUG -  - GitTool: Attempting ssh connection 
with host: vi-stash.lab.vi.local:7999, username: git
2014-04-29 21:22:29,988 - DEBUG -  - starting thread (client mode): 
0xb7fb8e4cL
*2014-04-29 21:22:29,989 - INFO -  - Connected (version 2.0, client 
SSHD-CORE-0.9.0-ATLASSIAN-1)*
2014-04-29 21:22:29,991 - DEBUG -  - kex 
algos:['diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server 
key:['ssh-rsa'] client encrypt:['aes128-ctr', 'aes256-ctr', 'aes128-cbc', 
'3des-cbc', 'blowfish-cbc', 'aes192-cbc', 'aes256-cbc'] server 
encrypt:['aes128-ctr', 'aes256-ctr', 'aes128-cbc', '3des-cbc', 
'blowfish-cbc', 'aes192-cbc', 'aes256-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-04-29 21:22:29,992 - DEBUG -  - Ciphers agreed: local=aes128-ctr, 
remote=aes128-ctr*
2014-04-29 21:22:29,992 - 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
2014-04-29 21:22:30,090 - DEBUG -  - Switch to new keys ...
2014-04-29 21:22:30,192 - DEBUG -  - EOF in transport thread


Dan


On Tuesday, April 29, 2014 2:18:47 PM UTC-7, Ken Rachynski wrote:
>
> You'll need to change your URL format. user@server:repo implies SSH and 
> uses the colon to separate server from repo. This is likely why your port 
> usage is disappearing.
>
> Use ssh://user@server:port/repo instead.
>
> Ken
>
> On Tuesday, April 29, 2014 2:59:04 PM UTC-6, Dan Tehranian wrote:
>>
>> Hi Christian,
>>
>> I've confirmed that Review Board is not respecting the port number in my 
>> Git URL string and using the default port 22 instead. In real-time I can 
>> see the relevant log output for "sshd" running on port 22 when I try to add 
>> a repo to Review Board with the URL: 
>> "g...@vi-stash.lab.vi.local:7999/do/tools.git".  From "/var/log/auth.log" on 
>> my Stash server:
>>
>> root@vi-git-stash1:/var/log# tail -f auth.log 
>> ...
>> Apr 29 13:52:10 vi-git-stash1 sshd[4200]: Invalid user git from 
>> 10.10.77.65
>> Apr 29 13:52:10 vi-git-stash1 sshd[4200]: input_userauth_request: invalid 
>> user git [preauth]
>> Apr 29 13:52:10 vi-git-stash1 sshd[4200]: Failed none for invalid user 
>> git from 10.10.77.65 port 34312 ssh2
>> Apr 29 13:52:10 vi-git-stash1 sshd[4200]: Connection closed by 
>> 10.10.77.65 [preauth]
>>
>>
>>
>> ... Meanwhile the logs for the Stash app that I'm also tailing don't show 
>> any connection attempt being to port 7999.
>>
>> Shall I file a bug?
>>
>> Thanks,
>> Dan
>>
>>
>>
>>
>> On Tuesday, April 29, 2014 12:25:26 PM UTC-7, Christian Hammond wrote:
>>>
>>> Hi Dan,
>>>
>>> We don't use OpenSSH for talking to the repository. We use our rbssh 
>>> instead. This shouldn't end up using the SSH key in ~/.ssh, but rather 
>>> should be using the SSH key configured in Review Board instead, which will 
>>> live in $sitedir/data/.ssh instead of /var/www/.ssh.
>>>
>>> Is the SSH key shown in Review Board matching exactly the key configured 
>>> on the repository's side?
>>>
>>> It is possible that there's an issue with the port. I'd have to see your 
>>> repository configuration and play around with stuff to know more.
>>>
>>> Christian
>>>
>>> -- 
>>> Christian Hammond - chi...@chipx86.com
>>> Review Board - http://www.reviewboard.org
>>> Beanbag, Inc. - http://www.beanbaginc.com
>>>
>>>
>>> On Tue, Apr 29, 2014 at 11:23 AM, Dan Tehranian <tehr...@gmail.com>wrote:
>>>
>>>> We're moving our git server to Atlassian Stash and I'm unable to hook 
>>>> our existing Review Board instance up with the repos we've moved to Stash.
>>>>
>>>> The error from the Admin UI is: "Unable to authenticate against this 
>>>> repository using one of the supported authentication types."  From 
>>>> "/var/log/reviewboard/reviewboard.log":
>>>>
>>>> 2014-04-29 18:04:49,684 - DEBUG -  - GitTool: Attempting ssh connection 
>>>> with host: vi-stash.lab.vi.local, username: git
>>>> 2014-04-29 18:04:49,688 - DEBUG -  - starting thread (client mode): 
>>>> 0xb7fe712cL
>>>> 2014-04-29 18:04:49,697 - INFO -  - Connected (version 2.0, client 
>>>> OpenSSH_5.9p1)
>>>> 2014-04-29 18:04:49,698 - DEBUG -  - kex algos:['ecdh-sha2-nistp256', 
>>>> 'ecdh-sha2-nistp384', 'ecdh-sha2-nistp521', 
>>>> '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', 'arcfour', 'rijnda...@lysator.liu.se'] 
>>>> server encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', 
>>>> 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 
>>>> 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijnda...@lysator.liu.se'] 
>>>> client mac:['hmac-md5', 'hmac-sha1', 'uma...@openssh.com', 
>>>> 'hmac-sha2-256', 'hmac-sha2-256-96', 'hmac-sha2-512', 'hmac-sha2-512-96', 
>>>> 'hmac-ripemd160', 'hmac-ri...@openssh.com', 'hmac-sha1-96', 
>>>> 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'uma...@openssh.com', 
>>>> 'hmac-sha2-256', 'hmac-sha2-256-96', 'hmac-sha2-512', 'hmac-sha2-512-96', 
>>>> 'hmac-ripemd160', 'hmac-ri...@openssh.com', 'hmac-sha1-96', 
>>>> 'hmac-md5-96'] client compress:['none', 'zl...@openssh.com'] server 
>>>> compress:['none', 'zl...@openssh.com'] client lang:[''] server 
>>>> lang:[''] kex follows?False
>>>> 2014-04-29 18:04:49,698 - DEBUG -  - Ciphers agreed: local=aes128-ctr, 
>>>> remote=aes128-ctr
>>>> 2014-04-29 18:04:49,698 - 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
>>>> 2014-04-29 18:04:49,742 - DEBUG -  - Switch to new keys ...
>>>> 2014-04-29 18:04:49,773 - DEBUG -  - Trying SSH key 
>>>> *baac4e3fe8a0e255a59160d00707093b*
>>>> 2014-04-29 18:04:49,778 - DEBUG -  - userauth is OK
>>>> 2014-04-29 18:04:49,812 - INFO -  - Authentication (publickey) failed.
>>>> 2014-04-29 18:04:49,823 - DEBUG -  - Trying discovered key 
>>>> *baac4e3fe8a0e255a59160d00707093b* in 
>>>> /var/www/vi-reviewboard/data/.ssh/id_rsa
>>>> 2014-04-29 18:04:49,824 - DEBUG -  - userauth is OK
>>>> 2014-04-29 18:04:49,845 - INFO -  - Authentication (publickey) failed.
>>>> 2014-04-29 18:04:49,847 - DEBUG -  - userauth is OK
>>>> 2014-04-29 18:04:49,847 - INFO -  - Authentication (password) failed.
>>>> 2014-04-29 18:04:49,948 - DEBUG -  - EOF in transport thread
>>>>
>>>>
>>>>
>>>>
>>>> But I'm otherwise able to clone repos as the "www-data" user from the 
>>>> CLI.  Ex:
>>>>
>>>> www-data@vi-reviewboard:~/tmp$ git clone 
>>>> ssh://g...@vi-stash.lab.vi.local:7999/do/tools.git
>>>> Cloning into 'tools'...
>>>> remote: Counting objects: 2271, done.
>>>> remote: Compressing objects: 100% (954/954), done.
>>>> remote: Total 2271 (delta 1468), reused 2004 (delta 1260)
>>>> Receiving objects: 100% (2271/2271), 294.32 KiB, done.
>>>> Resolving deltas: 100% (1468/1468), done.
>>>>
>>>>
>>>> Even more confusing, when I successfully "ssh" w/"--verbose" from the 
>>>> CLI, I can see the fingerprint of the private key matches the fingerprint 
>>>> of the private key used by Review Board. Ex:
>>>>
>>>> www-data@vi-reviewboard:~/tmp$ ssh -vv g...@vi-stash.lab.vi.local -p 7999
>>>> OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
>>>> debug1: Reading configuration data /etc/ssh/ssh_config
>>>> debug1: /etc/ssh/ssh_config line 19: Applying options for *
>>>> debug2: ssh_connect: needpriv 0
>>>>  debug1: Connecting to vi-stash.lab.vi.local [10.10.77.216] port 7999.
>>>> debug1: Connection established.
>>>> debug1: identity file /var/www/.ssh/id_rsa type 1
>>>> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
>>>> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
>>>> debug1: identity file /var/www/.ssh/id_rsa-cert type -1
>>>> debug1: identity file /var/www/.ssh/id_dsa type -1
>>>> debug1: identity file /var/www/.ssh/id_dsa-cert type -1
>>>> debug1: identity file /var/www/.ssh/id_ecdsa type -1
>>>> debug1: identity file /var/www/.ssh/id_ecdsa-cert type -1
>>>> debug1: Remote protocol version 2.0, remote software version 
>>>> SSHD-CORE-0.9.0-ATLASSIAN-1
>>>> debug1: no match: SSHD-CORE-0.9.0-ATLASSIAN-1
>>>> ...
>>>> debug1: Host '[vi-stash.lab.vi.local]:7999' is known and matches the 
>>>> RSA host key.
>>>> debug1: Found key in /etc/ssh/ssh_known_hosts:7
>>>> ...
>>>> debug2: key: /var/www/.ssh/id_rsa (0xb8886b50)
>>>> debug2: key: /var/www/.ssh/id_dsa ((nil))
>>>> debug2: key: /var/www/.ssh/id_ecdsa ((nil))
>>>>  debug1: Authentications that can continue: publickey
>>>> debug1: Next authentication method: publickey
>>>> debug1: Offering RSA public key: /var/www/.ssh/id_rsa
>>>> debug2: we sent a publickey packet, wait for reply
>>>> debug1: Server accepts key: pkalg ssh-rsa blen 279
>>>> debug2: input_userauth_pk_ok: fp 
>>>> *ba:ac:4e:3f:e8:a0:e2:55:a5:91:60:d0:07:07:09:3b*
>>>> debug1: read PEM private key done: type RSA
>>>> debug1: Authentication succeeded (publickey).
>>>> Authenticated to vi-stash.lab.vi.local ([10.10.77.216]:7999).
>>>>
>>>>  
>>>>
>>>> I'm wondering if RB is not parsing the port #7999 form my repo URL 
>>>> correctly and going to the VM's default SSH port 22 instead.  This claims 
>>>> to have been fixed in 
>>>> https://code.google.com/p/reviewboard/issues/detail?id=2841 though...
>>>>
>>>> I'm using RB 1.7.14.  I checked the release notes for all the newer 
>>>> versions and don't see anything that might help if I upgrade.
>>>>
>>>> Any thoughts?
>>>>
>>>> Thanks,
>>>> Dan
>>>>
>>>> -- 
>>>> 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/d/optout.
>>>>
>>>
>>>

-- 
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/d/optout.

Reply via email to