Subject: Extensions to SSH in order to facilitate telnet replacement.

From: "Phillip Remaker" <[email-masked]>
Date: Fri, 1 Mar 2002 12:25:45 -0800

In the process of trying to eliminate telnet from customer networks, I have
encountered  two hurdles, one major and one minor.

A number of customers continue  to use telnet and terminal servers to
provide legacy RS-232 port access to devices such  Sun servers, Cisco
routers and modems.  Telnet provides two useful functions through the IAC
mechanism:

1) Presentation of an out of band BREAK signal (IAC 243)  as in RFC854 [This
is important]
2) Manipulation of RS-232 parameters (speed, parity, flowcontrol state) by
IAC commands (RFC2217) [Less important]

It seems like SSH would be well suited to handle these using the well
designed negotiation mechanisms within the protocol, and I was wondering if
anybody has already tackled this problem.  If not, I welcome suggestions
about the most elegant way to handle it within the spirit of the SSH
protocol.

---

From: Simon Tatham <[email-masked]>
Date: Sat, 02 Mar 2002 09:07:33 +0000

> about the most elegant way to handle it within the spirit of the SSH

SSH_MSG_CHANNEL_REQUEST seems like an ideal mechanism for these.
Just define a channel request type ("[email-masked]" or
similar), and enhance your SSH2 server to accept it on a
shell-session channel and do the right thing. Then all you need to
do is convince client implementors to add support for it. Note that
you don't need to affect the standardisation process to do this at
all - you could propose your extension as an RFC so you'd have
something to refer people to, but that needn't be a prerequisite for
getting it implemented.

Cheers,
Simon
-- 
Simon Tatham         "The difference between theory and practice is
<[email-masked]>    that, in theory, there is no difference."

---

From: Barney Wolff <[email-masked]>
Date: Sat, 2 Mar 2002 13:11:15 -0500

Is there a reason, aside from elegance, that simply forwarding to
localhost (or lo0) port 23 over ssh is unacceptable?  It has the
great advantage that no client enhancement is required.

-- 
Barney Wolff

"Nonetheless, ease and peace had left this people still curiously
tough.  They were, if it came to it, difficult to daunt or to kill;
and they were, perhaps, so unwearyingly fond of good things not
least because they could, when put to it, do without them, and could
survive rough handling by grief, foe, or weather in a way that
astonished those who did not know them well and looked no further
than their bellies and their well-fed faces." J.R.R.T.

---

From: "Joseph Galbraith" <[email-masked]>
Date: Sat, 2 Mar 2002 11:58:07 -0800

Well, it requires running a complicated
server (telnetd) with all it's additional
bugs and security vulnerabilities on your
server, and requires the client to have
another complicated (maybe expensive?)
piece of code on his/her system.

Or, imagine either your server or
client are dedicated devices -- now
a telnet server seems even less
attractive.

- Joseph

---

From: Barney Wolff <[email-masked]>
Date: Sat, 2 Mar 2002 15:09:57 -0500

As opposed to building the telnet complexities into sshd?  And of course
every device for which this functionality would be desired already has
the telnet server built in.  Ditto telnet client, for ssh clients.

Maybe I misunderstood the request, but it seemed clear to me that the
only motivation was to talk to things that expected to be talking via
telnet.

Barney