lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4C1207B9.10305@symas.com>
Date:	Fri, 11 Jun 2010 02:54:01 -0700
From:	Howard Chu <hyc@...as.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: EXTPROC, telnetd LINEMODE, revisited

It's been over 10 years since I looked at this last

http://lkml.indiana.edu/hypermail/linux/kernel/9911.3/0650.html

and apparently no one else has been interested since then. A random 
conversation got me looking into it again, and now I have it working. However, 
obviously the world has moved on from telnet to ssh, and my goal in posting 
now is to hash out what needs to be done in the kernel so that LINEMODE can be 
fully supported in ssh.

First you'll note that this patch is fairly similar to the one I posted back 
in 1999. The bug I was chasing down back then turned out to be in the telnetd 
source, not in the tty driver, so this patch has only needed minor refreshing 
to bring it up to date.

There are some other issues that need to be addressed though to make this 
feature maximally useful today:

GNU readline and other similar code is prevalent today, and uses many 
additional editing characters that aren't represented in termios. The telnet 
Linemode spec in RFC 1184 accomodates most of these characters but without 
termios support there's no way to communicate these settings between telnetd 
and the readline library (or whatever other app). Most of the editing features 
provided by readline really belong on the local client anyway.

Linemode assumes single-character codes for input functions, but on common 
terminals (e.g. ANSI/VT100 style) a lot of navigation keys send 
multi-character sequences (cursor movement, etc.).

So I'm looking for suggestions on ways to approach this, that will allow as 
much functionality as possible to be handled by a local client.

Despite the fact that most people today have ready access to high speed 
broadband networking today, I think the motivation for local character 
processing is as great now as it was 10 years ago. I regularly use an ssh 
client on an Android phone to keep tabs on my servers when I'm away from my 
home base, and sometimes cellphone connectivity can be extremely lossy, 
networks can be heavily congested, etc... Waiting for character-at-a-time 
packet turnarounds in these conditions can be pretty aggravating. Also, if 
you're unfortunate enough to need to get access to a machine while you're 
roaming away from your home network, the per-byte roaming fees can be murder. 
Both of these pain points can be minimized by using local character processing 
and only sending complete lines to the remote server.

The telnet Linemode spec serves as a pretty good starting point for adapting 
to ssh, but these details still need to be addressed - can/should we add 
additional command characters to the tty driver? The telnet spec defines these 
commands that the tty driver is missing:
   Move cursor one character left, right
   Move cursor one word left, right
   Move cursor to beginning/end of line
   Enter insert/overstrike mode
   Erase character to the right
   Erase word to the right
   Erase to beginning/end of line

Also it would be nice to be able to define other forwarding characters, which 
don't necessarily have an edit function. E.g., <TAB> for word completion.

Another feature with readline is a command history buffer that can be reviewed 
using Cursor Up/Down. Can/should we define this in the tty driver too? Or 
perhaps rely on the client to implement its own command buffer, and never 
mention this aspect on the wire protocol. Again, given the purpose, it makes 
most sense to me to keep this feature on the client side. But some 
coordination with the server would still be useful. E.g., different programs 
can maintain their own persistent command history files. It might be nice to 
have a way for the app to signal to the client which command context to use 
for the current history buffer, and keep them all separate. (Or not, I can see 
other times where you'd just rather have it all as one stack.)

PS: if anyone knows where to send the patches for telnetd, please email me. 
Looks like the upstream source hasn't been touched since 2000.

ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/

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

View attachment "linemode.txt" of type "text/plain" (4518 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ