SSH client config – Rememberall

In this post

The SSH client is capable of leveraging configured and runtime settings to influence its operation and behaviour. This may include creation and use of keys, host specific settings and enabling client capabilities. This is by no means intended to be a comprehensive guide of all things SSH config related, but merely a list of lessons learned in my journey with SSH so far.

SSH client config file

The below example lists some of the settings that can be defined in an SSH client config file. The file is typically located in ~/.ssh/config

GSSAPIAuthentication no

Host 192.168.100.230
        KexAlgorithms +diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Host 192.168.100.231
        KexAlgorithms +diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Host *
        AddKeysToAgent yes
        IdentityFile ~/.ssh/id_rsa

Host 192.168.100.232
        HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

Each Host stanza defines settings that are specific to that particular host.

KexAlgorithms

KexAlgorithms allows you to modify the key exchange algorithms that are proposed during negotiation. This might be necessary if you’re attempting to connect to a system that is using legacy algorithms. An example of this is demonstrated below:

ssh admin@192.168.100.230
Unable to negotiate with 192.168.100.230 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Defining KexAlgorithms for individual hosts allows you to limit vulnerable algorithms to specific hosts, rather than exposing your entire system to the relaxed settings.

HostKeyAlgorithms

HostKeyAlgorithms allows you to modify the public key algorithms presented to an SSH server to authenticate itself to an SSH client. You might need to modify the HostKeyAlgorithms if you encounter a situation similar to below:

ssh admin@192.168.100.232
no hostkey alg

The solution to this is to generate ECDSA host keys and apply them to the connection which is experiencing the issues:

ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -C '' -N ''
chmod 600 /etc/ssh/ssh_host_ecdsa_key
chmod 640 /etc/ssh/ssh_host_ecdsa_key.pub

With the associated HostKeyAlgorithms defined:

Host 192.168.100.232
        HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

Host *

Host * provides a per-user ability to apply common settings to all SSH connections. This is useful if you can’t (or don’t want to) apply settings system-wide.

AddKeysToAgent

AddKeysToAgent specifies whether keys should be automatically added to a running ssh-agent. If this option is set to yes and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add. If this option is set to ask, ssh will require confirmation using the SSH_ASKPASS program before adding a key. If this option is set to confirm, each use of the key must be confirmed, as if the -c option was specified to ssh-add. If this option is set to no, no keys are added to the agent. Alternately, this option may be specified as a time interval to specify the key’s lifetime in ssh-agent, after which it will automatically be removed. The argument must be no (the default), yes, confirm (optionally followed by a time interval), ask or a time interval.

IdentityFile

IdentityFile specifies a file from which the user’s DSA, ECDSA, authenticator-hosted ECDSA, Ed25519, authenticator-hosted Ed25519 or RSA authentication identity is read. You can also specify a public key file to use the corresponding private key that is loaded in ssh-agent when the private key file is not present locally. The default is ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa. Additionally, any identities represented by the authentication agent will be used for authentication unless IdentitiesOnly is set. If no certificates have been explicitly specified by CertificateFile, ssh will try to load certificate information from the filename obtained by appending -cert.pub to the path of a specified IdentityFile.

It is possible to have multiple identity files specified in configuration files; all these identities will be tried in sequence. Multiple IdentityFile directives will add to the list of identities tried (this behaviour differs from that of other configuration directives).

IdentityFile may be used in conjunction with IdentitiesOnly to select which identities in an agent are offered during authentication. IdentityFile may also be used in conjunction with CertificateFile in order to provide any certificate also needed for authentication with the identity.

GSSAPIAuthentication

GSSAPIAuthentication specifies whether user authentication based on GSSAPI is allowed. It may be useful to disable the GSSAPIAuthentication setting if you’re not using Kerberos. Having it enabled can sometimes slow the SSH handshake, negotiation and connection process while the GSS API mechanisms attempt to use DNS and rDNS to resolve the remote host’s hostname.