I saw that, and it may well be accurate, and then again it may not. I don’t know, and I have no reasonably convenient way to know. Of course that is also true of whois information, but having “private” whois information seems completely unnecessary for a company that is trying to do business transparently. None of that is my main point, however, which is that the service you are offering, even if “well intended” and “legitimate” in purpose, is inherently insecure (as you pointed out yourself in your Terms and Conditions) and is therefore dangerous to use. People should not use it because it is unsafe.
I think it is more than just a question of trust, but let’s talk about the trust aspect for a minute. Not only do users of your service need to “trust” the service not to abuse (resell, release, exploit, etc.) their information, but they have to also trust your security practices sufficiently to believe that you are capable of protecting that information, and I maintain that it is unreasonable for them to do so.
From a security standpoint, it defeats the whole point of using ssh in the first place to pass your credentials over the web in the clear to be forwarded through a third party to your system. Period. Your service is, by definition, a “man in the middle”, and your system sees the credentials “in the clear”. I’m sorry, but while it may seem convenient to use such a service to those who do not understand the risk, it is foolish for anyone to consider such a service an “acceptable b(a)ckup solution”. Just because a thing can be done does not mean that the thing should be done, and this is one of the things one should not do. It’s like using telnet or ftp via a third-party proxy that you don’t control - also a foolish thing to do. A far better solution for such “exigent” and occasional use would be for a user to install their own software on their own server, reachable only via apahce authentication and/or SSL. While still not completely safe, it would be orders of magnitude safer than using a service such as yours.
What is particularly distressing about such services is that they appeal primarily to those who do not have the technical background to identify and understand the risk, so that they can make an informed decision about whether or not to assume that risk.
gotossh.org and my.anyterm.org present similar security concerns, which they discuss candidly on their websites in their discussion of security. Frankly, their documentation does a far better job of warning users of the security implications than your site does. At least installing anyterm software on one’s own server affords one the option of configuring their system to only accept traffic from certian IPs, and to use SSL (though this method is not commonly available to many shared hosting account customers who do not have root).
Add to all this your posting your linkspam to forums in long dead threads, and you are left with what very much appears to be just another “phishing” attempt. I don’t know if that is what you are doing or not. If that is not what you are doing, you might consider your whole approach to the service you are attempting to provide and your methods of promoting it, so that you are not perceived that way. While that won’t change the riskiness of using your service, it might at least discourage people from thinking the worst of you.
Irrespective of any of the preceding discussion, it remains dangerous to connect to a shared server’s shell in this manner, and I most strongly implore users here to refrain from doing this via your, or another similar, service.