OpenSSH/scp ->> F-Secure SSH server Problems

[Greg A. Woods]

[ On Wednesday, March 14, 2001 at 18:41:39 (-0600), mouring at localhost[eviladmin.org] wrote: ]
> Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems
>
> On Wed, 14 Mar 2001, Greg A. Woods wrote:
> 
> [..]
> > > Or are you suggesting that if OpenBSD connects to Solaris that I should
> > > run a different sftp-server then if Linux connects to Solaris? 
> > 
> > IMNSHO that should be up to the client, but restricted by the server
> > administrator.
> > 
> 
> IMNSHO it's up to the administrator and not the connecting client.

Ben, that's almost exactly what I said, but only from the opposite
perspective!  The current subsystem naming scheme does *NOT* allow the
administrator to control what service is expected under which name!  The
administrator *MUST* adhere to either a given implementation, or if a
central naming authority is defined, then to that authority, or else
face inter-operability problems!

> By the fact no one is requiring you to register your program name with
> an IANA type group you can still have pure chaos.

Exactly!  That's why the "built-in subsystem" feature is a wart!
There's no way to enforce implementations to honour the registered
names!

Without the "built-in subsystem" feature the expectations set by the
design are completely different and already well understood and handled
by not only SSH-v1 implementations, but indeed by most other generic
remote transport protocols (well, except maybe SSL which has an alarming
number of TCP port numbers assigned to it -- one for every SSL-wrapped
service).

>  I write a program call
> 'Foo' that uses SSH to call 'Bar'.  You write a program call 'Bar' and
> install it and it happens to fall before my program in the path.  Thus,
> chaos.

Fortunately most everyone's been dealing with this single level of
naming and its consequences for decades now and we have the solutions
down pat.

Adding unnecessary forced generic naming indirection is rarely a good
thing.  It's nice to have in personal environments (eg. shell aliases
and such, but just ask anyone who uses your shell prompt how much
difficulty they have when faced with someone else's aliases, or vice
versa).  A naming indirection scheme is necessary when the underlying
topology is inflexible (eg. IP addresses -- if you move around the
topology you need a new number, so having a constant name is of extreme
benefit).

However in scenarios where the client's expectations of what services
are available are set by its understanding of the host it's about to
connect to, the *lack* of a generic force protocol-level naming
indirection scheme allows the administrator of that host to choose the
name-space entirely, and allows the clients to adjust their use of
command or application names on the server to suite that particular
server.  (Eg. "ssh remhost dir" for M$/DOS, or "ssh remhost ls" for
POSIX.)  A naming system indirection scheme at this level only adds the
need for totally unnecessary *global* co-ordination and co-operation.

Yes of course names can be defined in the form "service at domain.name", as
Bill Sommerfeld said in his response to this thread, however that
doesn't ease the problem any at all and still requires a global registry
for unqualified names.  All it does is provide an outlet for those who
want to define their own naming scheme -- they won't have to pressure
implementors into providing non-standard names, but as we've seen in
other very similar situations the implementors will still bend the rules
for even the slightest reason.

Just look at the mess that appears on any given segment of the public
Internet w.r.t. TCP and UDP port numbers.  Sure there are lots and lots
of people using the registered names for the protocols they are defined
to represent.  However there are a very large and very significant
number of people using illegal port numbers (most Unix systems come with
at least one or two by default!).  You cannot sit in the middle of the
Internet and pick off random packets from the "wire" and be guaranteed
that the port number specified in the header will have any relation at
all to the contents of the data within the defined mappings by IANA.
Indirection in this case was not necessarily a good idea, and it has not
been anywhere near 100% successful!  The only problem in this case was
many people have a harder time using numbers to identify things and so a
common naming scheme was devised to make things easier to remember and
to refer to.  Fortunately with command and application names that might
be invoked by remote SSH clients, there's no need for another naming
scheme because they already have memorable names.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>      <robohack!woods>
Planix, Inc. <woods at planix.com>; Secrets of the Weird <woods at weird.com>