diff options
| -rw-r--r-- | usr.bin/ssh/README.dns | 47 | ||||
| -rw-r--r-- | usr.bin/ssh/README.tun | 132 |
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 $ |