I thought it was implementing SSH in JS and WebSockets aka an "HTML5 SSH client"
In fact its just a front end. So yeah it's plugin free, but it's still not interesting.
Means also that your password travels to the host machine then and that you get double latency.
"Bleh" comes to mind :-(
Please someone tell me I missed a sshprotocol.py and that the ssh.py was not full of system() calls :'(
I thought it was implementing SSH in JS and WebSockets aka an "HTML5 SSH client"
I don't think that's possible. You would have to implement encryption in JavaScript and that is a horror in it's own right, especially when it comes to performance. There would be other problems too.
Means also that your password travels to the host machine then and that you get double latency.
Yes, but if you install this on your machine or another machine on your local network, it shouldn't be too bad.
"Bleh" comes to mind :-(
This is actually very cool! I develop on Windows (personal preference), but my development + production is all Linux. There's also instances on Rackspace and EC2, all Linux. This allows me to connect to them through the browser, without running SecureCRT or Putty!
What is the improvement for your workflow? I'm genuinely interested, because I cannot even imagine why I'd drop putty (or something similar) and go for a web client here (at least not unless it would be something completely without a backend that I need to install first).
I use SecureCRT (not free). Really good software, has tabs, a ton of features. However ...
1. I have to install it on every computer I use. It's not free or cheap. If I re-install OS, I have to re-install it. It is supported on Windows, Mac, and Linux, but if I need access while using my tablet or phone ... I'd need to install something else.
2. I use many servers and it doesn't synchronize settings between computers. I want to have access to all my servers whether I'm in the office or using my laptop at home. Not an issue with a web based system.
3. I make web based software, so ... it only makes sense that I support the ecosystem =)
Here's a couple of reasons why Gate One is superior to PuTTY:
* Gate One makes temporary network disruptions a trivial inconvenience: If your connection drops (which is sadly very common with business VPNs and home Internet connections) you can instantly resume all your open terminals the moment it comes back online. This also works for when you need to reboot your computer (not that Windows ever makes you do that ;).
* Gate One's bookmark manager is vastly superior to PuTTY's built-in session manager. With PuTTY, if you have more than a few "Saved Sessions" you'll have to scroll and scroll to find the one you want and the connection window isn't resizable. Also, you can't attach notes or classify them in any way. Gate One's bookmark manager is so much nicer (and faster to navigate).
* Gate One terminals don't clutter up your task manager. I've seen Systems Administrators struggle to find the right window when they have dozens of PuTTY windows open. Some other SSH clients support tabs but those can get out of control just as quickly. Gate One's grid view lets you manage (and find) a large number of terminals very efficiently.
* Gate One's session logging/recording, playback, and sharing features. PuTTY supports raw, text-based logging but it is unreliable (if you don't shut down PuTTY properly the log will be lost).
Of course, there's other features you might like but I won't enumerate them all here. PuTTY does some things Gate One can't do (e.g. port forwarding) but for most day-to-day stuff Gate One will probably be better.
I don't see any reason why implementing SSH in JS wouldn't be possible. You'd need a small server-side part to wrap TCP to WebSockets, but it shouldn't need to touch SSH in any way. Otherwise there shouldn't be really many obstructions. Yes, it might be slower than OpenSSH, but at least it would be secure.
edit: found websockify[1], which should be enough as the server-side component. Now only client-side remains :)
You'd need a small server-side part to wrap TCP to WebSockets, but it shouldn't need to touch SSH in any way.
You probably mean WebSockets to TCP. That kinda kills the client-side concept. That is a neat little library though.
Otherwise there shouldn't be really many obstructions.
The entire point of SSH as opposed to Telnet is that it uses encryption. That means you need to do encryption in JavaScript. Now, I have a number of encryption algorithms that I use on a regular basis in JavaScript for short strings. In theory, you can do it for longer strings. In practice, I suspect you'll grind your browser to a halt.
Would be interesting if somebody else tried it though ...
The entire point of SSH as opposed to Telnet is that it uses encryption.
Exactly. And that's why I'd prefer complete end-to-end encryption instead of giving plaintext to a middleman (or in worst-case scenario to an unknown middleman).
edit: Re: Performance. Best source I could find[1] about encryption with JS claims unoptimized AES implementation doing 30 kB/s in Firefox 3 on 2 GHz Core 2. Certainly enough for interactive use.
We get to see all kinds of impressive stuff here at HN. I was skeptical about what this was for the reasons you pointed out. An SSH client in javascript and HTML5...
"HTML5 SSH Client" is a misleading title because is not accurate. The heavy lifting resources to python and system calls.
Gate One just comes with a bundled SSH plugin that makes using it for SSH really convenient. You can actually use Gate One to run any terminal application you desire. For example, if you run "sudo ./gateone.py --command=/bin/login" Gate One will instantly become the equivalent of logging into the host's console. It can be a great (secure) back door into a server in case SSH or PAM auth ever breaks.
There is FireSSH, a SSH client entirely written in javascript. I did not try it out, but it looks as if it should not be that much work to embed it into an own page.
Edit: From the paramikojs library:
Q: Can I use FireSSH on a webpage?
A: It's not possible at this time. The web at large currently doesn't allow javascript the same amount of permissions like addons have. The main issue is basically making socket connections. No, websockets don't cut it :-/
FYI: Gate One was developed entirely by one guy in his spare time over the course of ~9 months. It turned out pretty good so he's looking to start a business out of it.
anyone know how he plans to do that? license it under different terms to network hardware device vendors for integration or something?
The repository's LICENSE.txt states, "if the terms of the AGPLv3 license do not suit your needs, a proprietary
license may be purchased from Liftoff Software," so I would assume that you are correct.
1) Gate One is licensed under the AGPLv3 which requires that you publicly distribute the source of anything that uses Gate One. Even if it is hosted via a SaaS or ASP solution. So if you want to include Gate One into another product you'll either have to make that product open source or buy a license (which will be available when Gate One reaches 1.0).
2) Support contracts. There's no requirement that business buy a support contract just to use Gate One inside their organization (please do!). Having said that, in my experience most businesses would be happy to pay for support if the price is right. Especially if there's worries about licensing (and many organizations are terrified of the AGPLv3).
I chose to write my own terminal emulator from scratch because after trying various existing open source implementations (including the one in Ajaxterm) I decided they were too slow, buggy, or incomplete. I have old versions of Gate One that used a modified version of Ajaxterm's emulation, Termemulator, and one other that I can't remember right now.
The biggest reason of all was the speed. Gate One needed to support multiple users running multiple terminals. Every terminal--when the screen is updated--needs to be converted into HTML and sent to the client. I wrote terminal.py to be as fast as possible with this purpose in mind.
For reference, I hadn't heard of pyte until I saw your link just now. I'll definitely be checking it out.
Having said all that, now that I've already written my own terminal emulator for Gate One, it includes some additional features that only Gate One is suited to take advantage of (special escape handlers that only terminal.py would know how to handle--for plugin authors to use). I don't think it would be practical to use something else at this point.
I understand your point, there's two problems with most of the terminal emulators I've seen:
- they are either poorly or completely unsupported
- the code is a nightmare, badly written, undocumented
Both make extending a VTE an almost impossible task. Actually, that's why we (at Selectel) wrote `pyte` [http://github.com/selectel/pyte], which soon became open-source.
As for speed issues, have you considered implementing incremental updates (like in AnyTerm, for example)? This approach works perfectly in our setup (multiple clients, multiple terminals).
P. S. Looking through the code, I can tell that you had some tough nights throughout those 9 months :) Good job!
Open source projects need a RELATED_WORK.txt like the section at the end of academic papers. Each project would get a summarised one paragraph comparison.
Actually, some of them do have it -- `xterm`, for instance has a lists of flaws in other terminals. `pyte` on the other hand only mentions similar projects.
Very cool. But I don't like all the options on the right. It could have been simpler. You have the tabs in your browser. Why add another way to make screens in a screen? Though splits could be handy..
I think because different Tabs are sandboxed from each other. Looking at the code in GitHub, the browser is communitcating to a server based application. By doing this in one browser window, you only need on connection between the browser and the server.
This is exactly right. Having said that, I plan to add support for detaching terminals into their own tabs to Gate One in the future. There's no technical reason why it can't be done but it will require a lot of coding.
There's another advantage to having all your terminals under one tab: They don't clutter up your tabs! LOL! If you've ever had a dozen or so PuTTY windows open you'll know that they can really clutter the heck out of your task manager. Having a zillion tabs open would have a similar effect.
I've thought about similar ssh client for Kindle Keyboard 3G web browser. With 3G you are getting free over the world coverage with no issues with battery. Slow e-ink screens are not a problem for terminal. So you are able to fix problem on your server almost any place in the world.
This looks like an impressive, feature-rich version of escape from the web (https://launchpad.net/eftw). Both use tornado on the backend and there seem to be some similarities in the multiplex classes. Escape from the web in turn shares code with ajaxterm.
Both (gateone and eftw) render terminal output on the server side using a python terminal emulator, while shellinabox mentioned in another comment uses a Javascript terminal emulator on the client side.
Edit: The docs say, the terminal class was written from scratch.
Hah, nice find! You'll be interested to note that I am the author of both Escape From The Web and Gate One. Once WebSockets became generally available I decided to write a new application from scratch in order to take advantage of the technology. The primary motivator was that I wanted a web-based terminal emulator that could support multiple terminals (among other things).
Also, the two work on completely different principals. EFTW uses long-held HTTP streams (which differs from Ajaxterm's long-polling method) while Gate One uses asynchronous WebSockets. WebSockets are vastly superior to the old AJAX methods in that they're much less bandwidth/CPU intensive and provide an order of magnitude less latency.
Wait a second...is he correct on the AGPL? We have a legacy application which runs on linux...I'd be very interested in exposing it to our internal business users through something like this, but not if I had to give the source away. However, I'm not sure how this could be the case...it technically wouldn't be part of the application...it'd only be a way of accessing it.
That said, if we get value of it, I'm not opposed to paying for it either. I'm just more interested in understanding whether the AGPL really forces this.
Does the GPL require that source code of modified versions be posted to the public?
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
As long as the use was strictly internal to your organization the only people you'd have to give the source to would be the users. This includes 3rd party companies you might have a business relationship with (though I doubt they'd put such a pressure on you =).
The bigger concern with such an integration is if it ever gets exposed to the Internet at large. Then you'll need to distribute the source or be in violation. Why risk it? Licenses will be pretty cheap for such one-off situations. Everything is negotiable regardless.
ianal, but i believe that using it to connect to your service would not require you to release the code of your service. You'd only be required to release the code of any modifications to the Gate One software. (that is, i personally would not interpret it as making your service a "derivative" of the terminal emulator.. Maybe a lawyer could make that case though.) either way though, nothing stops you from making him an offer, provided he has the full rights to relicense it for you.
I wrote my own web-based terminal emulator, but shortly thereafter found shellinabox (http://code.google.com/p/shellinabox/) and I use that instead. It looks like GateOne might be a bit more configurable, and I don't think shellinabox does tiling or bookmarks. Can anyone else comment on other relevant differences?
- unicode characters (for instance you can't type in russian) -- try there http://demos.anyterm.org/shellinabox_nano
- speed could've been better, there's a noticeable delay when running something like `mc`
I haven't tried Gate One yet, but I did look very closely at your project at some point. Great work, btw :)
Very, very cool - fyi your site is giving me the ol' 403 - (http://liftoffsoftware.com/) (if this just because you're getting it up and running let me know and I'll delete this!)
Strangely, the last line of the README file says "NOTE: http://liftoffsoftware.com/ hasn't been built yet so links pointing there will be dead for a while."
I guess an "Under Construction" animated GIF would be better than a 403
An INSTALL file would be nice, but the docs are there, if buried. For my Ubuntu 11.04 install, it was smooth sailing after I purged my stock version of Tornado and upgraded to 2.1.1.
I'm not understanding how (why?) this would be useful. Accessing a server through http and pipe everything to some other server, why would I want to do that instead of directly connect to my server?
What advantage does this have over running ssh normally on my terminal, or putty?
Not being sarcastic, just genuinely curious about the rational of this application.
Bypassing overly tight firewalls and/or execution policies is one reason. Basically this enables you to use SSH with any machine, even if it was firewalled to allow only port 80 and/or doesn't allow executing anything other than browser.
- Easier to run on your 'mom's computer'
- Easier to get it to work on ipod/ipad without downloading the app.
- May avoid the ssh-key annoying stuff on different servers. (For instance, you've got a vps somewhere.. you can just login there to access your stuff; it makes it easier to associate which ssh is which).
- For device with only browsers (google laptop for instance)
- To have *everything* in the browsers; emails, todolist, consoles, etc.
- To make it easier to add some goodies; I.e. you've got the tab open, but you can bind some javascript stuff to ease your workflow. Way easier to write a chrome extension than modify Putty.
- Run it from school or jobs that need administrative access to do trivial things. (I.e. One could use emacs from his browser if he couldn't install it on his computer).
My use for software like this (I use shellinabox [1] on my server) is being able to access a secure Unix commandline from absolutely any Internet-connected machine in the world.
Most recently, I was able to rebook an upcoming flight in Sabre (a travel agent's reservation terminal) from an internet kiosk in the Hong Kong subway. It ran a very weird kiosk-mode browser based at least in part on IE 6.0, but I was still able to securely [2] open a terminal session on my server.
[2] I have an SSL certificate for my shellinabox vhost, which protects both the Javascript client code and the terminal communications; while I do have to trust that the web browser is properly validating the SSL certificate, it's pretty much the most secure solution possible that doesn't involve carrying around my own hardware.
Besides what the others have stated (which are some really great reasons), Gate One will resume your sessions if you lose/regain network connectivity, close/reopen your browser, reboot your computer, etc.
Also, there's compliance (Gate One can be configured to log everything every user does--even to a central log server), the awesome bookmark manager, and then there's the fact that it is pretty much your only option if using a Chromebook :).
Side note: Gate One also has an interesting feature in that you can kill the Gate One daemon, start it back up, and everyone's sessions will be restored. It does this by way of the dtach program. This feature is actually the groundwork for some big things coming in the future for Gate One. Features that will likely make the front page again =)
* Similarly, supports server-side logging, recording, and video-like playback of user sessions. It can even log to syslog to support whatever centralized logging system you want.
Why does auditability scare you? Besides, it is a requirement of many laws and industry regulations. Especially the log-to-syslog capability which enables centralized logging of sessions.
Because the point of SSH is that it's encrypted and secure, thus not eavesdroppable my any intermediaries.
Edit: To put it other way, this feels like using telnet to connect to a server where you can then ssh where you were going to. And the telnet server recording all traffic that goes through it.
I could see a number of use cases for this. However, I would like to know that it has been vetted for possible security issues.