these files should not exist. the developers have been given ample time

and warnings to integrate this into the manual page proper, but users who
find documentation missing keep being pointed at these files in the src
tree. we now delete the files, so that they will document these things
in the correct place.  you know who you are, and btw, jmc will help you
integrate the information into the man page if you just wrote simple bits
of text and asked nicely..

2 files changed, 0 insertions, 179 deletions

diff --git a/usr.bin/ssh/README.dns b/usr.bin/ssh/README.dns
deleted file mode 100644
index 97879183e39..00000000000
--- a/usr.bin/ssh/README.dns
+++ /dev/null
@@ -1,47 +0,0 @@
-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 $
diff --git a/usr.bin/ssh/README.tun b/usr.bin/ssh/README.tun
deleted file mode 100644
index 5e1cb074c2e..00000000000
--- a/usr.bin/ssh/README.tun
+++ /dev/null
@@ -1,132 +0,0 @@
-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 $