1and1 GIT Repositories Leave A Lot To Be Desired

Every now and again we all come across things which appear too ridiculous to be true. As was the way with 1and1's GIT repos. Allow me to recant the tale.

I was looking for a primary GIT repository to host a private project. This unfortunately ruled out Github, as their pricing model for private hosting was a little too steep.

I would have been happy to host it locally, but with high availability as a requirement, and the fact that the best connection I can get in my area is a poor ADSL with speeds of < 3Mbit dl (let's not even talk about ul!), that didn't seem ideal.

What I did have was a *nix hosting account with 1and1, and with shell access as standard, this seemed ideal. Digging around the 1and1 console, I even found a prominent section promoting the use of git, and with instructions for its use. Better still, git was already installed on the server; no need for the wget/make combo.

Unfortunately, the only protocol configured for git was SSH; but, that didn't pose any immediate problem. In minutes, I had a git repo configured, had cloned it locally, and everything was good.

Then came the obvious next move: securing the configuration by using an appropriately configured SSH account.

This aligns with the first rule* of computer security: grant only those permissions which are absolutely necessary. Obviously, nobody would use a fully permissioned** SSH account for simple pushes to a repo, let alone disseminate it to others... would they?

So I tried SSH-ing in with a secondary FTP account. This is what I saw:

This account is restricted by rssh.
Allowed commands: sftp

If you believe this is in error, please contact your system administrator.

Connection to XXXXX.co.uk closed.

And therein lies the catch: 1and1 supports only 1 single SSH account, which has the same credentials as the master FTP account.

A lengthy call with technical support confirmed my bewildered suspicions.
The reason given? "Security".

Perhaps it's my own marbles rolling around on the floor, but this security policy seems to have been devised by the same people behind IEEE's webserver permissioning strategy.

At the very least, they should have a secondary ssh account restricted to a preset git repository directory and the git command. At most, they should allow proper ssh user account creation & permissioning. An alternative would be to configure the webserver for git over https; but they haven't done that either.

It could be marginally acceptable if you only intend to pull patches from submitters and push them to the remote yourself, but it's still barely suitable for that use case. The only place I'd feel comfortable storing the key would be on my own boxes (not mobile devices), which would make for some rather inconvenient git practices.

Another unrelated inconvenience with this route is 1and1's rather low configuration for the number of failed login attempts prior to temporary IP blocking. It's a good policy to have, but implemented in rather brutal fashion... no gradual backoffs, nothing. The block itself lasts quite a while, and their SLA upon calling and requesting an unblock is 4 hours.

I finished my call to 1and1 with a request to revise their 1 login "security policy"... but until then, if you want a high availability GIT repo, look elsewhere.

Update 8th May 2013:

A great alternative, if all you want is a private hosted service with a handful of users, is Atlassian's Bitbucket. It comes with a rather agreeable interface, >=5 users, unlimited repos, and as good as instant account setup, all for free.

* There are lots of "first" rules, depending upon what got the author's gander up at the time of writing.

** Got r00t? Nope... but as fully permissioned as it gets on 1and1, meaning access to the entire webspace.