Gate One 0.9 Released, Brings SSH To the Web

Riskable writes "Dan McDougall (full disclosure: That's me) just publicly released the source code to Gate One, which is an HTML5-powered terminal emulator and SSH client. It is unique in that it doesn't require any browser plugins (it uses WebSockets) and supports multiple simultaneous terminals/SSH sessions in a single browser tab. It can resume users' sessions after being disconnected, and supports both client and server-side session recording/playback (view as a log or like a video). Gate One can also be embedded into other web-based applications such as administration interfaces, serial port concentrators, virtual appliances, or whatever."

Comments

sshd

[bolthole]

When is sshd in html5 coming, then?

Re:sshd

[Synerg1y]

are you talking about mixing a web language with a protocol?

Re:sshd

[Pieroxy]

That would be implementing a protocol with a language actually. Which makes sense, if the language was a programming language.

Re:sshd

[loufoque]

sshd is not a protocol, it's a daemon.

Re:sshd

[Tsingi]

Yeah, I have no clue what sshd in html5 means
As you say, sshd is a system daemon.

Re:sshd

[loufoque]

You can code a ssh daemon in javascript.

Re:sshd

[rwa2]

When is sshd in html5 coming, then?

It's been out for a while...
http://antony.lesuisse.org/software/ajaxterm/

Unfortunately, it's still blocked by work; grrr :-P

Re:sshd

[thePowerOfGrayskull]

A daemon is just a program that runs in the background. A daemon can be implemented in practically any programming language.

Re:sshd

[Anonymous Coward]

There's also an event-based version of it called “eftw” (python, Tornado).

Re:sshd

[Synerg1y]

SSHD = ssh protocol daemon , my point is you don't run programs behind programming languages, you write programs in programming languages. He's talking about something that already exists so my question was a bit satirical. I'm not going to look into how to do it though for html, the correct thing to ask for would be ssh protocol integration into html5, so that you can make ssl calls using html 5, rather than have your web server redirect, or a web.config in .net. Point remains SSHD != HTML5 on any plain I'm familiar with.

Should be 1.0

[Anonymous Coward]

Sounds like this should be Gate 1.0

Re:Should be 1.0

[stillnotelf]

Eternal beta worked well for GMail... (although frankly I agree with you)

Re:Should be 1.0

[tesdalld]

Its Gate .05 because its beta. If it was Gate 1.0 it would be version cupcake.

Re:Should be 1.0

[bugnuts]

It is, but it's spelled "Gate One".

The arbitrary version is 0.9.

I'm newb

[tesdalld]

I looked over the source code.... so how do i use this?

Re:I'm newb

[GameboyRMH]

Looks like it runs as its own service, like a single-purpose http server. So it's not really pure HTML5 then, it's a service with an HTML5 frontend.

Re:I'm newb

[omnichad]

Yeah - It's Python. No mention of that in the summary. My first thought was that it used WebSockets to make a connection to the real server, not an intermediate server. Shouldn't that be possible with a little more robust coding??

Re:I'm newb

[GameboyRMH]

Unless there's a way in JS to open arbitrary network connections (and I don't think there is) it's not possible, since all WebSockets traffic is actually specialized traffic that runs on port 80. JS can only do WebSockets and regular HTTP requests AFAIK.

Re:I'm newb

[tesdalld]

I just tried to install it, coppied it all to my server and was getting ready to enjoy this neat tool. Its for linux only at this point and i only have IIS. Le Sigh.

Re:I'm newb

[Riskable]

Install the dependencies:

sudo pip install tornado pyopenssl kerberos

...or if you don't have pip:

sudo easy_install tornado pyopenssl kerberos

Then use git to check out the code:

git clone git@github.com:liftoff/GateOne.git

Then you can run it like so:

cd GateOne/gateone; sudo ./gateone.py

...or you could just cd into the GateOne directory and run:

sudo python setup.py install

Which will install /opt/gateone. Then you could run it like so:

sudo /opt/gateone/gateone.py

There's some (incomplete but extensive) HTML documentation included in GateOne/gateone/docs/build/html/. "gateone.py --help" is also useful.

For reference, I haven't written any init scripts yet... Forthcoming (trying to get some .rpm and .deb releases out as well).

Re:I'm newb

[omnichad]

Oh, right. I guess that's why they don't just call it Sockets. Still a misleading summary.

Re:I'm newb

[Anonymous Coward]

This year is certainly the year of Linux on the desktop!

Re:I'm newb

[DragonWriter]

Unless there's a way in JS to open arbitrary network connections (and I don't think there is) it's not possible, since all WebSockets traffic is actually specialized traffic that runs on port 80. JS can only do WebSockets and regular HTTP requests AFAIK.

You can open arbitrary network sockets in JavaScript, if you are using JavaScript in an environment that supports it (node.js, for instance), but, largely for security reasons, no browser-based JS implementation (at least, that I know of) supports this.

This isn't a JavaScript issue, its a browser-as-platform issue.

Re:I'm newb

[oakgrove]

Try this. You'll love it.

Re:I'm newb

[oakgrove]

You must have dug really deep for that one. Don't hurt yourself.

Re:I'm newb

[dolmen.fr]

This is the real "Linux on the desktop".

Re:I'm newb

[DarwinSurvivor]

Exactly. If you could open arbitrary connection in JS, then your entire internal network would be vulnerable to the simplest of JS code.

Re:I'm newb

[styrotech]

You might have a point if the Windows or Mac procedure of building and installing a Python source package off github didn't look practically identical to that.

There was nothing *nix specific about any of those instructions.

Cool

[pinkeen]

No more downloading putty!

From what I see ncurses apps work great too.

Re:Cool

[mrclisdue]

I'll second the coolness. Very nice work.

cheers,

Re:Cool

[Anonymous Coward]

No more downloading putty!

Instead you need to download and install python and a python based server.

Nice job!

[Drivintin]

Honestly the first practical thing I have done with HTML5. This thing is nice, clean, and fast!

Re:Nice job!

[Desler]

Except it's a python app with an html frontend. Not that impressive.

Re:Nice job!

[Tsingi]

I was looking for this exact thing just this morning. It's not hugely impressive, but it looks like no one else has done it. I did come across a lot of messages saying how it should be done.

Happy to see the code, I'll try it out. Much better than having to write it myself.

This isn't new.

[lolcutusofbong]

Shellinabox has been doing this in JavaScript for a while now. There's source and binary packages for everything from Red Hat to Debian armel.

Re:This isn't new.

[Anonymous Coward]

Um, no. This is new, and shellinabox is something quite different.

Re:This isn't new.

[Anonymous Coward]

what about FireSSH? http://firessh.mozdev.org/

Re:This isn't new.

[Anonymous Coward]

Or AnyTerm (http://anyterm.org/)?

Re:This isn't new.

[oakgrove]

Can you automatically resume the connection when closing and reopening the browser? Gate One does this.

Re:This isn't new.

[Anonymous Coward]

You could use GNU screen (or a handful of similar programs) to handle the reconnection, and as a bonus the same session can be moved amongst an xterm window, a ssh session, your HTML5-ified virtual terminal of choice, or a real live terminal connected to a serial port (or modem). Building it into the front-end limits its functionality dramatically.

Re:This isn't new.

[Riskable]

By default Gate One runs all sessions through the dtach program which is like a mini version of screen... So you CAN resume a session started from Gate One via some other connection method (e.g. traditional ssh). I really need to document how to do this because it is a pretty cool feature.

Re:This isn't new.

[Anonymous Coward]

screen

Re:This isn't new.

[lolcutusofbong]

You're so cool.

Re:This isn't new.

[jefe7777]

...just a head check, to see if anyone's paying attention.

this changes everything :)

[brenddie]

awesome job. Cant wait to try it on the intranet

Whatever?

[courteaudotbiz]

such as administration interfaces, serial port concentrators, virtual appliances, or whatever.

What is the "Whatever" part? Toasters? Refrigerators? :-)

Re:Whatever?

[Riskable]

If it ever comes up in court I'm going to refer to your comment as evidence of obviousness!

Re:Whatever?

[Baloroth]

Rockets.

Python?

[Anonymous Coward]

The source code looks like a bunch of Python files. Somehow I expected an app written in HTML5 to be a bunch of .html files. What am I missing? Does Python run in the browser now?

Re:Python?

[Zancarius]

It looks to be written using Tornado, which means that the WebSocket app is served up by the Python backend. In other words, this isn't a stand alone HTML-only implementation, which would be impossible since that's not what WebSockets do.

again with the "full disclosure" ?

[Anonymous Coward]

Please learn the appropriate time and place for "full disclosure" usage.

Re:again with the "full disclosure" ?

[Anonymous Coward]

Or, you know, maybe he was using it in the journalism sense (the one that's been around a hell of lot longer) and not in the computer security sense. In which case he's right and you're a fucking moron.

Re:again with the "full disclosure" ?

[Anonymous Coward]

Could not have said it better myself.

ft

!HTML5 Powered

[Anonymous Coward]

Um, it's written in Python and runs as a service with a HTML5 frontend.

Re:!HTML5 Powered

[nam37]

My thoughts exactly unless I'm missing something.

Re:!HTML5 Powered

[Anonymous Coward]

Meh, cheating. It uses a Python backend to do the heavy lifting, this isn't "HTML5 powered". I could make a "HTML4 Powered" one without any Javascript at all which uses form POST, frames and Meta Refresh page to act as a SSH client too if I could use a backend like this. This isn't some HTML5 voodoo magic just another pretty frontend.

Re:!HTML5 Powered

[Riskable]

I could be feeding a troll here but... The problem with writing a terminal emulator using old-school methods ("HTML4 Powered") is the latency and overhead associated with long-polling and long-held HTTP streams. It would be incredibly slow and inefficient to have more than one terminal open at a time. I know this for a fact. How?

I've written such an app

No one ever used it--not even me. Because it sucked. Without WebSockets and Web Workers such a thing will always be slow. Without HTML5's "contentEditable" ability you can't even copy & paste properly.

Re:!HTML5 Powered

[Timmmm]

Well obviously. The client is written in HTML5. If you knew anything at all about HTML5 you'd know it is impossible to write a "true" ssh client using HTML5. Instead this connects to a python server which then goes on to connect to the actual sshd. The point is that you don't need an ssh binary installed on the client.

You could actually remove ssh from the equation, but it looks like the gate server allows you to connect to *any* ssh server, so I guess that's why they didn't do that.

Re:!HTML5 Powered

[Anonymous Coward]

You missed my point, that was an extreme example. I was just saying that nothing done here couldn't have really be done before. It's not HTML5 powered, it's powered by the Python backend.

Re:!HTML5 Powered

[multipartmixed]

> it is impossible to write a "true" ssh client using HTML5

Not so fast. Assuming you mean HTML5 + JavaScript, I think you could, provided you were allowed to hop through an HTTP proxy that supports the CONNECT method.

For those of you about to suggest that a crypto stack written in JS would be slow -- I don't think it would be as slow as the CPU in my 15-year-old Cisco switches.

Re:!HTML5 Powered

[dolmen.fr]

The real HTML5 power would be if the SSH encryption was implemented on the client in JavaScript. I'm sure someone will soon do it.
With the current implementation the Python back-end is still a man-in-the-middle that knows the user password and can record everything.
Anyway the terminal emulation and chrome around it looks cool!

Re:!HTML5 Powered

[Anonymous Coward]

So people shouldn't be corrected if they're obviously wrong?

Re:!HTML5 Powered

[Timmmm]

Wouldn't work. You can still only send HTTP or websockets, and websockets have hand-shaking and framing that you can't remove.

Re:!HTML5 Powered

[Riskable]

I wanted to point out that you're absolutely right: Gate One *could* be modified to record user passwords. But then again, so could the SSH server you're connecting to. The attacker wouldn't even have to change the host keys. So with SSH you have to trust the server you're connecting to and Gate One is no different.

I would *LOVE* to put the encryption on the client end though. That would be one hell of a hack and I'm willing to give it a try. My biggest worry would be that JavaScript might just be too slow to handle it (really, even with all the latest JS engine improvements it is still that slow).

Re:!HTML5 Powered

[Anonymous Coward]

You could certainly write SSH client with HTML5 and websockify[1]. That way the entire SSH protocol would be implemented client-side.

[1] https://github.com/kanaka/websockify

Re:!HTML5 Powered

[Anonymous Coward]

I wanted to point out that you're absolutely right: Gate One *could* be modified to record user passwords. But then again, so could the SSH server you're connecting to.

No, it couldn't, in general -- your private key is never sent to the server, much less the passphrase to it. It's only if you use password (or keyboard-interactive) auth that you have to trust the server -- which is why those are not recommended!

Since the SSH connection terminates on the server (with the python backend) I can only assume when you do add public-key auth, the client will send the entire private key to the python backend, which will serve as an agent. Which is fine if we trust the server not to have been compromised, but if we were that arrogant, we would be using password authentication to start with. The whole point (well, the biggest point) of PK auth is that logging into a compromised server doesn't give them anything useful -- your private keys stay on the local machine (where your agent is running).

• So if you ssh into a compromised host with PKI, then ssh from there into another host, the compromised host has no ability to ssh into that second host after you've gone, even though it saw the whole connection. Security win!
• With password auth, the above scenario lets the intermediate compromised host see your password for the second host, and then masquerade as you -- but at least if you use different passwords for every host, they only get that one.
• With PKI auth handled on the server side a compromised host uses a modified version of the GateOne backend which steals your private key; now they can login as you everywhere. (Unless you use separate private keys for every server, which no one does, since you don't need to, they're not at risk unless someone fubars security by rolling ssh into the wrong side of their AJAX vt!)

Please tell me that my surmise is wrong, and you're really going to implement SSH clientside (in javascript that the user can at least theoretically check for modifications!) rather than serverside. Failing that, at least warn users about the risk before they upload a private key.

Re:!HTML5 Powered

[Anonymous Coward]

And of course I misspoke...
s/implement SSH clientside/implement the SSH key agent clientside/

Re:!HTML5 Powered

[Anonymous Coward]

Sooooo, it's only *Secure* SHell once it leaves the backend server (hosted by someone, somewhere)? What could posibly go wrong?

Re:!HTML5 Powered

[msobkow]

Ooo. A web app. That really deserved the front page of Slashdot.

Tomorrow on Slashdot: Someone compiles a program.

Re:!HTML5 Powered

[Riskable]

The problem with private keys as you suggest is that they have vulnerabilities of a different sort: They don't scale and they lack centralized administration. Someone suggested in another thread that it would be great if users could store their private SSH key on a USB thumb drive. To me, this sure sounds convenient to the user but it would be a nightmare for anyone that employed them. They could be fired for insubordination and walk right out the door with a key that lets them remotely access all of the company's servers--even if you disable their account from a centralized location (LDAP, Active Directory, etc). To truly disable their access you'd need to login to every server they ever had access to in order to remove their authorized_keys file (you could use the SSH Power Tool to do it--which I also wrote =).

Where I work we have over 40,000 Unix (or Unix-like =) servers and only about 2,000 of them have some kind of NFS-mounted home directory setup. Those servers are managed by about 37 different IT organizations across the planet but nearly all of them (except those in DMZs and special restricted environments) can be logged into via user's Active Directory accounts. There's literally hundreds of teams of sysadmins, DBAs, and application administrators of varying sorts that administer their respective things across a wide variety of geographic locations and organizations. There's not a single admin team that has access to everything the other teams have access to. Also, there's a number of servers that you can't just login to (to make a change) except during special maintenance windows on the weekends (don't ask--super duper restricted--all sorts of alarms would go off and regulators would probably storm in, LOL).

I have friends that work at other big businesses with similar situations (tens of thousands of servers with accounts managed via AD/LDAP). When an employee leaves the organization, how do you propose you disable their access? With key-based authentication you need to visit every server they ever logged into to make sure their authorized_keys file is disabled. With password-based authentication you only have to disable their account in AD/LDAP (it's a cinch!).

I can go on and on about this topic... Especially in regards to Kerberos authentication, 2-factor methods, and whatnot. But the point I'm trying to make is that key-based auth isn't the be-all, end-all to SSH authentication that you're making it out to be.

Re:!HTML5 Powered

[heathen_01]

I could be feeding a troll here but...

People do not yet understand the power of websockets yet. Keep up the fantastic work.

Re:!HTML5 Powered

[Anonymous Coward]

"Instead this connects to a python server which then goes on to connect to the actual sshd. The point is that you don't need an ssh binary installed on the client."

i don't get it. isn't the python server implementing some sort of ssh client binary? what's the point of this? it seems equivalent to writing a webpage that can control and receive info from putty. again, the purpose for doing this doesn't seem to be explained anywhere.

Finally, an ssh client as secure as a browser!

[Vellmont]

I've always dreamed that one day, someone will make an SSH client in a browser so all the fun XSS,, CSRF, and the bevy of other web vulnerabilities could come to SSH. SSH has just been to darn secure over the years, but now with this new application, an SSH client can be just as insecure as everything on the web. Thanks!

Re:Finally, an ssh client as secure as a browser!

[Pharmboy]

An SSH client can be insecure without it being in a web browser. It isn't the programming language that makes it insecure, it is the programmer.

  I can picture plenty of ways to use this as a lame method to exploit, but they are all more effort than the current methods. I guess someone could embed this in a hidden webpage popup, use the persons computer to then try to hack various sites via ssh, but that seems like it is more work than using a simple trojan to install a background process to do the work instead.

Re:Finally, an ssh client as secure as a browser!

[Animats]

Mod parent up.

Not everything should be done in a web browser.

Take a look at the source code which stores SSH authentication information in browser cookies. In plaintext. In JSON. Idiots will start using this, and they'll open a back door into a remote server.

Re:Finally, an ssh client as secure as a browser!

[Vellmont]

It isn't the programming language that makes it insecure, it is the programmer.

It's the programmer, AND the environment the application was written in. A web browser isn't exactly a secure environment.

Re:Finally, an ssh client as secure as a browser!

[Tacvek]

No ssh authentication information is stored in cookies. Only the username used to authenticate to GateOne itself lives in the cookie, and it is a signed unforgeable cookie.

Re:Finally, an ssh client as secure as a browser!

[Riskable]

If you weren't in such a hurry to be negative you'd realize that the cookies are ENCRYPTED. And I'm not just talking about the fact that Gate One runs over SSL. No, the cookie Gate One uses is itself encrypted. There's a reason why the function is called set_secure_cookie().

Re:Finally, an ssh client as secure as a browser!

[Riskable]

Let's see...

XSS: Since there's no "cross-site" anything in Gate One I'd be really interested to see how this would work!
CSRF: Again, there's no "cross-site" to speak of.

The only vulnerability that concerns me with Gate One is the potential for session hijacking... To get around this Gate One uses encrypted cookies but that doesn't stop an attacker from copying the entire cookie. Then again, if the attacker has access to the cookie in such a situation they probably have access to the whole browser so it's probably moot.

Re:Finally, an ssh client as secure as a browser!

[Anonymous Coward]

I guess someone could embed this in a hidden webpage popup, use the persons computer to then try to hack various sites via ssh, but that seems like it is more work than using a simple trojan to install a background process to do the work instead.

As far as I understood, the ssh connection is made from the python back-end on your own webserver. You would be hacking from your own IP-address and can do that without the webpage.

Emulator?

[AaronLS]

I'm curious why is the term "emulator" used? What about this makes in an emulator of a SSH terminal? Is it just because it's being run in a web browser?

Re:Emulator?

[Sancho]

http://en.wikipedia.org/wiki/Terminal_emulator

That may help you understand.

Re:Emulator?

[cornface]

Because it is emulating a terminal, which back in the stone age was an actual piece of physical hardware.

Sometimes they were magical interactive typewriters which is where the abbreviation 'TTY' comes from.

Re:Emulator?

[Anonymous Coward]

http://en.wikipedia.org/wiki/Terminal_emulator

Re:Emulator?

[Anonymous Coward]

Probably that the terminal is receiving/outputting control codes for a (say) VT100 terminal. The software emulates a VT100 terminal by interpreting/generating those codes.

http://en.wikipedia.org/wiki/Terminal_emulator

Re:Emulator?

[petermgreen]

A terminal is a peice of hardware with a keyboard and a screen or printer that you use to access a computer.

A terminal emulator is a software program that runs on a general purpose computer that has a local keyboard and mouse and emulates a terminal. Usually a fairly advanced terminal.

A ssh client is a peice of software used to log into a remote computer over ssh and connect your terminal to it.

On *nix terminal emulators and ssh clients are usually seperate but ones designed for use in other environments are often integrated together.

Re:Emulator?

[Anonymous Coward]

Just a guess, but all ssh clients (putty, etc) are terminal emulators, because they aren't actually terminals.

Re:Emulator?

[msobkow]

It won't be too many years before someone would have posted in response to your comment:

"What's a typewriter?"

Just a matter of time. My nieces were already baffled by a couple cassettes I had lying around.

Re:Emulator?

[cburley]

Because it is emulating a terminal, which back in the stone age was an actual piece of physical hardware.

Sometimes they were magical interactive typewriters which is where the abbreviation 'TTY' comes from.

Pretty sure 'TTY' comes from "Teletype".

Re:Emulator?

[cornface]

What do you think a Teletype is? Teletypewriter. Jesus christ.

Not all parts run in the browser

[Anonymous Coward]

Seems to be that Python is doing the real work and being a web server, and the HTML/js part interfcaes to there. Not bad, but... not ssh in html5/js either.

Does it require backend functionality?

[hydrofix]

What kind of server-side support does this require? I bet I can not just run it from a static HTML file.

Re:Does it require backend functionality?

[Desler]

It requires the.python app which does all the real work.

SSH keychain support?

[Anonymous Coward]

This is useless unless it supports keys. You should always use keys (with a pass phrase) to access publicly available hosts.

  This is security 101 here.

Re:SSH keychain support?

[Riskable]

Apparently you access a lot of "publicly available" SSH servers? I don't know about you but all the SSH servers I connect to on a regular basis are "private".

Regardless, key-based authentication will be there in Gate One 1.0. Passphrases and all.

Key pairs?

[Neil Watson]

In the demo the author uses a password to login via SSH. In the documentation I see no option to use a private key.

Re:Key pairs?

[Riskable]

Private key support is forthcoming... I had it working just fine but then I had the bright idea of writing a plugin system for Gate One and making the SSH part just another plugin :)

Key-based SSH authentication and user management thereof should be there in 1.0. Really, it isn't rocket science... Just a matter of wrapping a GUI around the functions that are already there in the code.

Re:Key pairs?

[dolmen.fr]

I had the bright idea of writing a plugin system for Gate One and making the SSH part just another plugin :)

Key-based SSH authentication and user management thereof should be there in 1.0.

Are theese the parts that you plan to make your businness with? At least they do not seem to be in the GitHub repo...

Re:Key pairs?

[Riskable]

The business parts will be selling support/indemnification contacts and proprietary licenses ( so companies can embed Gate One without having to comply with the terms of the AGPLv3).

The key management parts of the code are sitting in an archive directory on my laptop at the moment. Just have to do some copying, pasting, and a little bit of logic rework.

Web 2.0

[Sduic]

So I can use HTML5 to SSH into my Linux on Javascript server, so I can play a game of TF2 with WebGL?

Now if only I could surf the web...

...but does require a server plugin

[david.given]

You need a daemon to proxy between the WebSocket connection (which, remember, isn't a straight TCP stream) and the ssh server proper. Although it appears this doesn't need to be on the machine that the ssh server is running on, so it doesn't look like too much of a hardship. Also, I can't find any reference of which of the umpteen different WebSocket variants it supports.

There's actually a number of these things out already, such as ConsoleFish or ShellInABox. There's also an HTML5 VNC client, which looks very interesting.

Re:...but does require a server plugin

[Riskable]

Which variants of WebSockets does it support? Both (there's really only two real-world implementations) by way of the Tornado framework. In earlier builds of Gate One it only worked with the old implementation of WebSockets but once the Tornado guys started supporting the final draft of the protocol Gate One instantly supported it as well.

For reference, I am not aware of a single other web-based terminal emulator that can resume sessions after closing your browser. Even the commercial SaaS vendors don't support this because they're all based on the same code base (Ajaxterm or Shellinabox from what I've seen).

Re:...but does require a server plugin

[david.given]

Yes, that is a neat trick --- the most obvious way I can think of of doing that is to do all the ssh processing on the client, and make the daemon a simply proxy; but a quick look at the source code shows you don't appear to be doing that. Or at least, I couldn't find it.

Unfortunately the platform I'd really like this to work on, my Kindle, doesn't support WebSockets (of any kind)...

I have, in fact, been vaguely thinking about trying to recompile a Java ssh client library under GWT and trying to make this work, but finding such a library that uses message-passing only and not threads is quite hard. Java likes threads.

Re:...but does require a server plugin

[Riskable]

For reference, Gate One can also be used in place of an SSH daemon. Just have it run /bin/login instead of ssh_connect.py. Example

sudo ./gateone.py --command=/bin/login

...and you've got yourself a web-based equivalent to logging into the console. This is especially handy if your server is configured to use LDAP/Kerberos authentication and for whatever reason that broke (you can still login as root this way).

Questions

[dyingtolive]

I have a few questions (so I only skimmed TFA...)

1) Does this handle the actual SSL connection server side, not client side (as certain web based IRC clients I've seen will), so then, for example, this could be used to effectively ssh to a box through an HTTP proxy, assuming the proxy was between you and the webpage, not the webpage and the target box to ssh to?

2) Assuming the answer to number 1 is yes, how does this differ from Ajaxterm? Is it less of a royal pain in the ass to configure? Is it faster? Thanks

Re:Questions

[Riskable]

1) Yes, it can be used to effectively SSH to a box through an HTTP proxy. I do it all the time! The only caveat being that some proxies don't work with WebSockets (old, garbage ones).

2) Ajaxterm uses a completely different method to communicate with the client... long-polling. Essentially, it hits the web server every second (forever--util you close the browser tab) checking for updates to your terminal. This is slow and very inefficient (high latency). Also, it would be silly to use this method to support more than one terminal as you'd have your browser constantly checking for updates * num_terminals. This would gobble up bandwidth and CPU pretty quick :)

Then there's the fact that Gate One has a zillion features that are missing from Ajaxterm... The most important of which is the terminal emulation isn't nearly as buggy! LOL. For reference, I am intimately familiar with Ajaxterm as I wrote an older, similar program a few years ago that was based off of it.

BTW: I HATE debugging the terminal emulator!

Re:Questions

[dolmen.fr]

Then there's the fact that Gate One has a zillion features that are missing from Ajaxterm... The most important of which is the terminal emulation isn't nearly as buggy! LOL. For reference, I am intimately familiar with Ajaxterm as I wrote an older, similar program a few years ago that was based off of it.

BTW: I HATE debugging the terminal emulator!

Do you plan to provide a terminfo definition for your terminal?

Re:Questions

[Riskable]

My goal is to get Gate One emulating an xterm as closely as possible. So xterm's terminfo definition should work. However, it might be the case that Gate One ends up with one or two differences that might warrant its own definition. Great question though... It is something I've definitely thought about.

Re:Questions

[dyingtolive]

Thanks Dan. Sounds promising. I eventually gave up on Ajaxterm just because of how frustratingly slow it was. I'm gonna give your Gate One a shot and see what I think.

TLA

[sexconker]

I'll wait for Gate 1.0 because SG-1 couldn't do shit without a DHD and in SGA they were always frantically hunting for ZPMs.
And when we got to SGU no one knew WTF they were doing because by the point everything was falling apart and no one understood the language.

Re:TLA

[Megane]

CSB

Re:TLA

[Riskable]

No need to wait... Just don't use Gate One during a period of intense solar flare activity. TRUST ME on this one! You didn't last time around and it didn't work out so well!

Ajaxterm

[mrops]

Use it.

Accept for bells and whistles, how is this different from Ajaxterm.

I like all the eye candy and features and no doubt they are an improvement over what ajaxterm offers, however, ajaxterm is already a plugin free html based ssh terminal. Put it behind a apache https reverse proxy and block the real ajaxterm port from internet access and you get a pretty good pure html/ajax ssh shell.

Re:Ajaxterm

[Riskable]

Ajaxterm, when a connection is open, polls the server every second to see if the terminal has been updated on the server (long polling). Also, when you close your browser window your Ajaxterm session will end. Then there's the fact that Ajaxterm doesn't really support proper copy & paste and it has to run at a specified terminal width and height ahead of time (Gate One auto-adjusts rows/cols to fill your browser window).

Gate One uses WebSockets which stay open... Meaning that whenever any of your terminals have updates available those updates are immediately sent to your client. This has much lower overhead from both a bandwidth and a latency standpoint. It also lowers the CPU load on the server.

Gate One will also resume your session after you close your browser and come back... It will even do this after the Gate One daemon itself has been restarted (if you have the dtach option enabled--which is the default). Then of course there's the eye candy, multiple terminals, the ability to clone open SSH sessions without asking for a password, Kerberos single sign-on support, the sophisticated plugin system, the bookmark manager, session logging, and on and on. They're worlds apart.

Having said all that, some of my earlier builds were based on Ajaxterm so I really appreciate that the author posted it publicly! Even though the code was uncommented and used ambiguous, single-character variables for nearly everything =)

Re:Ajaxterm

[Saintwolf]

Shellinabox

awesome

[Anonymous Coward]

awesome, very cool! - it makes it extremely easy to do web browser based secure network projects

Major issues:

[Anonymous Coward]

1) It uses a server-side proxy. We really need a browser-based ssh client that can connect directly. I know WebSockets can't do it, and that's a shame, but honestly how hard would it be for the browser guys to give us the tools to make this happen (regular TCP sockets???).

2) It doesn't support keys.

We really need something that solves these two problems, using encrypted keys off of a USB stick and making direction connections, so that we can do secure shell sessions from browser-only devices (e.g. ChromeBook type stuff).

Re:Major issues:

[Riskable]

Key-based authentication will be available in Gate One 1.0. It used to be there (and work) but it got lost when I wrote Gate One's plugin system and decided that SSH support should simply be a plugin (in case someone wanted to embed Gate One into something else without having all that SSH-specific stuff).

Shouldn't take me long to re-implement it so keep checking for updates.

Re:Major issues:

[Anonymous Coward]

We really need something that solves these two problems, using encrypted keys off of a USB stick and making direction connections, so that we can do secure shell sessions from browser-only devices (e.g. ChromeBook type stuff).

We might "really need" that if anyone had browser-only devices. Closest most people get is a smartphone or tablet. And there are already perfectly good SSH apps for those.

Given that this program requires a complete Python application running in the background, it is only suitable for use on full PC-type devices. And it's Linux-only. Hands up everyone using Linux on the desktop who doesn't already have, uh, an actual native terminal emulator and a native SSH client to run in it? Because last I checked both those were installed as standard on any serious Linux box.

Exactly what problem is this solving? It's a cool hack, but I fail to see any practical purpose for it.

Re:Major issues:

[Riskable]

Gate One is meant to run on a server. As in, you setup a Gate One server on your network and then you connect to it from a client machine (Windows works fine for this). Another way it can be used is on a server... As a backup in case the SSH daemon stops working or, say, to embed a terminal into a web-based administration interface.

Of course, you could run it on your desktop and use it like a traditional SSH client (I do it every day when I'm working on it) but it wouldn't be as useful.

Backdoor inside your network?

[sshambar]

Quick browse of the source makes it look like connections run through a python server... so anyone who deploys this on a gateway server (public web, but internally connected) would expose all internal ssh servers -- or at least that's how it appears.

Of course, using the web auth to connect mitigates the risk (but requires dual auth?) -- it's not obvious from the description that the connections to port 22 don't initiate from the browser's machine... and people may deploy this without appreciating the possible internal network exposure.

Back to my mindterm java client.. *sigh*

no website

[mdaitc]

you're trying to make a business out of it, but don't have a website... and you're still posting this to slashdot??

Re:no website

[Riskable]

So I guess I should've made the website selling the product first before making the actual product? Do you work for Microsoft?

Re:no website

[mdaitc]

no... just wanting to know there's some good old fashioned thought/planning other than throwing stuff into github. It's not an insult, I was just intrigued by the wanting to make a business out of it, but not any more details other than the sample of code. Knowing slashdot, you'd either be loved/hated for different reasons... and as someone who sees through that, I just wanted to make my own mind up.

FireSSH

[jasonla]

FireSSH is better. The client runs locally on your machine through FF. No server plugin required. And you don't have to worry about the server hosting the HTML5 frontend going down with FireSSH, unlike this Gate One's 404 and 500 errors.

Re:FireSSH

[dbIII]

The downside of such things is trying to use them over free WiFi that blocks anything apart from port 80 - or other situations that stop you just getting in with normal ssh. Getting the server to do it all via a web page gets around that problem.

Re:FireSSH

[Anonymous Coward]

Not really. It's not running in a browser context, it's just a regular ssh client implemented as a firefox plugin (and apparently not a terribly good one). If you can install and use FireSSH, you can install a real ssh client. When you can't, or you're working through a firewall that's overly http-friendly, something like ajaxterm or gateone is much more useful.

Re:FireSSH

[daid303]

Port 443 I hope. You better run you web-ssh session over https instead of http.

Re:FireSSH

[dbIII]

I'd hope so too but what do you do when everything other than port 80 is blocked? I'll have to admit my solution when I hit that problem was to go into the office, but there must be some measures that can be taken with cgi scripts that can prevent a proxy getting somehting meaningful out of a web ssh session on port 80.

Re:FireSSH

[Riskable]

There's nothing stopping you from running Gate One on port 80 with SSL still enabled. Your proxy might block the tunnel but it's worth a shot.

Re:FireSSH

[jago25_98]

Bear in mind that this may still have firewalling problems

X?

[markdavis]

OK, but if you can get X11 tunneling though and displaying in the browser, too, then I will be REALLY impressed ;)

Re:X?

[Anonymous Coward]

This is very close to what you're asking for. Unfortunately it only works with GTK+ apps. :-)

http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/

Re:X?

[Anonymous Coward]

Tunneling X11 is the easy part. The hard part is writing a proper X11 server in javascript. But before that happens someone will take the boring, easy way out and implement something more akin to VNC, where the X11 server is on the remote, side w/ the local end just implementing a frame buffer.

Re:X?

[Riskable]

Believe it or not, I have this in the TODO for Gate One 2.0. It will require implementing the X11 protocol in JavaScript using the canvas element. It shouldn't be too difficult... Just extremely time consuming. Which is something I don't have much of these days.

Re:X?

[Anonymous Coward]

Maybe you were joking, but there a rule, similar to rule 34, that says that if you can think of some dumb feature, then someone has implemented it. It's not X11 tunnelling, but you can display now GTK applications in your browser! http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/

For other links and/or videos, search "gtk broadway backend"

A console in a browser - what's next?

[Anonymous Coward]

A browser in a console?
Oh, wait ...

Hard to buy a license

[Anonymous Coward]

When the website is down? http://liftoffsoftware.com
http://www.isup.me/liftoffsoftware.com

Says I don't have permission to access '/' on this server. Is it really misconfigured or is this the slashdot effect?

Re:Hard to buy a license

[Riskable]

I haven't set the website up yet (which is why I didn't link to it anywhere but a few places in the docs). There's also a note on the Github page saying this.

Re:Hard to buy a license

[mamas]

> Gate One is dual-licensed: AGPLv3 or Proprietary.

> static/bell.ogg - Taken from KDE's default sound theme (KDE-Sys-App-Message.ogg)
> which is licensed under the GPLv2:

gplv2 and gplv3 are incompatible. If it's the "gplv2 or later" version, then mention so.
The combining work will be under agplv3.

I assume you're not including that gpl'ed sound file in the proprietary license version. I suggest you clarify that.

Re:Hard to buy a license

[Riskable]

The sound file is only temporary regardless. I'll be picking/making something else for 1.0. Probably the favicon too.

Nice catch though. Most people would never have noticed that.

ajaxterm?

[inzy]

doesn't ajaxterm already do this?

http://wiki.kartbuilding.net/index.php/Ajaxterm

Re:ajaxterm?

[Anonymous Coward]

But also:

    http://anyterm.org/
    http://code.google.com/p/shellinabox/

And I'm quite sure, that there are more ...

Re:ajaxterm?

[daid303]

Guess Slashdot is falling for buzzwords like HTML5. Other then that, it's not special at all.

Re:ajaxterm?

[Kevin Stevens]

Yeah I was going to say, I have been using ajaxterm for a few years now. It has its quirks, but it works and gives me access to my home network. For those times when you just can't tolerate the company firewall, it will do.

Ajaxterm beat this to it

[Anonymous Coward]

Ajaxterm (available in Debian) does this with AJAX. Works great on the iPad except you can't type into it.

Shellinbox

[Anonymous Coward]

http://code.google.com/p/shellinabox/

is useful, in https.

Not new

[monjemono]

There are several projects that do something similar, for example oterm (https://github.com/davidmoreno/onion/wiki/Oterm. Disclaimer: its my project). This one just need 80kb of a executable, everything included. We have used it succesfully on some released products, as the Aisoy1 Robot, although is disabled by default. There are other, mostly written in python, but my google-fu is not working today. Also FireSSH was there before. On gate one the only new thing is that you dont get access to a computer but to a ssh session. Next time I know that whenever I do something remotely new (although I know there are similar things) I have to post to slashdot.

Nice free publicity

[Anonymous Coward]

Man it must be great to get free publicity for doing something many MUD sites and such have been doing for a while. This might have been news in the 90s, at this point though ... not so much.

Java has a real solution

[Anonymous Coward]

Real solution in Java: http://www.cryptzone.com/products/agmindterm/