Objective
SSH is the most common way to connect to a remote host, although the basic operation of connecting to a delayed host is straightforward, but when you start using a large number of remote systems, this becomes cumbersome and complex task.
Fortunately, OpenSSH allows you to provide custom client connection options. These options can be stored in a configuration file that can be used to define the configuration of each host. This helps keep the connection options for each host better independent and organized, and also lets you avoid writing cumbersome options on the command line when you need to connect.
In this article, we will cover the basics of the SSH client configuration file, understand how SSH interprets the configuration file, but will not describe the meaning and use of the SSH specific options.
The structure and interpretation algorithm of SSH file
Each user of the local system can maintain a client's SSH profile, which can include parameters that you use at the command line for SSH, or store common connection options and automatically process when connected. You can use SSH on the command to specify flag to override the options in the configuration file.
Location of the SSH client configuration file
The file name of the configuration file is config
located under the. SSH folder in the user's home directory.
~/.ssh/config
Typically, the file is not created by default, so you might want to create it yourself.
Structure of the configuration file
The configuration files are organized by host, and each host definition item defines the connection options for the matching host. Wildcards can be used, in order to have a larger range of options.
The configuration file looks like this:
Host firsthost SSH_OPTIONS_1 custom_value SSH_OPTIONS_2 custom_value SSH_OPTIONS_3 custom_valueHost secondhost ANOTHER_OPTION custom_valueHost *host ANOTHER_OPTION custom_valueHost * CHANGE_DEFAULT custom_value
Interpreting algorithms
Only by understanding how SSH interprets the configuration file can you write a reasonable configuration file.
The SSH mission makes the hostname given in the row match the host name defined in the configuration file. It does this from the top of the file, so the order is important.
It is now a good time to point out that the schema in the host definition does not have to match the actual host you are connecting to. In fact, you can use these definitions to set aliases for hosts in place of the actual host names.
Look at an example:
Host dev1 HostName dev1.example.com User tom
Now to connect to it [email protected]
, you can enter the following command at the command line:
ssh dev1
With this in mind, we will now continue to discuss how SSH applies each configuration selected in the top down process. It starts at the top and checks to see if each host definition matches the one given on the command line. In the previous example, check the DEV1.
When the first matching host definition is found, each associated SSH option is applied to the incoming connection (for the sake of discussion below, we call this connection " connection a"). Nonetheless, the explanation is not over.
SSH continues to look down in the file to check for other matching Host definitions. If there is another host definition match, SSH will consider the configuration options under that host definition. If the new configuration option has an option that is not used when connecting a , add these options to connection a .
To summarize, SSH interprets each host definition that matches the hostname given on the command line in order. In this process, SSH always uses the first value given for each option. There is no way to overwrite the value given by the Host definition that was previously matched.
So it seems that a simple principle of writing a configuration file is. The more granular the Host definition, the more it is written on top. The generic Host definition should be written down below.
Look at an example:
Host firsthost SSH_OPTIONS_1 custom_value1 SSH_OPTIONS_2 custom_value2 SSH_OPTIONS_3 custom_value3Host secondhost ANOTHER_OPTION custom_value4Host *host ANOTHER_OPTION custom_value5Host * CHANGE_DEFAULT custom_value6
If so, the options used by SSH are,,,,,,,,,, and ssh firsthost
SSH_OPTIONS_1
SSH_OPTIONS_2
SSH_OPTIONS_3
ANOTHER_OPTION
CHANGE_DEFAULT
custom_value1
custom_value2
custom_value3
custom_value5
custom_value6
.
If ssh secondhost
so, the options used by SSH are, and the values used are, ANOTHER_OPTION
CHANGE_DEFAULT
respectively custom_value4
custom_value6
.
Basic connection Options
This section is directly explained by an example: To connect a user named Apollo to the name example.com, the host runs the SSH daemon on port 4567.
In general, we will write at the command line:
ssh -p 4567 [email protected]
If you use the full name of the option, this is the case:
ssh -o "User=apollo" -o "Port=4567" -o "HostName=example.com"
We can put the option that starts with uppercase in the second way into the configuration file. A man ssh_config
complete list of available options can be obtained.
Now, use the configuration file to write the above example:
Host home HostName example.com User apollo Port 4567
For each option, this is also possible (in port, for example):
Port = 4567Port=4567
Configure options for sharing
Continuing on to the last part of the example, I have two hosts, separate home and work, on both hosts, my user name is Apollo. Simply, modify the configuration file directly:
Host home HostName example.com User apollo Port 4567Host work HostName company.com User apollo
There's no problem with writing this, but we can put the User up:
Host home HostName example.com Port 4567Host work HostName company.comHost * User apollo
Very good, but the new problem comes, you have a good friend Mars, there is a host sharing for you, but he likes to read your name backwards, then what to do?
Host home HostName example.com Port 4567Host work HostName company.comHost friend-Mars HostName abc.com User ollopaHost * User apollo
With the passage of time, more and more friends, they have a host for you to use, and all like to put your name upside down, what to do?
Host home HostName example.com Port 4567Host work HostName company.comHost friend-Mars HostName mars.comHost friend-Mercury HostName mercury.comHost friend-Jupiter HostName jupiter.comHost friend-* User ollopaHost * User apollo
The original text is the Configure Custom Connection Options for your SSH Client, this article on the basis of a slight modification.
Article Link: https://www.cnblogs.com/xjshi/p/9146296.html
Reprint Please specify residence
Interpretation algorithms and configuration principles for. ssh/config Files