SSH (Secure Shell) is normally used in accessing remote Linux/ Unix servers. To access a remote server requires one to declare a username, the hostname or IP address and a password or in most cases an ssh key is used to improve security. If you are dealing with only one remote server, it is easy to just run ssh syntax to access as you will easily remember the IP address or the hostname. However, when it comes to managing several remote servers, it becomes crucial to have ssh management tool that will save you from having to master all remote hosts and their access credentials. In this case, ssh config file comes to our rescue.
To be able to use ssh config file, we need to have ssh installed in your system. Most Linux servers come with ssh already installed. Its files are stored in ~/.ssh directory.
$ ls -l ~/.ssh/ total 16 -rw-------. 1 lorna lorna 2602 Jul 21 17:23 id_rsa -rw-r--r--. 1 lorna lorna 566 Jul 21 17:23 id_rsa.pub -rw-------. 1 lorna lorna 1505 Jul 21 17:24 known_hosts -rw-------. 1 lorna lorna 759 Jul 21 17:24 known_hosts.old
As you can see the folder contains a number of files as described below:
- id_rsa – stores the private key that for authentication a remote access using ssh keys
- id_rsa.pub – stores the public key
- known_hosts – Stores the public keys for all hosts that have been connected to.
In this directory, we can create an ssh config file that defines all the hosts, their hostnames, usernames and passwords, called profiles. There is no limit on the number of profiles you can create. This will enable us to easily manage ssh connectivity and to avoid the hustle having to remember all. In normal cases, I would connect to a remote Linux server using the below syntax
$ ssh [email protected] #Example $ ssh [email protected]
In the above case, we are passing the remote username and the IP address or server hostname. The default port for ssh is 22 which we don’t have to write. If we were using a different port, we would use the flag -p then port number as shown.
ssh [email protected] -p 20222
Creating ssh User Config File
Now, lets create a config file (if does not already exist) with a profile for the above connection and see the difference is connecting
You may need to set permissions for the config file
chmod 600 ~/.ssh/config
Add the below content to the file
$ vim ~/.ssh/config Host server1 Hostname 192.168.50.2 user root port 20222
- server1 is the remote server alias name used to ssh
- 192.168.50.2 is the IP address of the remote system
- root is the name of user account in the remote system we will login as.
- 20222 is the SSH service port configured on the remote system
Once you save the file, connect to server1 as below. You will then be prompted for password.
As you can see, we only have to remember the profile name. Ssh will look for the appropriate information in the config file and uses the defined parameters to access. You can add as many profiles as you can as below:
Host server1 Hostname 192.168.50.2 User root Port 20222 Host server2 Hostname 192.168.50.3 User user1 Port 20223 Host server3 Hostname 192.168.50.4 User user2 Port 20224
Passing a Common Parameter for all Hosts in SSH User File
If their a parameter that applies for all the hosts, you can pass it using * as shown below at the bottom of the file. In this case assuming that the remote login user for all the nodes is lorna. You can add all the default parameters that you are using.
Host * user lorna
Overriding ssh User Config File parameters
If you have declared a parameter in the config file and probably you want to use another parameter but not change the config settings, you can override using -o flag. For example, assume the remote server1 above has more that one login user and already you have declared one in the config file, to use the other user, the command is a below:
ssh -o "User=lorna" server1
Setting an Identity Key in SSH User Config File
If you are connecting to the remote servers using ssh keys instead of password, you can declare the part to the private key as shown below. Remember that you cannot save passwords in the config file and it is recommended to use ssh keys for remote access.
Host server1 Hostname 192.168.50.2 User root Port 20222 IdentityFile ~/.ssh/id_rsa
SSH User File Identities Only
While having defined the path to the identity keys as in the above configuration, ssh will still go through the available identities until it finds a matching one. This normally results in authentication failures which increases with the number of available identities. In order to to tell ssh to only go for the specified key, we use IdentitiesOnly parameter as shown below:
Host server1 Hostname 192.168.50.2 User root Port 20222 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes
UserKeychain SSH User File
If your ssh key authentication requires a password, you can use UserKeyChain to enable you to enter the password only the first time and it will be saved in macOS keychain or Gnome keyring.
Host server1 Hostname 192.168.50.2 User root Port 20222 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes UserKeychain yes
Setting User Known Hosts File
Known hosts file enables the client to authenticate the remote servers. It contains a list of keys for the remote servers that the user has connected to. This helps the user to ensure that they are not connecting to the wrong remote servers. Any time you make an ssh connection to a remote server, it shows you the public key and a proof of the corresponding private key.
The remote server fingerprints are added to know_hosts file, if you do not have them already, so that every time you access the same server, it is verified against the existing fingerprint. This is why if you re-install the remote server and try to ssh into it again, you will get a warning of unknown fingerprint since it might have changed in the process of re-installation. This checking is enforced using StrictHostKeyChecking parameter. You can also pass known hosts file path.
Host server1 Hostname 192.168.50.2 User root Port 20222 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes UserKnownHostsFile ~/.ssh/known_hosts StrictHostKeyChecking yes Host server2 Hostname 192.168.50.3 User root Port 2022 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes StrictHostKeyChecking no
SSH Connection Time Out and Server Alive Interval
If a user client connects to a remote server are remains inactive, they should connect again. The session only remains active when the user is working in the server. Connection time out defines how long a user remains inactive before the session times out. The parameter used to define connection time out is ServerAliveCountMax. ServerAliveInterval on the other hand defines the intervals in which ssh send packets to check server availability.
Host server1 Hostname 192.168.50.2 User root Port 20222 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes UserKnownHostsFile ~/.ssh/known_hosts #UserKnownHostsFile /dev/null StrictHostKeyChecking yes ServerAliveInterval 30 ServerAliveCountMax 720
SSH User Config File Log Level
LogLevel parameter defines the extend of details of ssh logs on the client side. Most of the commonly used values are ERROR, FATAL, QUIET, VERBOSE, INFO, DEBUG1 and so on
Host server1 Hostname 192.168.50.2 User root Port 20222 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes UserKnownHostsFile ~/.ssh/known_hosts StrictHostKeyChecking yes ServerAliveInterval 30 ServerAliveCountMax 720 LogLevel INFO
Including Another Config File in SSH User Config File
If you already have another config file and you wish to use in the current file, you should use Include clause, defining the path to the other config file, at the top of the current file as shown below. You should provide the absolute path of the file else ssh will assume they are in ~/.ssh
Include <path-to-file> #example Include ~/.ssh/config.d/myservers Host server1 Hostname 192.168.50.2 User root Port 20222 IdentityFile ~/.ssh/myid_rsa IdentitiesOnly yes UserKnownHostsFile /dev/null StrictHostKeyChecking yes ServerAliveInterval 30 ServerAliveCountMax 720 LogLevel INFO
In this guide, we have seen an easy way of managing remote ssh connections by using a ssh user config file. It is pretty convenient and you can set the various parameters for various remote hosts. I hope you have enjoyed the guide and all the very best in your configurations.