ANNOUNCEMENT: Ssh (Secure Shell) remote login program

-----BEGIN PGP SIGNED MESSAGE-----

Looking for a secure rlogin?
Want to deter IP-spoofing, DNS-spoofing, and routing-spoofing?
Want to run X11 connections and TCP/IP ports securely over an insecure network?
Worried about your privacy?
Then read this.


Introducing SSH (Secure Shell) Version 1.0


Ssh (Secure Shell) is a program to log into another computer over a
network, to execute commands in a remote machine, and to move files
from one machine to another.  It provides strong authentication and
secure communications over insecure channels.  Its features include
the following:

   o    Strong authentication.  Closes several security holes (e.g., IP,
	routing, and DNS spoofing and listening for passwords from the
	network).  New authentication methods: .rhosts together with
	RSA based host authentication, and pure RSA authentication.

   o    All communications are automatically and transparently
        encrypted.  Encryption is also used to protect against spoofed
        packets.

   o    X11 connection forwarding provides secure X11 sessions.

   o    Arbitrary TCP/IP ports can be redirected over the encrypted
        channel in both directions.

   o    Client RSA-authenticates the server machine in the beginning of
        every connection to prevent trojan horses (by routing or DNS
        spoofing) and man-in-the-middle attacks, and the server RSA-
        authenticates the client machine before accepting .rhosts or
        /etc/hosts.equiv authentication (to prevent DNS, routing, or IP
        spoofing).

   o    An authentication agent, running in the user's local workstation
        or laptop, can be used to hold the user's RSA authentication
        keys.

   o    Multiple convenience features fix annoying problems with rlogin
        and rsh.

   o    Complete replacement for rlogin, rsh, and rcp.


Ssh is freely available, and may be used by anyone (see the file
COPYING in the distribution for more details).  There is no warranty
of any kind, and patents may restrict your right to use this software
in some countries.

Ssh is currently available for anonymous ftp at the following locations
   ftp.funet.fi:/pub/unix/security/ssh-1.0.0.tar.gz
   ftp.cs.hut.fi:/pub/ssh/ssh-1.0.0.tar.gz

Please let me know if you willing to have your site act as a
distribution site.  (US sites warning: although this software was
developed outside the United States using information available in any
major bookstore or scientific library worldwide, it is illegal to
export anything containing cryptographic software from the United
States.  Putting this openly available for ftp in the US may make you
eligible for charges on ITAR violations, with penalties up to 10 years
in prison.  French and Russian sites warning: it may be illegal to use
or even posses this software in your country, because your government
wants to be able to monitor all conversations of its citizens.)

There is a WWW home page for ssh: http://www.cs.hut.fi/ssh.

There is a mailing list for ssh.  Send mail to ssh-request@clinet.fi
to get instructions (or mail directly to majordomo@clinet.fi with
"subscribe ssh" in body).


All official distributions of ssh are accompanied by a pgp signature
by the key "pub  1024/DCB9AE01 1995/04/24 Ssh distribution key
<ylo@cs.hut.fi>".  (Included below.)

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.i

mQCNAi+btRkAAAEEAKxQ9HwqfsQc9apOIQmFTo2wqbCL6Q1xlvN6CjxkBbtviaLq
EgmVPnb/FGD5wwxDMjCCJDwBFfLLRwASQAyyy5RjukkZx1Gn8qHzmoyIOVTFOIJI
TFDWyVjMSSvUKACDqXv/xVFunsPlPc7d6f4MwxD1kw2BBpoV7k64di/cua4BAAUR
tCRTc2ggZGlzdHJpYnV0aW9uIGtleSA8eWxvQGNzLmh1dC5maT6JAJUCBRAvm7Vv
qRnF8ZYfSjUBAW7pBACQ7G2pYStkBM5aOK2udb/m/YAAZ/NlY2emSgEJfYrAysSY
0yfbhKGt0K59fGSotmSRcMOpq0tgTMm7lQjsUr5ez1Ra/0Dv7e3xoGQYJ8764X9w
popC+u9JuxLeGTtgWYwPUZIHFcQanZslUmCDr36kvesx/2wXBf8+StghMbA3vw==
=aGik
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQCVAgUBMAPhQqkZxfGWH0o1AQHgngP/dbcRUFqJF549VvVOWgDtAxu/UoO6hnei
26/OpczgH6j8+6fZh8TV81yVAh95K6EhHsKo85j5hXTmKSG3xLn6fw26q1DPGHpQ
Sa4xQ4oL20qcvgOeaEi3gZxxTD5etzdl8eBNbe8vSIkk91yrsAiZL7h8St7UHGsA
N5WqXSMI8pg=
=tXr9
-----END PGP SIGNATURE-----

FANTASTIC!!!!
I think we've all been waiting for / building this.
Kudos...

> Looking for a secure rlogin?
> Want to deter IP-spoofing, DNS-spoofing, and routing-spoofing?
> Want to run X11 connections and TCP/IP ports securely over an insecure network?
> Worried about your privacy?
> Then read this.
> 
> 
> Introducing SSH (Secure Shell) Version 1.0
...

Quibbles/suggestions:

ssh, while an obvious name, already collides with a nice shar decoder and
a different kind of secure shell from CFS.

Probably a worthwhile collision though.

Second: 

It would be very helpful if the socket connection could be made (optionally)
through a telnet proxy for firewalls (with optional quoting of problem
characters).  I've actually done this with TERM and a helper program.

I may produce a patch for this.

Third:

Of course support for S/Key and tokens/hand held authenticators would be
useful additions for some situations (although inferior to RSA...).

Forth:

Someone needs to crank out a Windows/Mac client... (Lower priority, but
still useful.)

Fifth:

udprelay etc. could also be borrowed from the term suite.

Sixth:

Integration with TCP/NFS and/or client-server CFS would be fantastic.
(One local CFS server acting as a secure client over tcp to a remote
CFS server.)
Remote encrypted mount of an encrypted partition...

sdw
-- 
Stephen D. Williams 25Feb1965 VW,OH (FBI ID) sdw@lig.net http://www.lig.net/sdw
Consultant, Vienna,VA Mar95- 703-918-1491W 43392 Wayside Cir.,Ashburn, VA 22011
OO/Unix/Comm/NN       ICBM/GPS: 39 02 37N, 77 29 16W home, 38 54 04N, 77 15 56W
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.;28May95

> ssh, while an obvious name, already collides with a nice shar decoder and
> a different kind of secure shell from CFS.

Ssh has already been registered with IANA (Internet Assigned Numbers
Authority) as the name of the service.  I would rather not change it
without a compelling reason.  It is also easy to obtain from rsh by
replacing the r by s (which also makes for scp, sshd, and in future
maybe also sdist).  It is my understanding that CFS is in rather
limited use (especially outside the US), and the ssh shar extractor is
not widely used either (neither can be found from the archie database
at archie.funet.fi).  IETF has a thing called Site Security Handbook
that they abbreviate SSH, but it is probably sufficiently different
not to be confused.

> Of course support for S/Key and tokens/hand held authenticators would be
> useful additions for some situations (although inferior to RSA...).

True.

The agent protocol can currently be used to forward a connection to
any program (which can mean device) that can perform RSA
authentication.  New authentication methods can be compatibly added
later.

S/Key can be used by making skeysh you login shell.  Then you will
first be asked for a normal password (if any), and then for the
one-time password.  I did not want to incorporate skey functionality
directly into the software, because it is not clear to me if the
arrangements in use (file names, formats, algorithms) have stabilized
yet.  Also, there is less need for skey as no passwords are
transmitted in the clear.

> Integration with TCP/NFS and/or client-server CFS would be fantastic.
> (One local CFS server acting as a secure client over tcp to a remote
> CFS server.)
> Remote encrypted mount of an encrypted partition...

Maybe, *maybe*, TCP/IP port forwarding could be used for this?  (I
don't know what CFS does because I have never seen CFS.)

    Tatu

> 
> > ssh, while an obvious name, already collides with a nice shar decoder and
> > a different kind of secure shell from CFS.
> 
> Ssh has already been registered with IANA (Internet Assigned Numbers
> Authority) as the name of the service.  I would rather not change it
> without a compelling reason.  It is also easy to obtain from rsh by
> replacing the r by s (which also makes for scp, sshd, and in future
> maybe also sdist).  It is my understanding that CFS is in rather
> limited use (especially outside the US), and the ssh shar extractor is
> not widely used either (neither can be found from the archie database
> at archie.funet.fi).  IETF has a thing called Site Security Handbook
> that they abbreviate SSH, but it is probably sufficiently different
> not to be confused.

I agree as the collisions aren't too bad (except in my /usr/local/bin...).

> > Of course support for S/Key and tokens/hand held authenticators would be
> > useful additions for some situations (although inferior to RSA...).
> 
> True.
> 
> The agent protocol can currently be used to forward a connection to
> any program (which can mean device) that can perform RSA
> authentication.  New authentication methods can be compatibly added
> later.
> 
> S/Key can be used by making skeysh you login shell.  Then you will
> first be asked for a normal password (if any), and then for the
> one-time password.  I did not want to incorporate skey functionality
> directly into the software, because it is not clear to me if the
> arrangements in use (file names, formats, algorithms) have stabilized
> yet.  Also, there is less need for skey as no passwords are
> transmitted in the clear.
> 
> > Integration with TCP/NFS and/or client-server CFS would be fantastic.
> > (One local CFS server acting as a secure client over tcp to a remote
> > CFS server.)
> > Remote encrypted mount of an encrypted partition...
> 
> Maybe, *maybe*, TCP/IP port forwarding could be used for this?  (I
> don't know what CFS does because I have never seen CFS.)

I was actually contemplating a modification to CFS to support a
tunneled TCP based NFS related operation.

CFS, like other specialized NFS servers, talks to NFS clients like
the normal NFS server, but runs on a different RPC port (so you can
run several types of NFS servers).  CFS encrypts directories that 
can be attached and detached without changing the NFS mount.

It occurred to me that it wouldn't be too tough to have one CFSD
open a TCP/socket connection to another CFSD and pass file access
requests instead of implementing them locally.  The encryption
of the ssh link and the on disk encryption of CFSD should be a 
good combination.

I've been compiling under Linux and have had a number of autoconfiguration
errors.  I'll produce a simple-minded patch shortly.
(Thinks I'm cross-compiling, have some include files I don't, don't
have waitpid/wait3, collision with stdc crypt/random defs, etc.)

>     Tatu

sdw
-- 
Stephen D. Williams 25Feb1965 VW,OH (FBI ID) sdw@lig.net http://www.lig.net/sdw
Consultant, Vienna,VA Mar95- 703-918-1491W 43392 Wayside Cir.,Ashburn, VA 22011
OO/Unix/Comm/NN       ICBM/GPS: 39 02 37N, 77 29 16W home, 38 54 04N, 77 15 56W
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.;28May95

Stephen D. Williams writes:
> It occurred to me that it wouldn't be too tough to have one CFSD
> open a TCP/socket connection to another CFSD and pass file access
> requests instead of implementing them locally.  The encryption
> of the ssh link and the on disk encryption of CFSD should be a 
> good combination.

The whole point of CFS was that you could mount remote devices that
were encrypted and decrypt them locally. CFS acts like a scrim over
existing file systems. If the remote machine has your keys on it
you've reduced security and, seemingly to me, gained very little.

Now, what *would* be really neat would be an implementation of CFS in
kernel under 4.4lite using the stacked vnode architecture. It would
probably be fairly simple to do it, and you wouldn't have any context
switches or the like when cfs'ing...

Perry

> 
> 
> Stephen D. Williams writes:
> > It occurred to me that it wouldn't be too tough to have one CFSD
> > open a TCP/socket connection to another CFSD and pass file access
> > requests instead of implementing them locally.  The encryption
> > of the ssh link and the on disk encryption of CFSD should be a 
> > good combination.
> 
> The whole point of CFS was that you could mount remote devices that
> were encrypted and decrypt them locally. CFS acts like a scrim over
> existing file systems. If the remote machine has your keys on it
> you've reduced security and, seemingly to me, gained very little.
> 
> Now, what *would* be really neat would be an implementation of CFS in
> kernel under 4.4lite using the stacked vnode architecture. It would
> probably be fairly simple to do it, and you wouldn't have any context
> switches or the like when cfs'ing...
> 
> Perry

That's true.  I was thinking in terms of traversing firewalls in a
safe fashion rather than where normal SUN/RPC NFS is available.

For this, using CFS and SSH together seems appropriate.

sdw
-- 
Stephen D. Williams 25Feb1965 VW,OH (FBI ID) sdw@lig.net http://www.lig.net/sdw
Consultant, Vienna,VA Mar95- 703-918-1491W 43392 Wayside Cir.,Ashburn, VA 22011
OO/Unix/Comm/NN       ICBM/GPS: 39 02 37N, 77 29 16W home, 38 54 04N, 77 15 56W
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.;28May95

> I've been compiling under Linux and have had a number of autoconfiguration
> errors.  I'll produce a simple-minded patch shortly.
> (Thinks I'm cross-compiling, have some include files I don't, don't
> have waitpid/wait3, collision with stdc crypt/random defs, etc.)

I last configured and compiled ssh on Linux yesterday and had no
problems.  I have slackware 2.2.0.1, kernel 1.2.8, gcc-2.7.0.

Please include version numbers in your report.

    Tatu