OpenSSH/Client Configuration Files

Client configuration files can be per user or system wide, with the former taking precedence over the latter and run-time arguments in the shell overriding both. In these configuration files, one parameter per line is allowed with the parameter name followed by its value or values. Empty lines and lines starting with the hash (#) are ignored. An equal sign (=) can be used instead of whitespace between the parameter name and the values.

Values are case-sensitive, but parameter names are not.

System-wide Client Configuration Files

System-wide client files set the default configuration for all users of OpenSSH clients on that system. These defaults can be overridden, in many cases, by the user's own default settings in a local configuration file. Both can be overridden, in many cases, by specifying various options or parameters at run time. The prioritization is as follows:

1. run time arguments via the shell
2. user's own configuration
3. system-wide configuration

The first value obtained is used. The user's own configuration file and the system-wide configuration file can also point to additional configuration files to be included using the Include directive, starting with OpenSSH 7.3. The Include directive can be specified anywhere in the configuration file even inside a Match or Host block. Care should be used when nesting this directive.

/etc/ssh/ssh_config

This file defines all the default settings for the client utilities for all users on that system. it must be readable by all users. The configuration options are described in detail in ssh_config(5).

Below a shortcut is made for connecting to arc.example.org. It is enough to enter ssh arc and the rest of the information gets filled in automatically.

Host arc
        Port 2022
        HostName arc.example.org
        User fred
        IdentityFile ~/.ssh/id_rsa_arc

/etc/ssh/ssh_known_hosts

This contains the system-wide list of known host keys used to verify the identity of the remote host and thus hinder impersonation or eavesdropping. This file should be prepared by the system administrator to contain the public host keys of all necessary hosts. It should be world-readable.

See ~/.ssh/known_hosts below for more explanation or see sshd(8) for further details of the format of this file.

/etc/ssh/sshrc

This file resides on the server and programs in this file are executed there by ssh(1) when the user logs in, just before the user's shell or designated program is started. It is not run as root, but instead as the user who is logging in. See the sshd(8) manual page in the section SSHRC for more information.

User-specific Client Configuration Files

Users can override the default system-wide client settings and choose their own defaults. For situations where the same change is made repeatedly it can make save work to add them to the user's local configuration.

Client Side Files

These files reside on the client machine.

~/.ssh/config

The user's own configuration file which, where applicable, overrides the settings in the global client configuration file, /etc/ssh/ssh_config. The configuration options are described in detail in ssh_config(5).

This file must not be accessible to other users in any way. Set strict permissions: read/write for the user, and not accessible by others. It may group-writable if and only if that user is the only member of the group in question.

Local override of defaults

Not all options can be set or overriden by the user. Those options which may be set or overridden by the user can by defined at the end of the user's configuration, ~/.ssh/config, file by matching all hosts. Those options which may not be set or overridden will be ignored.

Host *
        ExitOnForwardFailure	yes
        Protocol	2
        ServerAliveInterval	400

~/.ssh/known_hosts

As with /etc/ssh/ssh_known_hosts, this file contains the known keys for hosts that have been connected to in the past and is used to verify the identity of the remote host and protect against impersonation or man-in-the-middle attacks. With each subsequent connection the key will be compared to the key provided by the remote server. If there is a match, the connection will proceed. If the match fails, ssh(1) will fail with an error message. If there is no key at all listed for that remote host, then the key's fingerprint will be displayed and there will be the option to automatically add the key to the file. This file can be created and edited manually, but if it does not exist it will be created automatically by ssh(1) when it first connects to a remote host.

Server Side Files

These files reside on the server, by default in the user's directory. However, the server can be configured to look for them in other locations, if needed.

~/.ssh/authorized_keys

authorized_keys is a one-key-per-line register of public ECDSA, RSA and ED25519 keys that this account can use to log in with. The file's contents are not highly sensitive, but the recommended permissions are read/write for the user and not accessible by others. The whole key including options and comments must be on a single, unbroken line.

ssh-rsa AAAAB3NzaC1yc2EAAA...41Ev521Ei2hvz7S2QNr1zAiVaOFy5Lwc8Lo+Jk=

Lines starting with a hash (#) are ignored. Whitespace is used to separate the key's fields. They are, in sequence, an optional list of login options, the key type (usually ssh-dss or ssh-rsa), the key itself encoded as base64, and an optional comment.

If a key is followed by an annotation, the comment does not need to be wrapped in quotes. It has no effect on what the key does or how it works.

# an annotated key
ssh-rsa AAAAB3NzaC1yc2EAAA...zAiVaOFy5Lwc8Lo+Jk=  Fred @ Project FOOBAR

Keys can be preceded by a comma-separated list of options to affect what happens upon successful login. See the next section, Available key login options, for details.

# launch tinyfugue automatically
command="/usr/bin/tinyfugue" ssh-rsa AAAAB3NzaC1yc2EAAA...OFy5Lwc8Lo+Jk=

# set the PATH
environment="PATH=/bin:/usr/bin/:/opt/gtm/bin" ssh-rsa AAAAB3N...4Y2t1j=

The format of authorized_keys is described in the sshd(8) manual page. Old keys should be deleted from the file when no longer needed. The server can specify multiple locations for authorized_keys.

~/.ssh/authorized_principals

By default this file does not exist. If it is specified in sshd_config(5), it contains a list of names which can be used in place of the username when authorizing a certificate. This option is useful for role accounts, disjoint account namespaces and "user@realm"-style naming policies in certificates. Principals can also be specified in authorized_keys.

~/.ssh/environment

If the server is configured to accept user-supplied, automatic changes to environment variables as part of the login process, then these changes can be set in this file.

If the server, the environment file and an authorization key all try to change the same variable, the file environment takes precedence over what a key might contain. Either one will override any environment variables that might have been passed by ssh(1) using SendEnv. See also the AcceptEnv and PermitUserEnvironment directives in the manual page for sshd_config(5).

Authentication keys stored in authorized_keys can also be used to set variables.

~/.ssh/rc

This is a script which is executed by sh(1) just before the user's shell or command is started. It is not run if ForceCommand is used. The script is run after reading the environment variables. The corresponding global file, /etc/ssh/sshrc, is not run if the user's rc script exists.

Legacy Files

~/.rhosts

.rhosts is a legacy from rsh containing a local list of trusted host-user pairs that are allowed to log in. Login requests matching an entry are granted access.

See also the global list of trusted host-user pairs, /etc/hosts.equiv

rhosts can be used as part of host-based authentication. Otherwise it is recommended not to use rhosts for authentication, there are a lot of ways to misconfigure the rhosts file.

Available key login options

The login options available for use in the local user authorized keys file might be overridden or blocked by the server's own settings.

cert-authority

Specifies that the listed key is a certification authority (CA) trusted to validate signed certificates for user authentication. Certificates may encode access restrictions similar to key options. If both certificate restrictions and key restrictions are present, then the most restrictive union of the two is applied.

command="program"

Specifies a program, with options, that is executed when this key is used for authentication.

The program is run on a PTY if the client requests it, otherwise the default is to run without a TTY. The default, running without a TTY, provides an 8-bit clean channel. If the default has been changed, specify no-pty to get an 8-bit clean channel.

no-pty,command="" ssh-rsa AAAAB3NzaC1yc2EAAA...OFy5Lwc8Lo+Jk=

Quotes provided in the program's options must be escaped using a backslash. ('\')

command="sh -c \"mysqldump db1 -u fred1 -p\"" ssh-rsa AAAAB3NzaC1yc...Lwc8OFy5Lo+kU=

This option applies to execution of the shell, another program or subsystem. Thus any other program specified by the user is ignored, but the program originally specified by the client remains available as the environment variable SSH_ORIGINAL_COMMAND.

This way of forcing a program is useful to restrict a key to a single, specific operation, such as a remote backup. However, TCP and X11 forwarding are still allowed unless explicitly disabled elsewhere.

environment="NAME=value"

Sets the value of an environment variable when this key is used to log in. It overrides default values of the variable, if it exists. This option can be repeated to set multiple variables. This option is only allowed if the PermitUserEnvironment option is set. The default is disabled, and this option becomes disabled automatically when UseLogin is enabled.

from="pattern-list"

The canonical name of the remote host or its IP address required in addition to the key. Addresses and hostnames can be listed using a comma-separated list of patterns, see PATTERNS in ssh_config(5) for more information on patterns, or the CIDR address/masklen notation.

no-agent-forwarding

Forbids authentication agent forwarding when this key is used for authentication.

no-port-forwarding

Forbids TCP forwarding and any port forward requests by the client will return an error when this key is used for authentication.

no-pty

TTY allocation is prohibited and any request to allocate a PTY will fail.

no-user-rc

Use the no-user-rc option in authorized_keys to disable execution of ~/.ssh/rc

no-X11-forwarding

Prevents X11 forwarding when this key is used for authentication, and requests to forward X11 will return an error.

permitopen="host:port"

Limits local port forwarding (ssh -L) to only the specified host and port. IPv6 addresses can be specified with an alternative syntax: host/port. Multiple permitopen options may be used and must be separated by commas. No pattern matching is performed on the specified host names, they must be literal host names or IP addresses. Used in conjunction with agent-forwarding.

principals="name1[,name2,...]"

Specify a list of names that may be used in place of the username when authorizing a certificate trusted via the sshd_config(5) TrustedCAKeys option.

tunnel="n"

Select a specific tun(4) device on the server. Otherwise when a tunnel device is requested without this option the next available device will be used.

User-specific Keys

ssh(1) uses Ed25519, ECDSA, RSA, or DSA key pairs to verify hosts or authenticate users. Individual user accounts can maintain their own list of keys or certificates for authentication or to verify the identity of remote hosts.

Public Keys from other Hosts – ~/.ssh/known_hosts

known_hosts is for verifying the identity of other systems. It contains a list of public keys for all the hosts which the user has logged into. It can also include public keys for hosts that the user plans to log into but are not already in the system-wide list of known host keys. ssh(1) automatically adds keys to the user file, but they can be added manually as well. Usually when connecting to a host for the first time, ssh(1) adds the remote host's public key to the user's known_hosts file.

The format is one public key or certificate per unbroken line. Each line in contains a hostname, number of bits, exponent, and modulus. At the beginning of the line is either the host name or a hash representing the host name. An optional comment can follow at the end of the line. These can be preceded by an optional marker to indicate a certificate authority, if a certificate is used instead of a SSH key. These fields are separated by spaces. It is possible to use a comma-separated list of the hostname.

# keys with basic hostnames
anoncvs.fr.openbsd.org,93.184.34.123 ssh-rsa AAAA...njvPw==
anoncvs.eu.openbsd.org ssh-rsa AAAAB3Nz...cTqGvaDhgtAhw==

Non-standard ports can be indicated by enclosing the hostname with square brackets and followed by a colon and the port number.

# key with non-standard port
[ssh.example.org]:2222 ssh-rsa AAAAB3Nz...AKy2R2OE=
[127.0.0.2]:4922 ssh-rsa AAAAB4mV...1d6j=
[anga.funkfeuer.at]:2022,[78.41.115.130]:2022 ssh-rsa AAAAB...fgTHaojQ==

Hostname patterns can be created using "*" and "?" as wildcards and "!" to indicate negation.

Up to one optional marker per line is allowed. If present it must be either @cert-authority or @revoked. The former shows that the key is a certificate authority key, the latter flags the key as revoked and not acceptable for use.

See sshd(8) for further details of the format of this file and ssh-keygen(1) for managing the keys.

Manually Adding Public Keys to ~/.ssh/known_hosts

Manually adding public host keys to known_hosts is a matter of adding one unbroken line per key. How the key is obtained is not important, as long as it is complete, valid and guaranteed to be the real key and not a fake. ssh-keyscan(1) can fetch a key and ssh-keygen(1) can be used to show the fingerprint for verification. See examples in the cookbook chapter for methods of verification. The corresponding system-wide file is /etc/ssh/ssh_known_hosts

Local User's Public / Private Key Pairs

Users might have a variety of their own ECDSA, Ed25519, RSA and DSA keys around for various tasks and projects. The naming convention for keys is only a convention, but recommended to follow anyway. Public keys usually have the same name as the private key, but with .pub appended to the name.

Public Keys – ~/.ssh/id_dsa.pub ~/.ssh/id_ecdsa.pub ~/.ssh/id_ed25519.pub ~/.ssh/id_rsa.pub

Public keys are used for authentication. Public keys are not sensitive and are allowed to be readable by anyone, unlike the private keys, but don't need to be.

Private Keys – ~/.ssh/id_dsa ~/.ssh/id_ecdsa ~/.ssh/id_ed25519 ~/.ssh/id_rsa

These private keys are sensitive data and should be readable by the user but not accessible by others, mode 0600. The directory they are in should also have mode 0700 or 0500. If a private key file is accessible by others, ssh(1) will ignore it.

It is possible to specify a passphrase when generating the key which will be used to encrypt the sensitive part of this file using AES128. Until version 5.3, the cipher 3DES was used to encrypt the passphrase. Old keys using 3DES that are given new passphrases will use AES128 when they are modified.

Legacy Protocol Keys ~/.ssh/identity ~/.ssh/identity.pub

identity and identity.pub are for ssh protocol version 1, and thus deprecated.

User-specific Public Key Authentication

Users can authenticate using a private key stored on their system or fetched from a smartcard if the corresponding public key is stored on the system being connected to in authorized_keys. It is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.

The keys can be preceded by a comma-separated list of options. The whole key must be on a single, unbroken line. No spaces are permitted, except within double quotes. Any text after the key is considered a comment. See the section above on the authorized_keys file for more discussion. The authorized_keys file is a one-key-per line register of public RSA and DSA keys that can be used to log in as this user.

User-specified Host-based Authentication Configuration is also possible using the ~/.shosts, ~/.rhosts, ~/.ssh/environment, and ~/.ssh/rc files.

Managing Keys

When working with keys there are some basic, common sense actions that should take place to prevent problems.

Keys should use strong pass phrases. If autonomous logins are required, then the keys should be first loaded into an agent and used from there. See ssh-add(1) to get started there. It uses ssh-agent(1) which many systems have installed and some have running by default.

Keys should always be stored in protected locations, even on the client side. This is especially important for private keys. The private keys should not have read permissions for any user or group other than the owner. They should also be kept in a directory that is not accessible by anyone other than the owner in order to limit exposure.

Old and unused keys should be removed from the server. In particular, keys without a known, valid purpose should be removed and not allowed to accumulate. Using the comment field in the public key for annotation can help eliminate some of the confusion as to the purpose and owner when time has passed. Along those lines, keys should be rotated at intervals. In practice, rotation means generating new key pairs and removing the old ones. This gives a chance to remove old and unused keys. It is also an opportunity to review access needs, whether access is required and if so at what level.

Following the principle of least privilege can limit the chance for accidents or abuse. If a key is only needed to run a specific application or script, then its login options should be limited to just what is needed. See sshd(8) for the 'AUTHORIZED_KEYS FILE FORMAT' section on key login options. For root level access, it is important to remember to configure /etc/sudoers appropriately. Access there can be granted to a specific application and even limit that application to specific options.