1750: Unable to add svn+ssh repository when host requires rsa cert auth & disallows password auth
- Fixed
- Review Board
| mounta******@gmai***** (Google Code) (Is this you? Claim this profile.) | |
| Aug. 2, 2014 |
What version are you running? 1.5 RC1 What's the URL of the page containing the problem? /admin/db/scmtools/repository/add/ What steps will reproduce the problem? 1. Navigate to the /admin/db/scmtools/repository/add/ page in the admin section 2. Write a repository name 3. Change repository hosting service to Custom 4. Change repository type to Subversion 5. Use a repository that is on the same machine as reviewboard using ssh certs as auth w/password auth disable. URI should be like svn+ssh://theserver/the/repo/path 6. Leave username and password blank as auth is through ssh rsa cert. What is the expected output? What do you see instead? The repository should be succesfully added. What operating system are you using? What browser? uname -a Linux 2.6.31.12-0.2-default #1 SMP 2010-03-16 21:25:39 +0100 i686 i686 i386 GNU/Linux (openSUSE 11.3) Firefox 3.5 Please provide any additional information below. I have attached 4 files. The first being the an IRC chat from #reviewboard-soc on freenode that I (AfterFall) had with ChipX86 regarding this defect. The other 3 are copies of the pasteboards that are linked to within the discussion. As a summary of what I'm trying to accomplish: I have a reviewboard install on a server which also hosts my SVN repository. For svn authentication, I use ssh w/rsa certs and I have disabled password authentication. When attempting to add an svn+ssh repository I cannot due to various problems. I did notice that if I fill in username and password and enable password authentication in sshd_config I am able to authenticate through reviewboard. This is not an option for me though as I have disabled password auth for security reasons. The reviewboard logs for with password auth allowed and disallowed is attached as pb1.txt. As noted in the conversation, I am successfully able to connect to the repository using pysvn in the python console. The method for doing this is attached as pb2.txt. Using a blank password & username I woudl receive an error in ReviewBoard: local variable 'netloc_username' referenced before assignment We then fixed this problem by modifying reviewboard/scmtools/core.py in the get_auth_from_uri function by adding netlo_username = None after hostname = url[1] as stated in the irc conversation. Making this correction changed the error message displayed to Unable to authenticate against this repository with the provided username and password. It was then determined that the certificates should be copied to the $sitedir/data/.ssh directory. After copying the wwwrun users .ssh directory to this directory an attempting to add the respository the same error was received, however the ReviewBoard logs gave some different output showing that the certificates were actually being used now. This is shown in the pb3.txt attachment. However there is still a problem with authentication as the certificate appears to not be accepted. "2010-08-06 13:16:31,196 - INFO - Authentication (publickey) failed." At this point ChipX86 had to leave so our debugging efforts were on hold. At this point the problem may not even be a ReviewBoard problem. (possibly just something with the ssh key setup). Any suggestions on how to remedy would be appreciated before closing the bug. Thanks.
I continued to work on this problem on my own for a bit and came up with some new findings:
I commented out the uper(SVNTool, cls).check_repository(path, username, password) line in check_repository function of svn.py. In doing so, reviewboard automatically adds the svn repo without checking first which involves use of paramiko and bypassing the publickey failure. Reviewing the reviewboard logs, I could see that the repository could successfully be connected to by reviewboard, although this time through pysvn.
The logs showed the following line:
2010-08-06 15:40:31,793 - DEBUG - SVN: Got repository information for svn+ssh://xxx.com/yyy: [('yyy', <PysvnInfo ”>)]
I then proceded by creating a test review to verify that reviewboard could fetch files from the repo. This was also a success:
2010-08-06 15:43:58,061 - DEBUG - Fetching file '/trunk/path/to/file/in/repo' r113 from repo took 0.831398 seconds
From here I decided to dig into the check_repository function of SVNTool as well as SSHUtils' check_host. The check_host function uses paramiko to verify the ssh connection to the server. This is where the public key authentication failure was originating from.
First I wanted to verify that I could connect with paramiko by itself. So I su'ed into wwwrun (the apache user) and used the python console and did the following commands:
python
import paramiko
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect('xxx.com',username=None,password=None)
I was able to successfully connect using this method.
After this started to try and figure out why paramiko was not working. I did a lot of modifications in the sshutils.py to try and separate out the problematic components. And at a later time I may try some new tests with a clean file again. One of the main things I was testing was the proper user. I used os.getguid to verify that the reviewboard was running as wwwrun and would therefore attempt to authenticate as this user with paramiko. This function returned the expected uid. However if one does the following:
import getpass
getpass.getuser()
It returns a different (wrong) user (at least in my case). To my understanding this function references the environment variables to get its return value. I'm not too familiar with paramiko, however, if it uses this function internally this could be part of the problem.
This made me think to try changing which private key I provided reviewboard with. So I gave reviewboard the private key of the user that was returned incorrectly by getpass.getuser().
This resulted in the following logs:
2010-08-07 01:55:52,859 - INFO - Authentication (publickey) successful!
2010-08-07 01:55:52,959 - DEBUG - EOF in transport thread
2010-08-07 01:55:53,138 - ERROR - SVN: Failed to get repository information for svn+ssh://xxx.com/path/to/repo: Network connection closed unexpectedly
The authentication was succesfully, meaning reviewboard (or paramiko) was trying to connect to the wrong user. I'm not sure why after this it reports that it failed to get the repository information.
Okay So I'll have to return to this at a later time but I got one more bit of news... I restored my ReviewBoard installation and made the important change of fixing the netloc_user bug. NOTE: If anything needs to be fixed on this bug its this. So with this clean install with that slight modification I again attempted to connect to the repository. This time I copied the id_rsa from wwrun to reviewboards data/.ssh. Then in the add repository page I gave the repo url. This resulted in publickey failure. So then i put wwwrun in the username box and I got a success however I was given the error that there was no repository at this location. Same problem as earlier: 010-08-07 17:19:03,605 - INFO - Authentication (publickey) successful! 2010-08-07 17:19:03,706 - DEBUG - EOF in transport thread 2010-08-07 17:19:03,895 - ERROR - SVN: Failed to get repository information for svn+ssh://xxxx.com/path/to/repo: Network connection closed unexpectedly More to come.
Final set of information until some of this madness can be processed. I recognized the failure in the previous comment was from pysvn. I knew that previously I did not have problems with pysvn so I decided to login to the wwwrun and manually try pysvn again. While doing so, I was asked to accept the host and successfully connected. After this, I attempted to add the the repository through reviewboard and it worked. (It seems the problem may have been that reviewboard neglected to ask me for the key? As after doing a connection with pysvn and accepting it worked...)
I have the exact same problem, but I can't seem to replicate mountainmilk's workaround. I have a very similar configuration where I am attempting to connect to a remove svn+ssh repository. No other method of authentication is ever going to be possible with that server, so using http is not an option. I've attached what gets logged when I try to add the repository.
-
+
It's clearly a failure in pysvn.info2. One interesting piece of information is that if I include my username in the repository URL, the call succeeds.
In other words, assuming username <user> is the access user for host <host> and the repo is at <repo> on that host, not specifying the user in the URL yields this:
>>> import pysvn
>>> client = pysvn.Client()
>>> client.info2('svn+ssh://<host>/<repo>')
Password:
In other words, an interactive password prompt, which of course eventually times out on the server (might explain the error message).
However, if I then to this (after pressing Control-C to interrupt the previous call):
>>> client.info2('svn+ssh://<user>@<host>/<repo>')
Then I get the repo information without any prompt.
Furthermore, if I do this instead:
>>> client = pysvn.Client()
>>> client.set_default_username('<user>')
>>> client.info2('svn+ssh://<host>/<repo>')
Password:
I still get an interactive password prompt.
So there you have it...
Figured out an interesting workaround, given the information above: If I specify the username in the URL *and* also set the Username field in the Repository object model, everything works.
Roy, I see that you got a password prompt from pysvn. Can you take a look in your sshd_config file. It should be in /etc/ssh or somewhere similar. Check to see if you have password authentication disabled. If not, this could be why you received the interactive prompt from pysvn which lead to your inability to connect via reviewboard. Thanks
The server I am trying to connect to does allow password authentication, so it definitely makes sense that a password prompt would be displayed. It seems to me that the simple solution would be to pick up the username from the repository URL if it is not provided in the reviewboard admin form. Clearly, some piece of the SVN machinery when dealing with SSH key-pair authentication is ignoring the username set with set_default_username.
I have a similar issue, connectint svn+ssh correctly gets the public key, but then throws an authentication error. I can connect from command line. Was there a solution to this by any chance?
Adding the username to the URL solved the problem for me.
Can you please put the sample example? Even I am facing similar issue?
Using ReviewBoard 1.6.3 - Ubuntu
I've updated /var/www/<reviewboard-domain>/data/config to use a specific SSH key and name when accessing the SVN server.
I have sanity checked this as a www-data user and the SSH works from the command line.
However I cannot access the SVN server without a username in the SVN url,
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,396 - DEBUG - SVNTool: Attempting ssh connection with host: subversion.acme.com, username: chris.kelly
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,410 - DEBUG - starting thread (client mode): 0x2228992cL
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,427 - INFO - Connected (version 2.0, client OpenSSH_4.3)
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,440 - DEBUG - kex algos:['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', 'rijndael-cbc@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', 'rijndael-cbc@lysator.liu.se'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'zlib@openssh.com'] server compress:['none', 'zlib@openssh.com'] client lang:[''] server lang:[''] kex follows?False
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,440 - DEBUG - Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,441 - 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
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,577 - DEBUG - Switch to new keys ...
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,580 - DEBUG - Trying SSH key 419214727ed611cb7babd7283f83a5d6
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,635 - DEBUG - userauth is OK
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,666 - INFO - Authentication (publickey) successful!
[Tue Jan 24 22:05:56 2012] [error] 2012-01-24 22:05:56,766 - DEBUG - EOF in transport thread
Too many authentication failures for www-data
[Tue Jan 24 22:05:57 2012] [error] 2012-01-24 22:05:57,668 - ERROR - SVN: Failed to get repository information for svn+ssh://subversion.acme.com/usr/local/svnroot/delivery: Network connection closed unexpectedly
It fails if I use the raw address subversion.acme.com.
However if I use a username i.e. chris.kelly@subversion.acme.com I get a connection.
Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,132 - DEBUG - SVNTool: Attempting ssh connection with host: subversion.acme.com, username: chris.kelly
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,145 - DEBUG - starting thread (client mode): 0x2238576cL
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,163 - INFO - Connected (version 2.0, client OpenSSH_4.3)
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,176 - DEBUG - kex algos:['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', 'rijndael-cbc@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', 'rijndael-cbc@lysator.liu.se'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'zlib@openssh.com'] server compress:['none', 'zlib@openssh.com'] client lang:[''] server lang:[''] kex follows?False
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,176 - DEBUG - Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,176 - 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
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,311 - DEBUG - Switch to new keys ...
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,314 - DEBUG - Trying SSH key 419214727ed611cb7babd7283f83a5d6
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,371 - DEBUG - userauth is OK
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,401 - INFO - Authentication (publickey) successful!
[Tue Jan 24 22:10:17 2012] [error] 2012-01-24 22:10:17,502 - DEBUG - EOF in transport thread
[Tue Jan 24 22:10:18 2012] [error] 2012-01-24 22:10:18,871 - DEBUG - SVN: Got repository information for svn+ssh://chris.kelly@subversion.acme.com/usr/local/svnroot/delivery: [('delivery', <PysvnInfo ''>)]
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,590 - DEBUG - SVNTool: Attempting ssh connection with host: subversion.acme.com, username: chris.kelly
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,606 - DEBUG - starting thread (client mode): 0x223234acL
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,624 - INFO - Connected (version 2.0, client OpenSSH_4.3)
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,636 - DEBUG - kex algos:['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', 'rijndael-cbc@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', 'rijndael-cbc@lysator.liu.se'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'zlib@openssh.com'] server compress:['none', 'zlib@openssh.com'] client lang:[''] server lang:[''] kex follows?False
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,637 - DEBUG - Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,637 - 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
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,775 - DEBUG - Switch to new keys ...
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,778 - DEBUG - Trying SSH key 419214727ed611cb7babd7283f83a5d6
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,833 - DEBUG - userauth is OK
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,864 - INFO - Authentication (publickey) successful!
[Tue Jan 24 22:11:11 2012] [error] 2012-01-24 22:11:11,964 - DEBUG - EOF in transport thread
[Tue Jan 24 22:11:13 2012] [error] 2012-01-24 22:11:13,361 - DEBUG - SVN: Got repository information for svn+ssh://chris.kelly@subversion.acme.com/usr/local/svnroot/delivery: [('delivery', <PysvnInfo ''>)]
Furthermore it looks like whatever I type in the username field on the webpage is always ignored. The username does not get used when you access the SVN repository
It's preferential that the subversion URL has no username because I relying on that for the Eclipse ReviewBoard plugin. The code checked out there has no username in the URL. When the plugin searches the server for SVN repositories it cannot find a match as the RB server only picks up the repository if the username is part of the SVN url. I can't create multiple SVN repositories with different usernames for members of my team. Not a feasible solution :(.
-
+ Component-SSH
-
+ Unable to add svn+ssh repository when host requires rsa cert auth & disallows password auth
I think that this is quite out of date now. The cert needs to be installed for the web server user, but I think several people have deployed this way successfully.
-
+ Fixed