See http://www.openssh.com/txt/release-6.6 for the release notes.

- A Japanese translation of this document and of the OpenSSH FAQ is
- available at http://www.unixuser.org/~haruyama/security/openssh/index.html
- Thanks to HARUYAMA Seigo <haruyama@unixuser.org>

This is the port of OpenBSD's excellent OpenSSH[0] to Linux and other
Unices.

OpenSSH is based on the last free version of Tatu Ylonen's sample
implementation with all patent-encumbered algorithms removed (to
external libraries), all known security bugs fixed, new features
reintroduced and many other clean-ups.  OpenSSH has been created by
Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt,
and Dug Song. It has a homepage at http://www.openssh.com/

This port consists of the re-introduction of autoconf support, PAM
support, EGD[1]/PRNGD[2] support and replacements for OpenBSD library
functions that are (regrettably) absent from other unices. This port
has been best tested on AIX, Cygwin, HP-UX, Linux, MacOS/X,
NetBSD, OpenBSD, OpenServer, Solaris, Unicos, and UnixWare.

This version actively tracks changes in the OpenBSD CVS repository.

The PAM support is now more functional than the popular packages of
commercial ssh-1.2.x. It checks "account" and "session" modules for
all logins, not just when using password authentication.

OpenSSH depends on Zlib[3], OpenSSL[4] and optionally PAM[5].

There is now several mailing lists for this port of OpenSSH. Please
refer to http://www.openssh.com/list.html for details on how to join.

Please send bug reports and patches to the mailing list
openssh-unix-dev@mindrot.org. The list is open to posting by
unsubscribed users.Code contribution are welcomed, but please follow the
OpenBSD style guidelines[6].

Please refer to the INSTALL document for information on how to install
OpenSSH on your system. There are a number of differences between this
port of OpenSSH and F-Secure SSH 1.x, please refer to the OpenSSH FAQ[7]
for details and general tips.

Damien Miller <djm@mindrot.org>

Miscellania -

This version of OpenSSH is based upon code retrieved from the OpenBSD
CVS repository which in turn was based on the last free sample
implementation released by Tatu Ylonen.

References -

[0] http://www.openssh.com/faq.html
[1] http://www.lothar.com/tech/crypto/
[2] http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
[3] http://www.gzip.org/zlib/
[4] http://www.openssl.org/
[5] http://www.openpam.org
    http://www.kernel.org/pub/linux/libs/pam/
    (PAM also is standard on Solaris and HP-UX 11)
[6] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9
[7] http://www.openssh.com/faq.html

$Id: README,v 1.86 2014/02/27 23:03:53 djm Exp $

How to verify host keys using OpenSSH and DNS
---------------------------------------------

OpenSSH contains support for verifying host keys using DNS as described in
draft-ietf-secsh-dns-05.txt. The document contains very brief instructions
on how to use this feature. Configuring DNS is out of the scope of this
document.


(1) Server: Generate and publish the DNS RR

To create a DNS resource record (RR) containing a fingerprint of the
public host key, use the following command:

	ssh-keygen -r hostname -f keyfile -g

where "hostname" is your fully qualified hostname and "keyfile" is the
file containing the public host key file. If you have multiple keys,
you should generate one RR for each key.

In the example above, ssh-keygen will print the fingerprint in a
generic DNS RR format parsable by most modern name server
implementations. If your nameserver has support for the SSHFP RR
you can omit the -g flag and ssh-keygen will print a standard SSHFP RR.

To publish the fingerprint using the DNS you must add the generated RR
to your DNS zone file and sign your zone.


(2) Client: Enable ssh to verify host keys using DNS

To enable the ssh client to verify host keys using DNS, you have to
add the following option to the ssh configuration file
($HOME/.ssh/config or /etc/ssh/ssh_config):

    VerifyHostKeyDNS yes

Upon connection the client will try to look up the fingerprint RR
using DNS. If the fingerprint received from the DNS server matches
the remote host key, the user will be notified.


	Jakob Schlyter
	Wesley Griffin


$OpenBSD: README.dns,v 1.2 2003/10/14 19:43:23 jakob Exp $

Notes:

NONE CIPHER:
  To use the NONE option you must have the NoneEnabled switch set on the server
  and you MUST have *both* NoneEnabled and NoneSwitch set to yes on the client.
  The NONE feature works with ALL ssh subsystems (as far as we can tell)
  as long as there is no tty allocated.
  If a user uses the -T switch to prevent a tty being created the NONE cipher
  will be disabled.


PERFORMANCE:
  The performance increase will only be as good as the network and TCP stack
  tuning on the reciever side of the connection allows.  As a rule of thumb a
  user will need at least 10Mb/s connection with a 100ms RTT to see a doubling
  of performance.
  The HPN-SSH home page  http://www.psc.edu/networking/projects/hpn-ssh
  describes this in greater detail.


BUFFER SIZES:
- if HPN is disabled the receive buffer size will be set to the OpenSSH default
  of 64K.

- if a HPN system connects to a non-HPN system the receive buffer will
  be set to the HPNBufferSize value. The default is 2MB but user adjustable.

- If a HPN to HPN connection is established a number of different things might
  happen based on the user options and conditions.

  Conditions: HPNBufferSize NOT Set, TCPRcvBufPoll enabled, TCPRcvBuf NOT Set
  Result: HPN Buffer Size = up to 64MB
    This is the default state.  The HPN buffer size will grow to a maximum of
    64MB as the TCP receive buffer grows.  The maximum HPN Buffer size of 64MB
    is geared towards 10GigE transcontinental connections.

  Conditions: HPNBufferSize NOT Set, TCPRcvBufPoll disabled, TCPRcvBuf NOT Set
  Result: HPN Buffer Size = TCP receive buffer value.
    Users on non-autotuning systesm should disable TCPRcvBufPoll in the
    ssh_cofig and sshd_config

  Conditions: HPNBufferSize SET, TCPRcvBufPoll disabled, TCPRcvBuf NOT Set
  Result: HPN Buffer Size = minmum of TCP receive buffer and HPNBufferSize.
    This would be the system defined TCP receive buffer (RWIN).

  Conditions: HPNBufferSize SET, TCPRcvBufPoll disabled, TCPRcvBuf SET
  Result: HPN Buffer Size = minmum of TCPRcvBuf and HPNBufferSize.
    Generally there is no need to set both.

  Conditions: HPNBufferSize SET, TCPRcvBufPoll enabled, TCPRcvBuf NOT Set
  Result: HPN Buffer Size = grows to HPNBufferSize
    The buffer will grow up to the maximum size specified here.

  Conditions: HPNBufferSize SET, TCPRcvBufPoll enabled, TCPRcvBuf SET
  Result: HPN Buffer Size = minmum of TCPRcvBuf and HPNBufferSize.
    Generally there is no need to set both of these, especially on autotuning
    systems. However, if the users wishes to override the autotuning this would
    be one way to do it.

  Conditions: HPNBufferSize NOT Set, TCPRcvBufPoll enabled, TCPRcvBuf SET
  Result: HPN Buffer Size = TCPRcvBuf.
   This will override autotuning and set the TCP recieve buffer to the user
   defined value.


HPN SPECIFIC CONFIGURATION OPTIONS:

- HPNDisabled=[yes/no] client/server
  In some situations, such as transfers on a local area network, the impact
  of the HPN code produces a net decrease in performance.  In these cases it is
  helpful to disable the HPN functionality. By default HPNDisabled is set to no.

- HPNBufferSize=[int]KB client/server
  This is the default buffer size the HPN functionality uses when interacting
  with non-HPN SSH installations.  Conceptually this is similar to the TcpRcvBuf
  option as applied to the internal SSH flow control.  This value can range from
  1KB to 64MB (1-65536).  Use of oversized or undersized buffers can cause
  performance problems depending on the roud trip time of the network path.
  The default size of this buffer is 2MB.

- TcpRcvBufPoll=[yes/no] client/server
  Enable or disable the polling of the TCP receive buffer through the life
  of the connection.  You would want to make sure that this option is enabled
  for systems making use of autotuning kernels (linux 2.4.24+, 2.6, MS Vista,
  FreeBSD 7.x and later). Default is yes.

- TcpRcvBuf=[int]KB client
  Set the TCP socket receive buffer to n Kilobytes.  It can be set up to the
  maximum socket size allowed by the system.  This is useful in situations where
  the TCP receive window is set low but the maximum buffer size is set higher
  (as is typical).  This works on a per TCP connection basis.  You can also use
  this to artifically limit the transfer rate of the connection.  In these cases
  the throughput will be no more than n/RTT.  The minimum buffer size is 1KB.
  Default is the current system wide TCP receive buffer size.

- NoneEnabled=[yes/no] client/server
  Enable or disable the use of the None cipher.  Care must always be used when
  enabling this as it will allow users to send data in the clear.  However, it
  is important to note that authentication information remains encrypted even
  if this option is enabled.  Set to no by default.

- NoneSwitch=[yes/no] client
  Switch the encryption cipher being used to the None cipher after
  authentication takes place.  NoneEnabled must be enabled on both the client
  and server side of the connection.  When the connection switches to the NONE
  cipher a warning is sent to STDERR.  The connection attempt will fail with an
  error if a client requests a NoneSwitch from the server that does not
  explicitly have NoneEnabled set to yes.
  Note: The NONE cipher cannot be used in interactive (shell) sessions and it
  will fail silently.  Set to no by default.


CREDITS:

  This patch was conceived, designed, and led by Chris Rapier (rapier@psc.edu)
  The majority of the actual coding for versions up to HPN12v1 was performed
  by Michael Stevens (mstevens@andrew.cmu.edu).
  The MT-AES-CTR cipher was implemented by Ben Bennet (ben@psc.edu).
  This work was financed, in part, by Cisco System, Inc., the National Library
  of Medicine, and the National Science Foundation.

This file contains notes about OpenSSH on specific platforms.

AIX
---
As of OpenSSH 3.8p1, sshd will now honour an accounts password expiry
settings, where previously it did not.  Because of this, it's possible for
sites that have used OpenSSH's sshd exclusively to have accounts which
have passwords expired longer than the inactive time (ie the "Weeks between
password EXPIRATION and LOCKOUT" setting in SMIT or the maxexpired
chuser attribute).

Accounts in this state must have their passwords reset manually by the
administrator.  As a precaution, it is recommended that the administrative
passwords be reset before upgrading from OpenSSH <3.8.

As of OpenSSH 4.0, configure will attempt to detect if your version
and maintenance level of AIX has a working getaddrinfo, and will use it
if found.  This will enable IPv6 support.  If for some reason configure
gets it wrong, or if you want to build binaries to work on earlier MLs
than the build host then you can add "-DBROKEN_GETADDRINFO" to CFLAGS
to force the previous IPv4-only behaviour.

IPv6 known to work: 5.1ML7 5.2ML2 5.2ML5
IPv6 known broken: 4.3.3ML11 5.1ML4

If you wish to use dynamic libraries that aren't in the normal system
locations (eg IBM's OpenSSL and zlib packages) then you will need to
define the environment variable blibpath before running configure, eg

blibpath=/lib:/usr/lib:/opt/freeware/lib ./configure \
  --with-ssl-dir=/opt/freeware --with-zlib=/opt/freeware

If sshd is built with the WITH_AIXAUTHENTICATE option (which is enabled
by default) then sshd checks that users are permitted via the
loginrestrictions() function, in particular that the user has the
"rlogin" attribute set.  This check is not done for the root account,
instead the PermitRootLogin setting in sshd_config is used.


Cygwin
------
To build on Cygwin, OpenSSH requires the following packages:
gcc, gcc-mingw-core, mingw-runtime, binutils, make, openssl,
openssl-devel, zlib, minres, minires-devel.


Darwin and MacOS X
------------------
Darwin does not provide a tun(4) driver required for OpenSSH-based
virtual private networks. The BSD manpage still exists, but the driver
has been removed in recent releases of Darwin and MacOS X.

Nevertheless, tunnel support is known to work with Darwin 8 and
MacOS X 10.4 in Point-to-Point (Layer 3) and Ethernet (Layer 2) mode
using a third party driver. More information is available at:
	http://www-user.rhrk.uni-kl.de/~nissler/tuntap/


Linux
-----

Some Linux distributions (including Red Hat/Fedora/CentOS) include
headers and library links in the -devel RPMs rather than the main
binary RPMs. If you get an error about headers, or complaining about a
missing prerequisite then you may need to install the equivalent
development packages.  On Redhat based distros these may be openssl-devel,
zlib-devel and pam-devel, on Debian based distros these may be
libssl-dev, libz-dev and libpam-dev.


Solaris
-------
If you enable BSM auditing on Solaris, you need to update audit_event(4)
for praudit(1m) to give sensible output.  The following line needs to be
added to /etc/security/audit_event:

	32800:AUE_openssh:OpenSSH login:lo

The BSM audit event range available for third party TCB applications is
32768 - 65535.  Event number 32800 has been choosen for AUE_openssh.
There is no official registry of 3rd party event numbers, so if this
number is already in use on your system, you may change it at build time
by configure'ing --with-cflags=-DAUE_openssh=32801 then rebuilding.


Platforms using PAM
-------------------
As of OpenSSH 4.3p1, sshd will no longer check /etc/nologin itself when
PAM is enabled.  To maintain existing behaviour, pam_nologin should be
added to sshd's session stack which will prevent users from starting shell
sessions.  Alternatively, pam_nologin can be added to either the auth or
account stacks which will prevent authentication entirely, but will still
return the output from pam_nologin to the client.


$Id: README.platform,v 1.10 2009/08/28 23:14:48 dtucker Exp $

Privilege separation, or privsep, is method in OpenSSH by which
operations that require root privilege are performed by a separate
privileged monitor process.  Its purpose is to prevent privilege
escalation by containing corruption to an unprivileged process.
More information is available at:
	http://www.citi.umich.edu/u/provos/ssh/privsep.html

Privilege separation is now enabled by default; see the
UsePrivilegeSeparation option in sshd_config(5).

On systems which lack mmap or anonymous (MAP_ANON) memory mapping,
compression must be disabled in order for privilege separation to
function.

When privsep is enabled, during the pre-authentication phase sshd will
chroot(2) to "/var/empty" and change its privileges to the "sshd" user
and its primary group.  sshd is a pseudo-account that should not be
used by other daemons, and must be locked and should contain a
"nologin" or invalid shell.

You should do something like the following to prepare the privsep
preauth environment:

	# mkdir /var/empty
	# chown root:sys /var/empty
	# chmod 755 /var/empty
	# groupadd sshd
	# useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

/var/empty should not contain any files.

configure supports the following options to change the default
privsep user and chroot directory:

  --with-privsep-path=xxx Path for privilege separation chroot
  --with-privsep-user=user Specify non-privileged user for privilege separation

Privsep requires operating system support for file descriptor passing.
Compression will be disabled on systems without a working mmap MAP_ANON.

PAM-enabled OpenSSH is known to function with privsep on AIX, FreeBSD,
HP-UX (including Trusted Mode), Linux, NetBSD and Solaris.

On Cygwin, Tru64 Unix, OpenServer, and Unicos only the pre-authentication
part of privsep is supported.  Post-authentication privsep is disabled
automatically (so you won't see the additional process mentioned below).

Note that for a normal interactive login with a shell, enabling privsep
will require 1 additional process per login session.

Given the following process listing (from HP-UX):

     UID   PID  PPID  C    STIME TTY       TIME COMMAND
    root  1005     1  0 10:45:17 ?         0:08 /opt/openssh/sbin/sshd -u0
    root  6917  1005  0 15:19:16 ?         0:00 sshd: stevesk [priv]
 stevesk  6919  6917  0 15:19:17 ?         0:03 sshd: stevesk@2
 stevesk  6921  6919  0 15:19:17 pts/2     0:00 -bash

process 1005 is the sshd process listening for new connections.
process 6917 is the privileged monitor process, 6919 is the user owned
sshd process and 6921 is the shell process.

$Id: README.privsep,v 1.16 2005/06/04 23:21:41 djm Exp $

How to use OpenSSH-based virtual private networks
-------------------------------------------------

OpenSSH contains support for VPN tunneling using the tun(4) network
tunnel pseudo-device which is available on most platforms, either for
layer 2 or 3 traffic.

The following brief instructions on how to use this feature use
a network configuration specific to the OpenBSD operating system.

(1) Server: Enable support for SSH tunneling

To enable the ssh server to accept tunnel requests from the client, you
have to add the following option to the ssh server configuration file
(/etc/ssh/sshd_config):

	PermitTunnel yes

Restart the server or send the hangup signal (SIGHUP) to let the server
reread it's configuration.

(2) Server: Restrict client access and assign the tunnel

The OpenSSH server simply uses the file /root/.ssh/authorized_keys to
restrict the client to connect to a specified tunnel and to
automatically start the related interface configuration command. These
settings are optional but recommended:

	tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... reyk@openbsd.org

(3) Client: Configure the local network tunnel interface

Use the hostname.if(5) interface-specific configuration file to set up
the network tunnel configuration with OpenBSD. For example, use the
following configuration in /etc/hostname.tun0 to set up the layer 3
tunnel on the client:

	inet 192.168.5.1 255.255.255.252 192.168.5.2

OpenBSD also supports layer 2 tunneling over the tun device by adding
the link0 flag:

	inet 192.168.1.78 255.255.255.0 192.168.1.255 link0

Layer 2 tunnels can be used in combination with an Ethernet bridge(4)
interface, like the following example for /etc/bridgename.bridge0:

	add tun0
	add sis0
	up

(4) Client: Configure the OpenSSH client

To establish tunnel forwarding for connections to a specified
remote host by default, use the following ssh client configuration for
the privileged user (in /root/.ssh/config):

	Host sshgateway
		Tunnel yes
		TunnelDevice 0:any
		PermitLocalCommand yes
	        LocalCommand sh /etc/netstart tun0

A more complicated configuration is possible to establish a tunnel to
a remote host which is not directly accessible by the client.
The following example describes a client configuration to connect to
the remote host over two ssh hops in between. It uses the OpenSSH
ProxyCommand in combination with the nc(1) program to forward the final
ssh tunnel destination over multiple ssh sessions.

	Host access.somewhere.net
	        User puffy
	Host dmzgw
	        User puffy
	        ProxyCommand ssh access.somewhere.net nc dmzgw 22
	Host sshgateway
	        Tunnel Ethernet
	        TunnelDevice 0:any
	        PermitLocalCommand yes
	        LocalCommand sh /etc/netstart tun0
	        ProxyCommand ssh dmzgw nc sshgateway 22

The following network plan illustrates the previous configuration in
combination with layer 2 tunneling and Ethernet bridging.

+--------+       (          )      +----------------------+
| Client |------(  Internet  )-----| access.somewhere.net |
+--------+       (          )      +----------------------+
    : 192.168.1.78                             |
    :.............................         +-------+
     Forwarded ssh connection    :         | dmzgw |
     Layer 2 tunnel              :         +-------+
                                 :             |
                                 :             |
                                 :      +------------+
                                 :......| sshgateway |
                                      | +------------+
--- real connection                 Bridge ->  |          +----------+
... "virtual connection"                     [ X ]--------| somehost |
[X] switch                                                +----------+
                                                          192.168.1.25

(5) Client: Connect to the server and establish the tunnel

Finally connect to the OpenSSH server to establish the tunnel by using
the following command:

	ssh sshgateway

It is also possible to tell the client to fork into the background after
the connection has been successfully established:

	ssh -f sshgateway true

Without the ssh configuration done in step (4), it is also possible
to use the following command lines:

	ssh -fw 0:1 sshgateway true
	ifconfig tun0 192.168.5.1 192.168.5.2 netmask 255.255.255.252

Using OpenSSH tunnel forwarding is a simple way to establish secure
and ad hoc virtual private networks. Possible fields of application
could be wireless networks or administrative VPN tunnels.

Nevertheless, ssh tunneling requires some packet header overhead and
runs on top of TCP. It is still suggested to use the IP Security
Protocol (IPSec) for robust and permanent VPN connections and to
interconnect corporate networks.

	Reyk Floeter

$OpenBSD: README.tun,v 1.4 2006/03/28 00:12:31 deraadt Exp $