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 intended 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.26 / f-secure ssh 1.3.6.
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, Blowfish, 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.
Furthermore, it is possible to hijack connections going though the
network. This means that an intruder can enter in the middle of an
existing connection, and start modifying data in both directions.
This can, e.g., be used to insert new commands in sessions
authenticated by one-time passwords. A consequence is that no
security method based on purely authenticating the user is safe.
Furthermore, routing spoofing can be used to bring almost any
connection in the Internet to a location where it can be attacked.
Encryption and cryptographic authentication and integrity protection
are required to secure networks and computer systems. SSH uses strong
cryptographic algorithms to achieve these goals.
Ease of use is critical to the acceptance of a piece of software. SSH
attempts to be *easier* to use than its insecure counterparts.
SSH has gained very wide acceptance. It is currently (late 1996)
being used in approximately 50 countries at probably tens of thousands
of organizations. Its users include top universities, research
laboratories, banks, major corporations, and numerous smaller
companies and individuals.
SSH is available for almost all Unix platforms, and commercial
versions are available for Windows (3.1, 95, NT) and Macintosh. For
more information, see http://www.datafellows.com/f-secure.
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 information, 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 cryptography. The idea is
that there are two encryption keys, one for encryption and another for
decryption. It is not possible (on human time scale) 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 3DES, 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 compromised), 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.
LEGAL ISSUES
See the file COPYING for distribution conditions. To summarize, you
can use this software freely for non-commercial purposes. However,
this software cannot be sold or used for directly revenue-generating
purposes without licensing. THERE IS NO WARRANTY FOR THIS PROGRAM.
In some countries, particularly Russia, Iraq, Pakistan, and France, it
may be illegal to use any encryption at all without a special permit.
This software may be freely imported into the United States; however,
the United States Government may consider re-exporting it a criminal
offense. Thus, if you are outside the US, please retrieve this
software from outside the US.
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.
MAILING LISTS AND OTHER INFORMATION
There is a mailing list for ssh. It is ssh@clinet.fi. If you would
like to join, send a message to majordomo@clinet.fi 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.
For information about Windows, Macintosh, and commercial licensing,
see http://www.datafellows.com/f-secure, or mail to
f-secure-ssh-sales@datafellows.com.
Bug reports should be sent to ssh-bugs@cs.hut.fi.
ABOUT THE AUTHOR
This software was originally written by Tatu Ylonen <ylo@cs.hut.fi> in
Finland. It is now being maintained by SSH Communications Security
(http://www.ssh.fi) and Data Fellows (http://www.datafellows.com).
ACKNOWLEDGEMENTS
Many people have contributed to the development of this software.
Martin Abadi, Jason Ackley, Satoshi Adachi, Tim Adam, Kazunori Ando,
Andre April, Walker Aumann, E. Jay Barkenbilt, Steve Bellovin, Steve
Birnbaum, Steve Bonds, Paul Borman, Stephane Bortzmeyer, Jim Bourne,
Jurgen Botz, Hans-Werner Braun, Bill Broadley, Piete Brooks, Loren
Buchanan, Donald Buczek, Joao Castro, Andrey Chernov, Adrian Colley,
Michael Cooper, Brian Cully, Felix von Delius, David Dombek, Ian
Donaldson, Sean Doran, Danek Duvall, Garance Drosehn, Niklas
Edmundsson, Doug Engert, Jerome Etienne, Bill Fithen, Mike Friedman,
Florian Fuchs, Mark Fullmer, Jean-Loup Gailly, Bert Gijsbers, Eivind
Gjelseth, Bob Goellner, Ian Goldberg, Chuck Goodhart, Aaron Gowatch,
Torbjorn Granlund, Teddy Grenman, Klaus Guntermann, Andreas
Gustafsson, Kojima Hajime, Charles M. Hannum, Michael Henits, Ville
Herva, Nick Hibma, Mark Horn, Ton Hospel, Antti Huima, Cedomir Igaly,
Bradford W. Johnson, Steve Johnson, LaMont Jones, Arne Juul, Petri
Kaukasoina, Charles Karney, Richard Kaszeta, Brendan Kehoe, Tero
Kivinen, Philip Kizer, Mika Kojo, Georg-W. Koltermann, David Kågedal,
Thomas König, Joseph Lappa, Felix Leitner, Ofer Licht, Gunnar
Lindberg, Markus Linnala, Harald Lundberg, Glenn Machin, Andrew
Macpherson, Marc Martinec, Paul Mauvais, David Mazieres, Harry
McGavran Jr., Donald McKillican, Pedro Melo, Luke Mewburn, Leon
Mlakar, Robert Muchsel, Kaj Mustikkamäki, Hannu Napari, Pekka
Nikander, Bill O'Neill, Bryan O'Sullivan, John P.Speno, Andy Polyakov,
Matt Power, Theo de Raadt, Andrew Raphael, Matt Richards, Michael
Richardson, Timo Rinne, Ollivier Robert, Maciej W. Rozycki, Dima
Ruban, Tomi Salo, Paul J. Sanchez, Corey Satten, Jakob Schlyter, Wayne
Schroeder, Jay Schuster, Harry Shamansky, Janne Snabb, Harlan Stenn,
Kevin Steves, Mikael Suokas, Heikki Suonsivu, Tomasz Surmacz, Holger
Trapp, Mark Treacy, Andrew Tridgell, Rick Troxel, Dragan Vecerina,
Wietse Venema, Witse Venema, Alvar Vinacua, Russell Vincent, Petri
Virkkula, Michael Warfield, Brian Weaver, Peter Wemm, Raymund Will,
Mike Williams, Christophe Wolfhugel and Craig Yap.
My apologies to people whom I have forgotten to list.
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) 1996,1997,1998 SSH Communications Security, Espoo, Finland.
BLOWFISH ======== Bruce Schneier's block cipher that was designed to be a fast and free alternative to existing encryption algorithms. It is unpatented and license-free. SSH version uses a 128-bit key for Blowfish (the algorithm allows anything from 32 to 448 bits). Performance on a pentium machine is about 88% of "none" encryption. You can disable it by giving the --without-blowfish option to configure. It is ON by default. ARCFOUR ======= Arcfour is a stream cipher that supports variable length keys (SSH uses it with 128 bit keys). Arcfour is compatible with the RC4 cipher (RC4 is a trademark of RSA Data Security). Arcfour is quite fast. There are some problems in the way arcfour is used in SSH 1.x. Because of this, it is disabled by default. Arcfour can be enabled by giving --with-arcfour to configure; however, this will introduce security problems if the attacker can perform active network-level attacks. The problems are fixed in SSH 2.x. Performance on a pentium machine is about 91% of "none" encryption. The SSH client automatically switches to blowfish, if arcfour is requested but not supported. This allows old scripts and config files to work even now that arcfour is disabled by default. A warning is printed when this happens. IDEA ==== A 128-bit block cipher. Faster than 3DES, but slower than Arcfour and Blowfish. The IDEA algorithm is patented in many countries, and the patent holder disallows commercial use (their definition of commercial use include connections from one corporation to another corporation). Performance on a pentium machine is about 64% of "none" encryption. You can disable IDEA by giving the --without-idea option to configure. It is ON by default. DES === A 56-bit block cipher. About three times faster than 3DES, but slower than Arcfour and Blowfish. The 56-bit key length is too small for real security, so you should not enable this unless it is crucial for you to support DES (e.g. due to company policy). Performance on a pentium machine is about 71% of "none" encryption. You can enable DES by giving the --with-des option to configure. It is OFF by default. 3DES ==== Three-key triple-DES (effective key length of about 112 bits) in inner CBC-mode. This is the default fall back cipher that is used if the client asks for a cipher that isn't supported by the server. RSA private key files are encrypted by 3DES by default. (Some older versions encrypted private key files with IDEA, and such key files may still be around.) Performance on a pentium machine is about 45% of "none" encryption. You cannot disable it, because the it is mandatory cipher. NONE ==== No encryption at all. This cipher is intended only for testing, and should not be enabled for normal use. Using no encryption makes SSH vulnerable to network-level attacks (such as connection hijacking). There are also more subtle ways to exploit using no encryption, and servers should not allow such connections at all except when testing the protocol. Using no encryption is used as the reference value for the performance results indicated for other algorithms (and is represented by the value 100%). Note that performance depends also on compression, processor types, network speed, etc. You can allow "none" encryption by giving the --with-none option to configure. Using no encryption is not allowed by default.
============================================================================
CORE SDI S.A.
Buenos Aires, Argentina
<http://www.core-sdi.com>
SSH insertion attack detection
============================================================================
Crc32 Compensation attack detector
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This document describes the scope and characteristics of SSH crc32
compensation attack detector engine. It will inspect an encrypted SSH protocol
1.5 stream for suspicious patterns. If either the server or client is under
attack, the detector closes the conection and logs the attack.
Attack characteristics
~~~~~~~~~~~~~~~~~~~~~~
An attacker, with sniffing and spoofing capabilities on the SSH network stream, may perform an active network attack by constructing a packet using a
known cipher/plaintext pair and computing addditional data to fill the packet
in a way that will produce a valid CRC-32 field and pass as a valid packet when
decryped and integrity checked on the server side.
If the attack succeeds, arbitrary commands will get executed on the server.
This attack doesnt affect the confidential security characteristics of the
products using this protocols. However, integrity and authentication
of packets can no longer be trusted.
Solution
~~~~~~~~
This is not an implementation bug, but a protocol design vulnerability. The
protocol must be updated to use cryptographic strong message authentication
codes. SSH Protocol version 2 as published in [1] includes the use of a real
strong MAC.
However, this will require to update all clients and servers simultaneusly
while disabling compatibility with protocol version 1.5. On many installations
this is not practical.
A mid-term solution exists, that will help protecting the server from the
auth/integrity vulnerabilities. On most scenarios it will be enough to upgrade
only the servers.
This approach is based on the fact that an attacker will need to exploit some
of the linear characteristics of the integrity function in order to implement
the attack. In that context, the constructed packets will follow certain
patterns that could be detected on the encrypted stream.
This is not a general solution, but a countermeasure against a model of all
of the possible attacks that exploits this vulnerabilities.
The provided patch looks for patterns of repeated ciphered blocks in
each SSH packet received, the performance loss in speed is less 2% in an
uncompressed stream compared to an unpatched server. Memory usage increases
in about 8k per conection.
The chances of reporting a false attack in a 32GB file transfer is around
1 in 2**51.
Contact information
~~~~~~~~~~~~~~~~~~~
These vulnerabilities were discovered by Ariel Futoransky
and Emiliano Kargieman.
Comments and questions regarding this vulnerability and the fix
should be sent to:
Ariel Futoransky <futo@core-sdi.com>
Emiliano Kargieman <ek@core-sdi.com>
For more information about CORE SDI S.A. contact <core@core-sdi.com>
or visit <http://www.core-sdi.com>
For more information about this problem and related ones visit:
<http://www.core-sdi.com/ssh>
You can contact CORE SDI S.A. at <corelabs@core-sdi.com> using the
the following PGP key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
Comment: Requires PGP version 2.6 or later.
mQCNAzVgfMgAAAEEAJSfJNdvCwIAc4AK0ckeimubLIwzsRVDRhjPQIOYt/7kxxio
DZybr53fwMEjyT8cHXRL08i0R9rcuFeCNAez6XcalbhqUKXDcLL/cZK80CCDSCs5
tRCZGGOEBnXQIoyvbvi4gNYhBS5wUvmh3b/mvRFTvhmRrUy9m/nO/LnPTgz1AAUR
tCBDT1JFTEFCUyA8Y29yZWxhYnNAY29yZS1zZGkuY29tPokAlQMFEDVgfMn5zvy5
z04M9QEBC6ED/0Szt3f54JTvkZG3ezQ8G60HvAw4/A5Ti6i3oze6jsXxzGp6pA1x
i0jaZpKaUSpo0MLc7BcijMKneuUHnN3XtN5YxtFt0aEoot1MIvv4BsdeUb3x257G
3+vr8SxGk44Vm4tfuN8F/2dNo/00yYP9rd3zQ8Tl+gmr5VxnLViZIDuh
=ulRg
-----END PGP PUBLIC KEY BLOCK-----
Copyright
~~~~~~~~~
This file, deattack.c and deattack.h are copyright (c) 1998
CORE SDI S.A., Buenos Aires, Argentina. All rights reserved.
and should be redistributed or modified for non-commercial purposes only
provided that this copyright notice is retained.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES
ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING
FROM THE USE OR MISUSE OF THIS SOFTWARE.
Support for secure RPC, secure NFS, and NIS_PLUS Andy Polyakov
<appro@fy.chalmers.se>
- Provides support for secure RPC on systems with keyserv version 1-2.
Autoconfigured and tested on Solaris 2.5.1 and HP-UX 10.20 boxes.
It's also possible now to hire keyserv for generating passphrase for
private key encryption/decryption. If you try to encrypt your key
with SUN-DES-1 passphrase, ssh-keygen will substitute it with a
64-bit phrase crypted with your secret RPC key. It's functional
replacement for ssh-agent. Proc and cons:
- you use the only password (your login password) to get things
working;
- it's invariant to login password as secret key is not changed when
login password is changed, just reencrypted with new password;
- if you have your secret key is registered in keyserv, anybody who
runs under your uid can decrypt your private key (well, same as
when you keep it in ssh-agent). so it's important to run keylogout
when you logout or leave and for example lock the screen (i have
modified version of xlock that keylogout at start and keylogin when
unlock the screen with your password:-);
- Provides support for secure NFS, autoconfigured and tested on
Solaris 2.5.1;
- Provides support for NIS+, autoconfigured and tested on Solaris
2.5.1. Support is forced so that you don't have to recompile if you
suddenly choose to move to NIS+;
- Ensures that user shell is listed in /etc/shells on systems that
support getusershell(). The option has to be enabled manually with
#define CHECK_ETC_SHELLS and tested on Solaris 2.5.1 machine;
- Provides support for password aging on systems with /etc/shadow.
Tested on Solaris 2.5.1 and IRIX 5.3 machines. /etc/shadow support is
forced for SGI machines, so that you don't have to recompile if you
choose to convert it to /etc/shadow.
Notes on the integration of SecurID into ssh To enable ssh to allow users to authenticate themselves using SecurID cards, you have to come up with some mechanism to determine which users have such cards and which don't. The mechanism I have adopted is a simple one: a file /etc/securid.users that lists all the users with cards, one on each line. To run sshd with support for SecurID cards, you first of all need to have Security Dynamics' server software installed on the system (quelle surprise). To compile it you will also need the Security Dynamics authentication API, which consists of several .h files and the sdiclient.a library. When you run configure, you must then use the option --with-securid=/your/ace/dir, which will set all the appropriate flags in the Makefile. When all of this has been compiled and installed and a SecurID user signs in, they should request password authentication, not RSA. They will be given the Password: prompt like everyone else, however their response will be sent to the SecurID server, rather than being checked locally against the password file. It would be nice if we could change the prompt, but this would involve changing the dialog between the server and the client (since it the server that knows the user's authentication protocol, but the client which does the prompt). Maybe next time. A more significant issue is the /etc/securid.users file. Security Dynamics has its own approach to this issue, which is very different and incompatible with this one. Security Dynamics distributes a replacement for the user's login shell called sdshell, which simply prompts for the user's pass code, and then invokes the user's real shell, which is stored elsewhere. They also distribute an ftpd, which relies on the user having sdshell as their login shell to determine which users are SecurID users. I have philosophical problems with this approach (I don't think it is the business of the user's shell to perform the authenticationn check, that should be done by /bin/login instead). But that's not the reason I chose a different approach here. I tried to make it work with sdshell as the login shell, and it just has one big problem. Everything is fine for non-interactive sessions, the user gets prompted, enters his passcode and everything goes. But in an interactive session, the user connects, is prompted for his password, enters his passcode, and only then does ssh tell sshd that this is an interactive session! So sshd starts up the user's shell, i.e. sdshell, which promptly demands the user's passcode all over again! And what is really a nuisance is that Security Dynamics of course won't let you use the same passcode twice (for obvious reasons), so you have to wait for the next code to come up on the card, i.e. up to sixty seconds, before you can finish signing on! And I can see no way to avoid the double prompt. So that's why /etc/securid.users. Unfortunately, this means that you can either use ssh, scp and slogin with SecurID support, or you can use Security Dynamics' sdshell and ftpd. Not both (unless you are prepared to live with the double passcode prompt). One last issue and I'm done. This implementation handles only the two return codes ACM_OK and ACM_ACCESS_DENIED. It does not attempt to handle any of the other codes that can arise such as ACM_NEW_PIN_REQUIRED, ACM_NEXT_CODE_REQUIRED and so on. Again, this would involve significant changes to the ssh client/server dialog. If you have any comments about this implementation, or better yet, would like to contribute to it(!), please feel free to send me some e-mail at dmckilli@qc.bell.ca. Regards, -------------------------------------------------------------------- Donald McKillican Tel: (514) 870-3905 Bell Canada Corporate Security E-Mail: dmckilli@QC.Bell.CA Montreal, Canada WWW: http://libertel.montreal.qc.ca/~dmckilli/
Notes on the integration of Tis authentication into ssh
Tis authentication differ from the normal password authentication in
that the user is presented a challenge he has to meet. The nature of
the challenge and the response depends on the authentication method
assigned to each user kown by the authentication server. Ssh and sshd
had to be modified to present the challenge generated by the
authentication server to the user. This couldn't be done without
extending the protocol used between ssh and sshd. Howether, Tis aware
ssh clients can connect to non Tis aware sshd servers.
If the "TISAuthentication" option is set to "yes" on both the client
and server side, the authentication method is the following:
- the client (ssh) asks for tis authentication to the server (sshd),
- the server tries to connect to authsrv (Tis' authentication
server) and asks for identifying the user. If authsrv is not
accessible or do not know about the user, sshd sends an
authentication failure message to the client (ssh) and waits for
another authentication method request. If authsrv knows about
the user, it sends the challenge sentence to sshd. Sshd sends
the sentence to the client,
- the client prompts the challenge to the user and read the
passphrase,
- the client sends the passphrase to sshd,
- sshd sends the passphrase to authsrv,
- authsrv responds to sshd with "ok" or "Permission denied". In
the first case, sshd sends back an success message to the
client. In the second case, it sends a failure message to the
client and shuts down the connection.
The connection between sshd and Tis' authentication server is in clear
text! If the authentication server is on the same host as sshd, this
should not be a security concern. Howether, if they are on separate
hosts, you should make sure that the network connecting them can be
trusted.
Technically, only sshd needs the Tis libraries. It means that ssh is
always "Tis aware", while sshd needs to be compiled with Tis support
(see "--with-tis" option to configure)
Like any application linked with the Tis libraries, sshd need a line
similar to:
*: authserver aaa.bbb.ccc.ddd 7777
in netperm-table (specified during the installation of the Tis
libraries. Usually /usr/local/etc/netperm-table). The Tis firewall
toolkit can be found at http://www.tis.com.
USING SSH AND TIS' FIREWALL TOOLKIT.
Since there is no proxy for ssh, you configure sshd on one of your
hosts to authenticate users through the authentication server of the
firewall and configure the plug-gw application on the firewall to
forward any packet it receives on port 22 to your sshd server.
If you have any comments about this implementation, or better yet, would
like to contribute to it(!), please feel free to send me some e-mail at
Andre.April@cediti.be.
Regards,
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.