Re: SecSH Server functionality on Windows - incomplete

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

>From advice given in a reply to the original post and subsequent testing I have found one implementation that does not have these limitations:

    vshell 1.2 from www.vandyke.com


 --- Peter M Boyd

wrote: > Date: Tue, 27 Nov 2001 16:03:04 +0000 (GMT) > From: Peter M Boyd > Subject: SecSH Server functionality on Windows - > incomplete > To: ietf-ssh%netbsd.org@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 >

---

Do You Yahoo!?
Get personalised at My Yahoo!.