SecSH Server functionality on Windows - incomplete

[Peter M Boyd <peter_m_boyd%yahoo.co.uk@localhost>]

As I understand it:


The goal of the Secure Shell working group is to
update and standardize the popular SSH protocol.

The working group will attempt to assure that the SSH
protocol

o provides strong security against cryptanalysis and
protocol attacks, 

o can work reasonably well without a global key
management or certificate infrastructure, 

o can utilize existing certificate infrastructures
(e.g., DNSSEC, SPKI, X.509) when available, 

o can be made easy to deploy and take into use, 

o requires minimum or no manual interaction from
users, 

o is reasonably clean and simple to implement. 

The resulting protocol will operate over TCP/IP or
other reliable but insecure transport. It is intended
to be implemented at the application level. 


And yet as implemented in many, if not all, versions
on Windows, SecSH cannot support the full Windows
Shell capabilities.

Examples:

when using CMD.EXE as the Shell on Windows Servers,
the simple text editor EDLIN cannot be used via SecSH
to support its natural functionality that works in a
local DOS Window

browsing a file using 'pipe' into the 'more' function
doesn't work via SecSH yet it does, of course, work
locally

CTRL&C does not interrupt a long running function via
SecSH, which does work locally


Have Windows implementors not understood what SecSH
was intended to support?


It seems to me that SecSH is good to *N*X Servers, is
good as a tunnel between a Client program and a Server
program, e.g. used with VNC

    but not good to a Shell in Windows

---- even if a *N*X Shell is used in Windows instead
of CMD.EXE, the ablove deficiencies still apply


Is this of any concern to the IETF?

regards

Peter M Boyd 
  

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music Charts
http://uk.my.yahoo.com