cooked mode sessions

[Howard Chu]

Picking up on a couple really old threads (e.g.
http://osdir.com/ml/ietf.secsh/2001-09/msg00003.html ) I've finally gotten
around to this. The EXTPROC support on Linux is missing, but you can find
kernel patches for that here

http://lkml.org/lkml/2010/6/11/403

I've also fixed up the netkit telnet / telnetd code to work with EXTPROC /
LINEMODE on Linux, those patches are here

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585527

These ssh patches are still not even half-baked, just a proof of concept to
get feedback and guidance on what the right approach actually is. To get an
idea of where it's coming from you should read RFC1184 which gives the Telnet
LINEMODE spec. Since the ssh protocol doesn't have the Do/Dont/Will/Wont
option negotiation of Telnet things are of course a bit different here.

Instead of explicit negotiation, the server assumes the client supports
linemode if it includes an EXTPROC bit in its tty modes. I've added a new
"tty-changed" channel message as well, for the server to send tty mode changes
back to the client. The client will assume the server supports linemode if it
sends tty-changed messages.

If the server reports that the session tty is in cooked mode (ICANON|ECHO)
then the client will use the readline library to process input. This opens the
possibility of doing full local editing with command history on the client.
(Though I haven't enabled history yet in this patch.)

So far this is only working as expected for dumb programs that don't try to
manipulate the tty modes. I'm working on some patches to the readline library
so that it will leave the tty in cooked mode if it detects that EXTPROC is set
on the tty. So a remote bash shell will defer all input processing to the
local client. Will also be able to support command completion, if the tty
session has VEOL set to <TAB>.

Right now the tty mode handling on the client is a mess, it will need to be
rationalized somehow to work cleanly with older raw-mode-only servers along
with the linemode servers.

Feedback and help would be greatly welcomed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

[Howard Chu]

Howard Chu wrote:
> So far this is only working as expected for dumb programs that don't try to
> manipulate the tty modes. I'm working on some patches to the readline library
> so that it will leave the tty in cooked mode if it detects that EXTPROC is set
> on the tty. So a remote bash shell will defer all input processing to the
> local client. Will also be able to support command completion, if the tty
> session has VEOL set to<TAB>.

Simple patch for bash/readline here

http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/a34500e79021003b#

> Right now the tty mode handling on the client is a mess, it will need to be
> rationalized somehow to work cleanly with older raw-mode-only servers along
> with the linemode servers.
>
> Feedback and help would be greatly welcomed.

If anyone is interested, you can just follow along on this repo:

git://github.com/hyc/OpenSSH-LINEMODE.git

Everything should work exactly as before when connecting to an unpatached
server. With a patched server and patched shell you'll have local editing plus
command history. I'm still working out how to pass-thru the command completion
bits.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Howard Chu]

Howard Chu wrote:
> Howard Chu wrote:
>> So far this is only working as expected for dumb programs that don't try to
>> manipulate the tty modes. I'm working on some patches to the readline library
>> so that it will leave the tty in cooked mode if it detects that EXTPROC is set
>> on the tty. So a remote bash shell will defer all input processing to the
>> local client. Will also be able to support command completion, if the tty
>> session has VEOL set to<TAB>.
>
> Simple patch for bash/readline here
>
> http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/a34500e79021003b#
>
>> Right now the tty mode handling on the client is a mess, it will need to be
>> rationalized somehow to work cleanly with older raw-mode-only servers along
>> with the linemode servers.
>>
>> Feedback and help would be greatly welcomed.
>
> If anyone is interested, you can just follow along on this repo:
>
> git://github.com/hyc/OpenSSH-LINEMODE.git
>
> Everything should work exactly as before when connecting to an unpatached
> server. With a patched server and patched shell you'll have local editing plus
> command history. I'm still working out how to pass-thru the command completion
> bits.
>

Ugh. Except that this only works well for a single client; if you mux another
session in everything breaks. The GNU readline library assumes it's only
working with one display in one process; it doesn't work well trying to mux it
across multiple ttys. Is there a particular reason why the muxing code didn't
just relay the session data from the master to the slave client, rather than
passing file descriptors to the master and having it write directly to the
slave's tty? I guess it saves on memory copies, but it also limits the other
clients.

[Peter Stuge]

Howard Chu wrote:
> the client will use the readline library

How about libedit? I guess readline is not so hot in OpenSSH
upstream.

//Peter

[Alon Bar-Lev]

libnoise is simple and tiny...
Although not all functionality is there... :)

[Alon Bar-Lev]

Sorry, linenoise...

[Howard Chu]

Alon Bar-Lev wrote:
> libnoise is simple and tiny...
> Although not all functionality is there... :)
>
> On Thu, Jun 17, 2010 at 11:10 AM, Peter Stuge<pe...@stuge.se> wrote:
>>
>> Howard Chu wrote:
>>> the client will use the readline library
>>
>> How about libedit? I guess readline is not so hot in OpenSSH
>> upstream.

Thanks for the suggestions, I hadn't seen these alternatives. I only started
with readline since it's inside bash and I wanted to get bash to play along.
linenoise looks promising since it's such a small library. Of course it also
appears that it doesn't support any form of completion yet.

Command completion has turned out to be a bit tricky; I had first thought I
could grab all of the completion possibilities out of band and feed them to
the local readline library, but that's a waste. (After all, there are two
goals here - one is moving more processing to the local client, but the other
is to minimize network traffic.) Instead, I've opted to just forward any
completion characters to the remote side, and let it deal with them if it can.
This works, mostly, but it needs a bit more hacking to make sure it doesn't
mess up and redraw the input line incorrectly.

There's another limitation that may be more annoying - you can't utilize any
of the remote program's saved command history. Kind of raises a question about
whether ssh itself should manage a persistent history, one for each
hostname/destination.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

[Damien Miller]

On Thu, 17 Jun 2010, Peter Stuge wrote:

> Howard Chu wrote:
> > the client will use the readline library
>
> How about libedit? I guess readline is not so hot in OpenSSH
> upstream.

We already use libedit for sftp command editing and completion and we
would be loathe to add a dependency on another library that does something
similar.

-d

[Howard Chu]

Damien Miller wrote:
> On Thu, 17 Jun 2010, Peter Stuge wrote:
>
>> Howard Chu wrote:
>>> the client will use the readline library
>>
>> How about libedit? I guess readline is not so hot in OpenSSH
>> upstream.
>
> We already use libedit for sftp command editing and completion and we
> would be loathe to add a dependency on another library that does something
> similar.

That makes the choice easy then. I'll look into using libedit instead.
This page http://www.cs.utah.edu/~bigler/code/libedit.html implies that
there's some doubt about which is the master source for libedit. Do you know
where to get a current source that will run on Linux?

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

[Peter Stuge]

Howard Chu wrote:
> I'll look into using libedit instead.
> This page http://www.cs.utah.edu/~bigler/code/libedit.html implies that
> there's some doubt about which is the master source for libedit. Do you
> know where to get a current source that will run on Linux?

Gentoo uses http://www.thrysoee.dk/editline/libedit-20090923-3.0.tar.gz

//Peter

[Cristian Ionescu-Idbohrn]

On Thu, 17 Jun 2010, Howard Chu wrote:

> That makes the choice easy then. I'll look into using libedit

> instead. This page http://www.cs.utah.edu/~bigler/code/libedit.html
> implies that there's some doubt about which is the master source for
> libedit. Do you know where to get a current source that will run on
> Linux?

Debian (unstable) uses libedit (2.11-20080614-1) from
http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-5-0/src/lib/libedit/
with dependencies to libbsd and libncurses5.

Cheers,

--
Cristian