See https://www.openssh.com/releasenotes.html#9.1p1 for the release notes.

Please read https://www.openssh.com/report.html for bug reporting
instructions and note that we do not use Github for bug reporting or
patch/pull-request management.

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 https://www.openssh.com/

This port consists of the re-introduction of autoconf support, PAM
support, EGD/PRNGD 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,
FreeBSD, NetBSD, OpenBSD, OpenServer, Solaris 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.

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

Please send bug reports and patches to https://bugzilla.mindrot.org or
the mailing list openssh-unix-dev@mindrot.org.  To mitigate spam, the
list only allows posting from subscribed addresses.  Code contribution
are welcomed, but please follow the OpenBSD style guidelines[1].

Please refer to the INSTALL document for information on dependencies and
how to install OpenSSH on your system.

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] https://www.openssh.com/
[1] https://man.openbsd.org/style.9

.depend
.github/
.gitignore
.git_allowed_signers
.git_allowed_signers.asc
.skipped-commit-ids
ChangeLog
INSTALL
Makefile.in
OVERVIEW
PROTOCOL.u2f
README.md
SECURITY.md
README.platform
README.privsep
TODO
aclocal.m4
audit-bsm.c
audit-linux.c
audit.c
auth-bsdauth.c
auth-krb5.c
auth-shadow.c
auth-sia.c
auth-sia.h
auth2-gss.c
buildpkg.sh.in
cipher-aes.c
cipher-aesctr.c
cipher-chachapoly.c
cipher-ctr.c
config.guess
config.h.in
config.sub
configure
configure.ac
contrib/Makefile
contrib/README
contrib/aix/
contrib/cygwin/
contrib/findssl.sh
contrib/gnome-ssh-askpass1.c
contrib/gnome-ssh-askpass2.c
contrib/gnome-ssh-askpass3.c
contrib/hpux/
contrib/redhat/
contrib/solaris/
contrib/sshd.pam.freebsd
contrib/sshd.pam.generic
contrib/suse/
digest-libc.c
fixalgorithms
fixpaths
gss-genr.c
gss-serv-krb5.c
gss-serv.c
install-sh
int32_minmax.inc
logintest.c
m4/
md5crypt.c
md5crypt.h
mdoc2man.awk
mkinstalldirs
moduli.0
nchan.ms
nchan2.ms
openbsd-compat/
openssh.xml.in
opensshd.init.in
platform-pledge.c
platform-tracing.c
regress/
rijndael.c
sandbox-capsicum.c
sandbox-darwin.c
sandbox-null.c
sandbox-pledge.c
sandbox-seccomp-filter.c
sandbox-solaris.c
sandbox-systrace.c
scp.0
sftp-server.0
sftp.0
sk-usbhid.c
sntrup761.sh
ssh-add.0
ssh-agent.0
ssh-gss.h
ssh-keygen.0
ssh-keyscan.0
ssh-keysign.0
ssh-pkcs11-client.c
ssh-pkcs11-helper.0
ssh-pkcs11.c
ssh-sk-helper.0
ssh-sk-helper.8
ssh-sk-helper.c
ssh-sk.c
ssh-xmss.c
ssh.0
ssh_config.0
sshd.0
sshd_config.0
sshkey-xmss.c
survey.sh.in
xmss_commons.c
xmss_commons.h
xmss_fast.c
xmss_hash.c
xmss_hash.h
xmss_hash_address.c
xmss_hash_address.h
xmss_wots.c
xmss_wots.h

OPENSSH
=======

Original source can be downloaded from OpenBSD at
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/

file = openssh-9.1p1.tar.gz
date = 04 October 2022
size = 1838747
sha1 = 15545440268967511d3194ebf20bcd0c7ff3fcc9

A list of deleted files is in README.DELETED.

Configured with
===============
./configure --prefix=/usr --sysconfdir=/etc/ssh --with-sandbox=rlimit --with-pam \
	    --with-libedit --without-ssl-engine --without-rpath \
	    --with-privsep-path=/var/empty --with-xauth=/usr/local/bin/xauth \
	    --disable-pkcs11 ac_cv_lib_dl_dlopen=no

The following files have been patched (* planned)
=================================================
  auth-pam.c			WARNS, static sshpam_password_change_required()
  platform.h			pledge dummies
  session.c			WARNS, unused copy_environment()
				WARNS, strdup(login_getcapstr()) (leak)
  servconf.c			PAM defaults
  sshd_config			PasswordAuthentication no

NOTE: The configure script misdetects few things.
Update config.h and openbsd-compat in lib/libssh.

Used in:
lib/libssh/
libexec/sftp-server/
libexec/ssh-keysign/
libexec/ssh-pkcs11-helper/
usr.bin/scp/
usr.bin/sftp/
usr.bin/ssh-add/
usr.bin/ssh-agent/
usr.bin/ssh-keygen/
usr.bin/ssh-keyscan/
usr.bin/ssh/
usr.sbin/sshd/

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

OpenSSH contains support for verifying host keys using DNS as described
in https://tools.ietf.org/html/rfc4255. 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 $

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 $