Example of SSH public key authentication configuration in Linux

On two Linux hosts due to the needs of the environment, often to configure the two host between the password-free login, which will be used to key authentication, that is, the so-called public key authentication. Easy to understand, I'm here to specify two hosts for A and B. If a host wants to be password-free to log on to the B host, the host computer holds the private key, and the B host holds the public key. The two files generated by the Ssh-keygen command are: Public key file ~/.ssh/id_rsa.pub, private key file ~/.ssh/id_rsa. While the B host holds the public key, it needs to store the contents of the id_rsa.pub in the ~/.ssh/authorized_keys file, and guarantee the permission is 600.

SSH is made up of three main parts:

Transport layer Protocol [Ssh-trans]

Server authentication, confidentiality and integrity are provided. In addition, it also sometimes provides compression capabilities. Ssh-trans are typically run on TCP/IP connections and may also be used on other reliable data streams. Ssh-trans provides a strong encryption technology, password host authentication and integrity protection. The authentication in this protocol is based on the host, and the protocol does not perform user authentication. Higher-level user authentication protocols can be designed to be based on this agreement.

User authentication protocol [Ssh-userauth]

Used to provide client-side user authentication to the server. It runs above the Transport layer protocol Ssh-trans. When Ssh-userauth begins, it receives the session identifier from the low-level protocol (swap hash h from the first key exchange). The session identifier uniquely identifies this session and applies to the tag to prove ownership of the private key. Ssh-userauth also needs to know if low-level protocols provide confidentiality protection.

Connection Agreement [Ssh-connect]

Multiple encrypted tunnels are divided into logical channels. It runs on the user authentication protocol. It provides interactive logon sessions, remote command execution, forwarding TCP/IP connections, and forwarding X11 connections.

First, build and import key

A key is generated on a host

$ ssh-keygen-t RSA
$ ls
Id_rsa id_rsa.pub
Import key to remote B host and Modify permissions

Operation on a host
$ cat/root/.ssh/id_rsa.pub | SSH root@ remote server IP ' cat->> ~/.ssh/authorized_keys '
Operation on Host B
$ chmod ~/.ssh/authorized_keys
There is a simpler way, however, that you do not need to modify the permissions on the B host, but directly import the public key content to the remote host, using the Ssh-copy-id command, as follows:

$ ssh-copy-id-i/root/.ssh/id_rsa root@xxx,xxx,xxx,xxx

Second, configure Sshd_config

After the key is configured, you need to open key authentication in the Sshd_config file.

$ vim/etc/ssh/sshd_config
Pubkeyauthentication Yes//change the item to Yes
After the modification is complete, restart the SSH service reload configuration via/etc/init.d/sshd restart. If you want to disable password authentication, change the following:

$ vim/etc/ssh/sshd_config
Usepam Yes
For
Userpam No

More configuration parameters and their significance can be viewed through the man sshd_config.

Three, ssh_config and multiple private key configuration

Sshd_config is a global server-side configuration file (that is, the configuration of the SSHD service is enabled on the computer), and Ssh_config is a global client profile. For example, two of the lines in Ssh_config define the path of the default private key key for each user:

# Identityfile ~/.ssh/id_rsa
# Identityfile ~/.SSH/ID_DSA
If multiple private key files appear on multiple servers, how do I configure them on the client host? Append all to ~/.ssh/id_rsa (or ID_DSA)? After testing, this is not workable, only the first private key can be used, the back is not.

When multiple servers are available, there are two possible solutions.

1. On different hosts, the same public key is used, and the private keys of these machines are the same. The client only needs to configure this private key to log on to all hosts.

2. When different public keys are used on different hosts, there will be several different private keys. This requires that different private key files be specified for different hosts, which can be configured in Ssh_config (see the configuration sample for that file). Of course, in more cases, we will only make an emotional configuration of the user to use, the profile is ~/.ssh/config (the file does not exist, please create), the format is as follows:

Host xxxx
Identityfile private Key file name
Port Port number
User you log in to XXXX server account
Note: The configuration file here can also refer to the configuration in Ssh_config, and can be used to get more useful information through man ssh_config.

Host *
User www
Port 22
Checkhostip No
Compression Yes
Forwardagent Yes
Host 10.1.100.*
User Dev
Port 22
Identityfile ~/.ssh/dev.key

As the above configuration, by default we connect all the hosts (except for the 10.1.100.* of all hosts), the default user name is www, ssh 172.20.1.100 = ssh www@172.20.1.100-p 22. When we connect all the hosts under 10.1.100.*, the dev user is used by default, and the default private key is ~/.ssh/dev.key file. In the same vein, you can add more configurations.

Note: For security reasons, be sure to set the permissions for the ~/.ssh/config file and ~/.ssh/key file to 600.