Verifying Host Keys via DNS and SSH-based VPNs

if the session itself is interactive or not. By learning the pattern a known server produces, a user can easily find out that the host key has changed when a completely different pattern is displayed. Because these patterns are not unambiguous however, a pattern that looks similar to the pattern remembered only gives a good probability that the host key is the same, not guaranteed proof. To get a listing of the fingerprints along with their random art for all known hosts, the following command line can be used: $ ssh‐keygen ‐lv ‐f ~/.ssh/known_hosts If the fingerprint is unknown, an alternative method of verification is available: SSH fingerprints verified by DNS. An additional resource record (RR), SSHFP, is added to a zonefile and the connecting client is able to match the fingerprint with that of the key presented. In this example, we are connecting a client to a server, “host.example.com”. The SSHFP resource records should first be added to the zonefile for host.example.com: $ ssh‐keygen ‐r host.example.com. The output lines will have to be added to the zonefile. To check that the zone is answering fingerprint queries: $ dig ‐t SSHFP host.example.com Finally the client connects: $ ssh ‐o "VerifyHostKeyDNS ask" host.example.com [...] Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? See the VerifyHostKeyDNS option in ssh_config(5) for more information. SSH‐BASED VIRTUAL PRIVATE NETWORKS ssh contains support for Virtual Private Network (VPN) tunnelling using the tun(4) network pseudo‐device, allowing two networks to be joined se‐ curely. The sshd_config(5) configuration option PermitTunnel controls whether the server supports this, and at what level (layer 2 or 3 traf‐ fic). The following example would connect client network 10.0.50.0/24 with re‐ mote network 10.0.99.0/24 using a point‐to‐point connection from 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gate‐ way to the remote network, at 192.168.1.15, allows it. On the client: # ssh ‐f ‐w 0:1 192.168.1.15 true # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 # route add 10.0.99.0/24 10.1.1.2 On the server: # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 # route add 10.0.50.0/24 10.1.1.1 Client access may be more finely tuned via the /root/.ssh/authorized_keys file (see below) and the PermitRootLogin server option. The following entry would permit connections on tun(4) device 1 from user “jane” and on tun device 2 from user “john”, if PermitRootLogin is set to “forced‐commands‐only”: tunnel="1",command="sh /etc/netstart tun1" ssh‐rsa ... jane tunnel="2",command="sh /etc/netstart tun2" ssh‐rsa ... john Since an SSH‐based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wireless VPNs. More perma‐ nent VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8). ENVIRONMENT ssh will normally set the following environment variables: DISPLAY The DISPLAY variable indicates the location of the X11 server. It is automatically set by ssh to point to a value of the form “hostname:n”, where “hostname” indicates the host where the shell runs, and ‘n’ is an integer ≥ 1. ssh uses this special value

The text describes alternative host key verification methods, including DNS-based verification using SSHFP records. It provides an example of adding SSHFP records to a zonefile and configuring the SSH client to verify host keys using DNS. Additionally, it explains how to set up SSH-based Virtual Private Networks (VPNs) using the tun(4) network pseudo-device, covering client and server configurations, routing, and access control via authorized_keys. It notes that while SSH-based VPNs are useful for temporary setups, tools like ipsecctl(8) and isakmpd(8) are better suited for permanent VPNs. It also mentions environment variables like DISPLAY that are automatically set by SSH.