RepoMirrors/openssh
1
0
Fork 0
mirror of git://anongit.mindrot.org/openssh.git synced 2024-12-28 04:52:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

- (djm) Remove *.Ylonen files. They are no longer in the OpenBSD tree,

Browse Source 
the info in COPYING.Ylonen has been moved to the start of each
   SSH1-derived file and README.Ylonen is well out of date.
This commit is contained in:
Damien Miller 2000-12-27 19:06:05 +11:00
parent 5adbad22cb
commit 981eeed1be
5 changed files with 5 additions and 639 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
COPYING.Ylonen
View File

@ -1,70 +0,0 @@
This file is part of the ssh software, Copyright (c) 1995 Tatu Ylonen, Finland
COPYING POLICY AND OTHER LEGAL ISSUES
As far as I am concerned, the code I have written for this software
can be used freely for any purpose. Any derived versions of this
software must be clearly marked as such, and if the derived work is
incompatible with the protocol description in the RFC file, it must be
called by a name other than "ssh" or "Secure Shell".
However, I am not implying to give any licenses to any patents or
copyrights held by third parties, and the software includes parts that
are not under my direct control. As far as I know, all included
source code is used in accordance with the relevant license agreements
and can be used freely for any purpose (the GNU license being the most
restrictive); see below for details.
[ RSA is no longer included. ]
[ IDEA is no longer included. ]
[ DES is now external. ]
[ GMP is now external. No more GNU licence. ]
[ Zlib is now external. ]
[ The make-ssh-known-hosts script is no longer included. ]
[ TSS has been removed. ]
[ MD5 is now external. ]
[ RC4 support has been removed (RC4 is used internally for arc4random). ]
[ Blowfish is now external. ]
The 32-bit CRC implementation in crc32.c is due to Gary S. Brown.
Comments in the file indicate it may be used for any purpose without
restrictions.
The 32-bit CRC compensation attack detector in deattack.c was
contributed by CORE SDI S.A. under a BSD-style license. See
http://www.core-sdi.com/english/ssh/ for details.
Note that any information and cryptographic algorithms used in this
software are publicly available on the Internet and at any major
bookstore, scientific library, and patent office worldwide. More
information can be found e.g. at "http://www.cs.hut.fi/crypto".
The legal status of this program is some combination of all these
permissions and restrictions. Use only at your own responsibility.
You will be responsible for any legal consequences yourself; I am not
making any claims whether possessing or using this is legal or not in
your country, and I am not taking any responsibility on your behalf.
NO WARRANTY
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

3
ChangeLog
View File

@ -7,6 +7,9 @@
- (bal) Fixed NeXT's lack of CPPFLAGS honoring.
- (bal) ssh-keyscan.c: NeXT (and older BSDs) don't support getrlimit() w/
'RLIMIT_NOFILE'
- (djm) Remove *.Ylonen files. They are no longer in the OpenBSD tree,
the info in COPYING.Ylonen has been moved to the start of each
SSH1-derived file and README.Ylonen is well out of date.
20001223
- (bal) Fixed Makefile.in to support recompile of all ssh and sshd objects

567
README.Ylonen
View File

@ -1,567 +0,0 @@
[ Please note that this file has not been updated for OpenSSH and
covers the ssh-1.2.12 release from Dec 1995 only. ]
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. It is inteded as a
replacement for rlogin, rsh, rcp, and rdist.
See the file INSTALL for installation instructions. See COPYING for
license terms and other legal issues. See RFC for a description of
the protocol. There is a WWW page for ssh; see http://www.cs.hut.fi/ssh.
This file has been updated to match ssh-1.2.12.
FEATURES
o Strong authentication. Closes several security holes (e.g., IP,
routing, and DNS spoofing). New authentication methods: .rhosts
together with RSA based host authentication, and pure RSA
authentication.
o Improved privacy. All communications are automatically and
transparently encrypted. RSA is used for key exchange, and a
conventional cipher (normally IDEA, DES, or triple-DES) for
encrypting the session. Encryption is started before
authentication, and no passwords or other information is
transmitted in the clear. Encryption is also used to protect
against spoofed packets.
o Secure X11 sessions. The program automatically sets DISPLAY on
the server machine, and forwards any X11 connections over the
secure channel. Fake Xauthority information is automatically
generated and forwarded to the remote machine; the local client
automatically examines incoming X11 connections and replaces the
fake authorization data with the real data (never telling the
remote machine the real information).
o Arbitrary TCP/IP ports can be redirected through the encrypted channel
in both directions (e.g., for e-cash transactions).
o No retraining needed for normal users; everything happens
automatically, and old .rhosts files will work with strong
authentication if administration installs host key files.
o Never trusts the network. Minimal trust on the remote side of
the connection. Minimal trust on domain name servers. Pure RSA
authentication never trusts anything but the private key.
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 Host authentication key distribution can be centrally by the
administration, automatically when the first connection is made
to a machine (the key obtained on the first connection will be
recorded and used for authentication in the future), or manually
by each user for his/her own use. The central and per-user host
key repositories are both used and complement each other. Host
keys can be generated centrally or automatically when the software
is installed. Host authentication keys are typically 1024 bits.
o Any user can create any number of user authentication RSA keys for
his/her own use. Each user has a file which lists the RSA public
keys for which proof of possession of the corresponding private
key is accepted as authentication. User authentication keys are
typically 1024 bits.
o The server program has its own server RSA key which is
automatically regenerated every hour. This key is never saved in
any file. Exchanged session keys are encrypted using both the
server key and the server host key. The purpose of the separate
server key is to make it impossible to decipher a captured session by
breaking into the server machine at a later time; one hour from
the connection even the server machine cannot decipher the session
key. The key regeneration interval is configurable. The server
key is normally 768 bits.
o An authentication agent, running in the user's laptop or local
workstation, can be used to hold the user's RSA authentication
keys. Ssh automatically forwards the connection to the
authentication agent over any connections, and there is no need to
store the RSA authentication keys on any machine in the network
(except the user's own local machine). The authentication
protocols never reveal the keys; they can only be used to verify
that the user's agent has a certain key. Eventually the agent
could rely on a smart card to perform all authentication
computations.
o The software can be installed and used (with restricted
functionality) even without root privileges.
o The client is customizable in system-wide and per-user
configuration files. Most aspects of the client's operation can
be configured. Different options can be specified on a per-host basis.
o Automatically executes conventional rsh (after displaying a
warning) if the server machine is not running sshd.
o Optional compression of all data with gzip (including forwarded X11
and TCP/IP port data), which may result in significant speedups on
slow connections.
o Complete replacement for rlogin, rsh, and rcp.
WHY TO USE SECURE SHELL
Currently, almost all communications in computer networks are done
without encryption. As a consequence, anyone who has access to any
machine connected to the network can listen in on any communication.
This is being done by hackers, curious administrators, employers,
criminals, industrial spies, and governments. Some networks leak off
enough electromagnetic radiation that data may be captured even from a
distance.
When you log in, your password goes in the network in plain
text. Thus, any listener can then use your account to do any evil he
likes. Many incidents have been encountered worldwide where crackers
have started programs on workstations without the owners knowledge
just to listen to the network and collect passwords. Programs for
doing this are available on the Internet, or can be built by a
competent programmer in a few hours.
Any information that you type or is printed on your screen can be
monitored, recorded, and analyzed. For example, an intruder who has
penetrated a host connected to a major network can start a program
that listens to all data flowing in the network, and whenever it
encounters a 16-digit string, it checks if it is a valid credit card
number (using the check digit), and saves the number plus any
surrounding text (to catch expiration date and holder) in a file.
When the intruder has collected a few thousand credit card numbers, he
makes smallish mail-order purchases from a few thousand stores around
the world, and disappears when the goods arrive but before anyone
suspects anything.
Businesses have trade secrets, patent applications in preparation,
pricing information, subcontractor information, client data, personnel
data, financial information, etc. Currently, anyone with access to
the network (any machine on the network) can listen to anything that
goes in the network, without any regard to normal access restrictions.
Many companies are not aware that information can so easily be
recovered from the network. They trust that their data is safe
since nobody is supposed to know that there is sensitive information
in the network, or because so much other data is transferred in the
network. This is not a safe policy.
Individual persons also have confidential information, such as
diaries, love letters, health care documents, information about their
personal interests and habits, professional data, job applications,
tax reports, political documents, unpublished manuscripts, etc.
One should also be aware that economical intelligence and industrial
espionage has recently become a major priority of the intelligence
agencies of major governments. President Clinton recently assigned
economical espionage as the primary task of the CIA, and the French
have repeatedly been publicly boasting about their achievements on
this field.
There is also another frightening aspect about the poor security of
communications. Computer storage and analysis capability has
increased so much that it is feasible for governments, major
companies, and criminal organizations to automatically analyze,
identify, classify, and file information about millions of people over
the years. Because most of the work can be automated, the cost of
collecting this information is getting very low.
Government agencies may be able to monitor major communication
systems, telephones, fax, computer networks, etc., and passively
collect huge amounts of information about all people with any
significant position in the society. Most of this information is not
sensitive, and many people would say there is no harm in someone
getting that information. However, the information starts to get
sensitive when someone has enough of it. You may not mind someone
knowing what you bought from the shop one random day, but you might
not like someone knowing every small thing you have bought in the last
ten years.
If the government some day starts to move into a more totalitarian
direction (one should remember that Nazi Germany was created by
democratic elections), there is considerable danger of an ultimate
totalitarian state. With enough information (the automatically
collected records of an individual can be manually analyzed when the
person becomes interesting), one can form a very detailed picture of
the individual's interests, opinions, beliefs, habits, friends,
lovers, weaknesses, etc. This information can be used to 1) locate
any persons who might oppose the new system 2) use deception to
disturb any organizations which might rise against the government 3)
eliminate difficult individuals without anyone understanding what
happened. Additionally, if the government can monitor communications
too effectively, it becomes too easy to locate and eliminate any
persons distributing information contrary to the official truth.
Fighting crime and terrorism are often used as grounds for domestic
surveillance and restricting encryption. These are good goals, but
there is considerable danger that the surveillance data starts to get
used for questionable purposes. I find that it is better to tolerate
a small amount of crime in the society than to let the society become
fully controlled. I am in favor of a fairly strong state, but the
state must never get so strong that people become unable to spread
contra-offical information and unable to overturn the government if it
is bad. The danger is that when you notice that the government is
too powerful, it is too late. Also, the real power may not be where
the official government is.
For these reasons (privacy, protecting trade secrets, and making it
more difficult to create a totalitarian state), I think that strong
cryptography should be integrated to the tools we use every day.
Using it causes no harm (except for those who wish to monitor
everything), but not using it can cause huge problems. If the society
changes in undesirable ways, then it will be to late to start
encrypting.
Encryption has had a "military" or "classified" flavor to it. There
are no longer any grounds for this. The military can and will use its
own encryption; that is no excuse to prevent the civilians from
protecting their privacy and secrets. Information on strong
encryption is available in every major bookstore, scientific library,
and patent office around the world, and strong encryption software is
available in every country on the Internet.
Some people would like to make it illegal to use encryption, or to
force people to use encryption that governments can break. This
approach offers no protection if the government turns bad. Also, the
"bad guys" will be using true strong encryption anyway. Good
encryption techniques are too widely known to make them disappear.
Thus, any "key escrow encryption" or other restrictions will only help
monitor ordinary people and petty criminals. It does not help against
powerful criminals, terrorists, or espionage, because they will know
how to use strong encryption anyway. (One source for internationally
available encryption software is http://www.cs.hut.fi/crypto.)
OVERVIEW OF SECURE SHELL
The software consists of a number of programs.
sshd Server program run on the server machine. This
listens for connections from client machines, and
whenever it receives a connection, it performs
authentication and starts serving the client.
ssh This is the client program used to log into another
machine or to execute commands on the other machine.
"slogin" is another name for this program.
scp Securely copies files from one machine to another.
ssh-keygen Used to create RSA keys (host keys and user
authentication keys).
ssh-agent Authentication agent. This can be used to hold RSA
keys for authentication.
ssh-add Used to register new keys with the agent.
make-ssh-known-hosts
Used to create the /etc/ssh_known_hosts file.
Ssh is the program users normally use. It is started as
ssh host
or
ssh host command
The first form opens a new shell on the remote machine (after
authentication). The latter form executes the command on the remote
machine.
When started, the ssh connects sshd on the server machine, verifies
that the server machine really is the machine it wanted to connect,
exchanges encryption keys (in a manner which prevents an outside
listener from getting the keys), performs authentication using .rhosts
and /etc/hosts.equiv, RSA authentication, or conventional password
based authentication. The server then (normally) allocates a
pseudo-terminal and starts an interactive shell or user program.
The TERM environment variable (describing the type of the user's
terminal) is passed from the client side to the remote side. Also,
terminal modes will be copied from the client side to the remote side
to preserve user preferences (e.g., the erase character).
If the DISPLAY variable is set on the client side, the server will
create a dummy X server and set DISPLAY accordingly. Any connections
to the dummy X server will be forwarded through the secure channel,
and will be made to the real X server from the client side. An
arbitrary number of X programs can be started during the session, and
starting them does not require anything special from the user. (Note
that the user must not manually set DISPLAY, because then it would
connect directly to the real display instead of going through the
encrypted channel). This behavior can be disabled in the
configuration file or by giving the -x option to the client.
Arbitrary IP ports can be forwarded over the secure channel. The
program then creates a port on one side, and whenever a connection is
opened to this port, it will be passed over the secure channel, and a
connection will be made from the other side to a specified host:port
pair. Arbitrary IP forwarding must always be explicitly requested,
and cannot be used to forward privileged ports (unless the user is
root). It is possible to specify automatic forwards in a per-user
configuration file, for example to make electronic cash systems work
securely.
If there is an authentication agent on the client side, connection to
it will be automatically forwarded to the server side.
For more infomation, see the manual pages ssh(1), sshd(8), scp(1),
ssh-keygen(1), ssh-agent(1), ssh-add(1), and make-ssh-known-hosts(1)
included in this distribution.
X11 CONNECTION FORWARDING
X11 forwarding serves two purposes: it is a convenience to the user
because there is no need to set the DISPLAY variable, and it provides
encrypted X11 connections. I cannot think of any other easy way to
make X11 connections encrypted; modifying the X server, clients or
libraries would require special work for each machine, vendor and
application. Widely used IP-level encryption does not seem likely for
several years. Thus what we have left is faking an X server on the
same machine where the clients are run, and forwarding the connections
to a real X server over the secure channel.
X11 forwarding works as follows. The client extracts Xauthority
information for the server. It then creates random authorization
data, and sends the random data to the server. The server allocates
an X11 display number, and stores the (fake) Xauthority data for this
display. Whenever an X11 connection is opened, the server forwards
the connection over the secure channel to the client, and the client
parses the first packet of the X11 protocol, substitutes real
authentication data for the fake data (if the fake data matched), and
forwards the connection to the real X server.
If the display does not have Xauthority data, the server will create a
unix domain socket in /tmp/.X11-unix, and use the unix domain socket
as the display. No authentication information is forwarded in this
case. X11 connections are again forwarded over the secure channel.
To the X server the connections appear to come from the client
machine, and the server must have connections allowed from the local
machine. Using authentication data is always recommended because not
using it makes the display insecure. If XDM is used, it automatically
generates the authentication data.
One should be careful not to use "xin" or "xstart" or other similar
scripts that explicitly set DISPLAY to start X sessions in a remote
machine, because the connection will then not go over the secure
channel. The recommended way to start a shell in a remote machine is
xterm -e ssh host &
and the recommended way to execute an X11 application in a remote
machine is
ssh -n host emacs &
If you need to type a password/passphrase for the remote machine,
ssh -f host emacs
may be useful.
RSA AUTHENTICATION
RSA authentication is based on public key cryptograpy. The idea is
that there are two encryption keys, one for encryption and another for
decryption. It is not possible (on human timescale) to derive the
decryption key from the encryption key. The encryption key is called
the public key, because it can be given to anyone and it is not
secret. The decryption key, on the other hand, is secret, and is
called the private key.
RSA authentication is based on the impossibility of deriving the
private key from the public key. The public key is stored on the
server machine in the user's $HOME/.ssh/authorized_keys file. The
private key is only kept on the user's local machine, laptop, or other
secure storage. Then the user tries to log in, the client tells the
server the public key that the user wishes to use for authentication.
The server then checks if this public key is admissible. If so, it
generates a 256 bit random number, encrypts it with the public key,
and sends the value to the client. The client then decrypts the
number with its private key, computes a 128 bit MD5 checksum from the
resulting data, and sends the checksum back to the server. (Only a
checksum is sent to prevent chosen-plaintext attacks against RSA.)
The server checks computes a checksum from the correct data,
and compares the checksums. Authentication is accepted if the
checksums match. (Theoretically this indicates that the client
only probably knows the correct key, but for all practical purposes
there is no doubt.)
The RSA private key can be protected with a passphrase. The
passphrase can be any string; it is hashed with MD5 to produce an
encryption key for IDEA, which is used to encrypt the private part of
the key file. With passphrase, authorization requires access to the key
file and the passphrase. Without passphrase, authorization only
depends on possession of the key file.
RSA authentication is the most secure form of authentication supported
by this software. It does not rely on the network, routers, domain
name servers, or the client machine. The only thing that matters is
access to the private key.
All this, of course, depends on the security of the RSA algorithm
itself. RSA has been widely known since about 1978, and no effective
methods for breaking it are known if it is used properly. Care has
been taken to avoid the well-known pitfalls. Breaking RSA is widely
believed to be equivalent to factoring, which is a very hard
mathematical problem that has received considerable public research.
So far, no effective methods are known for numbers bigger than about
512 bits. However, as computer speeds and factoring methods are
increasing, 512 bits can no longer be considered secure. The
factoring work is exponential, and 768 or 1024 bits are widely
considered to be secure in the near future.
RHOSTS AUTHENTICATION
Conventional .rhosts and hosts.equiv based authentication mechanisms
are fundamentally insecure due to IP, DNS (domain name server) and
routing spoofing attacks. Additionally this authentication method
relies on the integrity of the client machine. These weaknesses is
tolerable, and been known and exploited for a long time.
Ssh provides an improved version of these types of authentication,
because they are very convenient for the user (and allow easy
transition from rsh and rlogin). It permits these types of
authentication, but additionally requires that the client host be
authenticated using RSA.
The server has a list of host keys stored in /etc/ssh_known_host, and
additionally each user has host keys in $HOME/.ssh/known_hosts. Ssh
uses the name servers to obtain the canonical name of the client host,
looks for its public key in its known host files, and requires the
client to prove that it knows the private host key. This prevents IP
and routing spoofing attacks (as long as the client machine private
host key has not been compromized), but is still vulnerable to DNS
attacks (to a limited extent), and relies on the integrity of the
client machine as to who is requesting to log in. This prevents
outsiders from attacking, but does not protect against very powerful
attackers. If maximal security is desired, only RSA authentication
should be used.
It is possible to enable conventional .rhosts and /etc/hosts.equiv
authentication (without host authentication) at compile time by giving
the option --with-rhosts to configure. However, this is not
recommended, and is not done by default.
These weaknesses are present in rsh and rlogin. No improvement in
security will be obtained unless rlogin and rsh are completely
disabled (commented out in /etc/inetd.conf). This is highly
recommended.
WEAKEST LINKS IN SECURITY
One should understand that while this software may provide
cryptographically secure communications, it may be easy to
monitor the communications at their endpoints.
Basically, anyone with root access on the local machine on which you
are running the software may be able to do anything. Anyone with root
access on the server machine may be able to monitor your
communications, and a very talented root user might even be able to
send his/her own requests to your authentication agent.
One should also be aware that computers send out electromagnetic
radition that can sometimes be picked up hundreds of meters away.
Your keyboard is particularly easy to listen to. The image on your
monitor might also be seen on another monitor in a van parked behind
your house.
Beware that unwanted visitors might come to your home or office and
use your machine while you are away. They might also make
modifications or install bugs in your hardware or software.
Beware that the most effective way for someone to decrypt your data
may be with a rubber hose.
LEGAL ISSUES
As far as I am concerned, anyone is permitted to use this software
freely. However, see the file COPYING for detailed copying,
licensing, and distribution information.
In some countries, particularly France, Russia, Iraq, and Pakistan,
it may be illegal to use any encryption at all without a special
permit, and the rumor has it that you cannot get a permit for any
strong encryption.
This software may be freely imported into the United States; however,
the United States Government may consider re-exporting it a criminal
offence.
Note that any information and cryptographic algorithms used in this
software are publicly available on the Internet and at any major
bookstore, scientific library, or patent office worldwide.
THERE IS NO WARRANTY FOR THIS PROGRAM. Please consult the file
COPYING for more information.
MAILING LISTS AND OTHER INFORMATION
There is a mailing list for ossh. It is ossh@sics.se. If you would
like to join, send a message to majordomo@sics.se with "subscribe
ssh" in body.
The WWW home page for ssh is http://www.cs.hut.fi/ssh. It contains an
archive of the mailing list, and detailed information about new
releases, mailing lists, and other relevant issues.
Bug reports should be sent to ossh-bugs@sics.se.
ABOUT THE AUTHOR
This software was written by Tatu Ylonen <ylo@cs.hut.fi>. I work as a
researcher at Helsinki University of Technology, Finland. For more
information, see http://www.cs.hut.fi/~ylo/. My PGP public key is
available via finger from ylo@cs.hut.fi and from the key servers. I
prefer PGP encrypted mail.
The author can be contacted via ordinary mail at
Tatu Ylonen
Helsinki University of Technology
Otakaari 1
FIN-02150 ESPOO
Finland
Fax. +358-0-4513293
ACKNOWLEDGEMENTS
I thank Tero Kivinen, Timo Rinne, Janne Snabb, and Heikki Suonsivu for
their help and comments in the design, implementation and porting of
this software. I also thank numerous contributors, including but not
limited to Walker Aumann, Jurgen Botz, Hans-Werner Braun, Stephane
Bortzmeyer, Adrian Colley, Michael Cooper, David Dombek, Jerome
Etienne, Bill Fithen, Mark Fullmer, Bert Gijsbers, Andreas Gustafsson,
Michael Henits, Steve Johnson, Thomas Koenig, Felix Leitner, Gunnar
Lindberg, Andrew Macpherson, Marc Martinec, Paul Mauvais, Donald
McKillican, Leon Mlakar, Robert Muchsel, Mark Treacy, Bryan
O'Sullivan, Mikael Suokas, Ollivier Robert, Jakob Schlyter, Tomasz
Surmacz, Alvar Vinacua, Petri Virkkula, Michael Warfield, and
Cristophe Wolfhugel.
Thanks also go to Philip Zimmermann, whose PGP software and the
associated legal battle provided inspiration, motivation, and many
useful techniques, and to Bruce Schneier whose book Applied
Cryptography has done a great service in widely distributing knowledge
about cryptographic methods.
Copyright (c) 1995 Tatu Ylonen, Espoo, Finland.

2
contrib/redhat/openssh.spec
View File

@ -205,7 +205,7 @@ fi
%files
%defattr(-,root,root)
%doc ChangeLog OVERVIEW COPYING.Ylonen README* INSTALL
%doc ChangeLog OVERVIEW README* INSTALL
%doc CREDITS LICENCE
%attr(0755,root,root) %{_bindir}/ssh-keygen
%attr(0755,root,root) %{_bindir}/scp

2
contrib/suse/openssh.spec
View File

@ -161,7 +161,7 @@ fi
%files
%defattr(-,root,root)
%doc COPYING.Ylonen ChangeLog OVERVIEW README*
%doc ChangeLog OVERVIEW README*
%doc RFC.nroff TODO CREDITS LICENSE
%attr(0755,root,root) %dir /etc/ssh
%attr(0644,root,root) %config /etc/ssh/ssh_config