Re: Serial port redirection

Peter Astrand
2003-12-06T23:31:43Z

> >Actually, we are using telnet+RFC2217 over an SSH TCP tunnel. I think this
> >is a pretty clean solution. How could a "better" solution look like?
> >
> >
> Two better solutions:
>
> * TELNET START_TLS + AUTH {SRP, KRB5} + RFC2217

But the START_TLS and auth stuff has nothing to do with RFC2217. It's just
a matter of using several Telnet options at the same time.

> * SSH + a Remote Serial Port subsystem (yet to be built)

SSH subsystems are nothing magic: The subsystem process communicates with
sshd via stdin/stdout, just like inetd. For example, the "SSH File
Transfer Protocol" RFC says:

Even though this protocol is described in the context of the SSH2
protocol, this protocol is general and independent of the rest of the
SSH2 protocol suite.

So, the question is, telnet+RFC2217 a "bad" or inappropriate protocol to
be used with a SSH subsystem? I think not.

Since sredird is a inetd-type service, it can actually work as a
subsystem. It works, I've just tested it. Here's what I did:

* Created /tmp/sredir-sshsub:

#!/bin/sh
exec /tmp/sredird 5 /dev/ttyS0 /tmp/LCK..ttyS0

* Added to sshd_config:

Subsystem sredir /tmp/sredir-sshsub

* Used ssh and socat to connect:

socat TCP-LISTEN:5555 "EXEC:ssh -s localhost sredir"

* Connected with Kermit:

(/home/peter/) C-Kermit>set host localhost:5555
DNS Lookup... Trying 127.0.0.1... Reverse DNS Lookup... (OK)
localhost.localdomain connected on port 5555
Negotiations.. (OK)

So, I think telnet+RFC2217 is a good protocol, even in a SSH environment.
Thus, it would be useful with an updated spec.

What remains is perhaps convincing IETF of this. Or, maybe not: We could
just go ahead and update the spec.

--
Peter Åstrand www.thinlinc.com
Cendio www.cendio.se
Teknikringen 3 Phone: +46-13-21 46 00
583 30 Linköping

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html