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: >> "[email protected]: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 - [email protected] >>> Review Board - http://www.reviewboard.org >>> Beanbag, Inc. - http://www.beanbaginc.com >>> >>> >>> On Tue, Apr 29, 2014 at 11:23 AM, Dan Tehranian <[email protected]>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', '[email protected]'] >>>> server encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', >>>> 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', >>>> 'aes192-cbc', 'aes256-cbc', 'arcfour', '[email protected]'] >>>> client mac:['hmac-md5', 'hmac-sha1', '[email protected]', >>>> 'hmac-sha2-256', 'hmac-sha2-256-96', 'hmac-sha2-512', 'hmac-sha2-512-96', >>>> 'hmac-ripemd160', '[email protected]', 'hmac-sha1-96', >>>> 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', '[email protected]', >>>> 'hmac-sha2-256', 'hmac-sha2-256-96', 'hmac-sha2-512', 'hmac-sha2-512-96', >>>> 'hmac-ripemd160', '[email protected]', 'hmac-sha1-96', >>>> 'hmac-md5-96'] client compress:['none', '[email protected]'] server >>>> compress:['none', '[email protected]'] 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://[email protected]: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 [email protected] -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 [email protected]. >>>> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
