SSH Options: X11 Forwarding, Syslog, Configuration Files, and Authentication Methods

play through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring. For this reason, X11 forwarding is subjected to X11 SECURITY ex‐ tension restrictions by default. Refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more infor‐ mation. (Debian‐specific: X11 forwarding is not subjected to X11 SECU‐ RITY extension restrictions by default, because too many pro‐ grams currently crash in this mode. Set the ForwardX11Trusted option to “no” to restore the upstream behaviour. This may change in future depending on client‐side improvements.) -x Disables X11 forwarding. -Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls. (Debian‐specific: In the default configuration, this option is equivalent to -X, since ForwardX11Trusted defaults to “yes” as described above. Set the ForwardX11Trusted option to “no” to restore the upstream behaviour. This may change in future de‐ pending on client‐side improvements.) -y Send log information using the syslog(3) system module. By de‐ fault this information is sent to stderr. ssh may additionally obtain configuration data from a per‐user configu‐ ration file and a system‐wide configuration file. The file format and configuration options are described in ssh_config(5). AUTHENTICATION The OpenSSH SSH client supports SSH protocol 2. The methods available for authentication are: GSSAPI‐based authentica‐ tion, host‐based authentication, public key authentication, keyboard‐in‐ teractive authentication, and password authentication. Authentication methods are tried in the order specified above, though PreferredAuthentications can be used to change the default order. Host‐based authentication works as follows: If the machine the user logs in from is listed in /etc/hosts.equiv or /etc/ssh/shosts.equiv on the remote machine, the user is non‐root and the user names are the same on both sides, or if the files ~/.rhosts or ~/.shosts exist in the user’s home directory on the remote machine and contain a line containing the name of the client machine and the name of the user on that machine, the user is considered for login. Additionally, the server must be able to verify the client’s host key (see the description of /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts, below) for login to be permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing, and routing spoofing. [Note to the administra‐ tor: /etc/hosts.equiv, ~/.rhosts, and the rlogin/rsh protocol in gen‐ eral, are inherently insecure and should be disabled if security is de‐ sired.] Public key authentication works as follows: The scheme is based on pub‐ lic‐key cryptography, using cryptosystems where encryption and decryp‐ tion are done using separate keys, and it is unfeasible to derive the decryption key from the encryption key. The idea is that each user cre‐ ates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. ssh im‐ plements public key authentication protocol automatically, using one of the DSA, ECDSA, Ed25519 or RSA algorithms. The HISTORY section of ssl(8) (on non‐OpenBSD systems, see http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8#HISTORY)

This section details SSH options related to X11 forwarding (-x, -Y), syslog (-y), and configuration files. It also outlines authentication methods supported by OpenSSH, including GSSAPI-based, host-based, public key, keyboard-interactive, and password authentication. Host-based and public key authentication methods are explained in detail.