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

[Barney Wolff <barney%databus.com@localhost>]

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.

On Sat, Mar 02, 2002 at 09:07:33AM +0000, Simon Tatham wrote:
> Phillip Remaker <remaker%cisco.com@localhost> wrote:
> > 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.
> 
> SSH_MSG_CHANNEL_REQUEST seems like an ideal mechanism for these.
> Just define a channel request type ("send-break%mydomain.com@localhost" 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.

-- 
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.