X11 Forwarding, Agent Forwarding, and Host Key Verification in SSH

$ irc ‐c ’#users’ pinky IRC/127.0.0.1 The -f option backgrounds ssh and the remote command “sleep 10” is spec‐ ified to allow an amount of time (10 seconds, in the example) to start the program which is going to use the tunnel. If no connections are made within the time specified, ssh will exit. X11 FORWARDING If the ForwardX11 variable is set to “yes” (or see the description of the -X, -x, and -Y options above) and the user is using X11 (the DISPLAY environment variable is set), the connection to the X11 display is auto‐ matically forwarded to the remote side in such a way that any X11 pro‐ grams started from the shell (or command) will go through the encrypted channel, and the connection to the real X server will be made from the local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in configura‐ tion files. The DISPLAY value set by ssh will point to the server machine, but with a display number greater than zero. This is normal, and happens because ssh creates a “proxy” X server on the server machine for forwarding the connections over the encrypted channel. ssh will also automatically set up Xauthority data on the server ma‐ chine. For this purpose, it will generate a random authorization cookie, store it in Xauthority on the server, and verify that any for‐ warded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server machine (and no cookies are sent in the plain). If the ForwardAgent variable is set to “yes” (or see the description of the -A and -a options above) and the user is using an authentication agent, the connection to the agent is automatically forwarded to the re‐ mote side. VERIFYING HOST KEYS When connecting to a server for the first time, a fingerprint of the server’s public key is presented to the user (unless the option StrictHostKeyChecking has been disabled). Fingerprints can be deter‐ mined using ssh‐keygen(1): $ ssh‐keygen ‐l ‐f /etc/ssh/ssh_host_rsa_key If the fingerprint is already known, it can be matched and the key can be accepted or rejected. If only legacy (MD5) fingerprints for the server are available, the ssh‐keygen(1) -E option may be used to down‐ grade the fingerprint algorithm to match. Because of the difficulty of comparing host keys just by looking at fin‐ gerprint strings, there is also support to compare host keys visually, using random art. By setting the VisualHostKey option to “yes”, a small ASCII graphic gets displayed on every login to a server, no matter 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

This section discusses X11 forwarding in SSH, detailing how it enables secure remote execution of graphical applications through a proxy X server. It also covers automatic Xauthority setup for authentication. Additionally, the document explains agent forwarding for secure agent connection and methods for verifying host keys, including comparing fingerprints and using visual random art, along with DNS-based verification using SSHFP records.