screen -x and/or Shared Shell
Friday Apr 27, 2007
One of the comments on Joerg Moellencamp's recent blog entry talked about Gnu "screen" providing similar functionality with Shared Shell (my apologies if I'm not getting the gist of the German thread on that entry). I thought I'd make a few comments about the difference between Gnu screen and Shared Shell at the user- and technical level. I don't consider myself an expert on screen, so please make any corrections down in the comments section.
Here are some of the obvious difference I can see:
- Shared Shell's network architecture uses a rendesvous server for all the sessions to route messages, do authentication, and do server-side logging. With screen, you need to have all users logged into the same host to start.
- The secure random "invitation key" model of Shared Shell allows remote participants to join in a session, without the need to set up a login on a gateway server or target server (or without, gasp, giving a Sun engineer your username and password). The ephemeral nature of these keys -- single use and single session -- ensures they cannot be used at a later time to access a system in an unauthorized fashion.
- Shared Shell has built-in proxy traversal code that helps you connect through an https or socks server. With screen, you need to use an ssh client capable of traversing a proxy to connect to the host running screen.
- Java vs. C code - by being a Java app, we can take advantage of Java Web Start for launching and auto-update with no install except for a Java VM (of course, web start isn't perfect). With screen, you need a copy installed on a target or gateway machine and you need an ssh client installed on all the participants' machines.
- Screen is a text-only (n)curses app, which inherently can be speedier and more responsive than the Swing GUI used by Shared Shell. Screen may be easier to use from an accessibility standpoint since it is all managed from the keyboard, but in Shared Shell we have tried to follow all Java Accessibility guidelines, so it should work as well.
- Color-coding: output from each participant in a Shared Shell session gets coded, allowing easy review of who-did-what.
- Annotation: Shared Shell lets you draw on the screen to highlight areas of concern. These annotations stick with the text as it scrolls.
- SSA has Built-in chat and file transfer between participants where screen, true to the unix philosophy, just does terminal management.
- Shared Shell has built-in logging both on the initiator and on the server side, saving all the terminal output, etc. With screen, I believe you have to use script(1) to do logging -- which will capture both input and output (including non-echoed passwords), nor capturing who-did-what. Shared Shell only captures terminal output, avoiding capture of most passwords.
- Right now, screen does a better job of handling unexpected disconnects, due to its history in the dial-up modem era. We're working on better dis/re-connect handling for subsequent patches and releases of Shared Shell.
In summary, I don't want to say one is better than the other -- I think they serve orthogonal use cases: screen can work well in a LAN or WAN environment, especially where every participant has a login on a gateway host or on the target server itself. It's fast and light and good at what it does -- multiplexing 1 or more terminal sessions.
Shared Shell, on the other hand, was designed from the betting as a remote support tool, where the initiator and participants are separated by the Internet, and tries to help with the end-to-end connectivity. It's also designed to be run by less-experienced administrators and started from a pure-GUI environment like Windows. There's also nothing stopping you from running screen inside a Shared Shell session if you need to connect to multiple systems, have multiple tasks going at the same time, or handle the possibility of an unexpected disconnect. I believe our vt100 emulation is sufficient to use all of screen's capabilities.
As always, feedback and comments are appreciated.
|
|
|
|
