1. Introduction
SSH (Secure Shell, Secure Shell) is a network security protocol that implements services such as secure access and file transfer through encryption and authentication mechanisms. Traditional remote login or file transfer methods, such as Telnet and FTP, use clear text to transfer data, which has many security risks. With people's emphasis on network security, these methods have gradually become unacceptable. The SSH protocol provides secure login and other secure network services in an insecure network environment by encrypting and verifying network data. As a secure alternative to Telnet and other insecure remote shell protocols, the SSH protocol has been widely used all over the world, and most devices support the SSH function.
Second, the default port
- When SSH is applied to STelnet, SFTP and SCP, the default SSH port used is 22.
- When SSH is applied to NETCONF, the SSH port can be specified as 22 or 830.
- The SSH port supports modification. After the change, all current connections will be disconnected, and the SSH server will start listening to the new port.
3. Why use SSH
- SSH is a protocol standard whose purpose is to implement secure remote login and other secure network services.
- The main difference between SSH and telnet, ftp and other protocols is security
Common Encryption Methods
- Symmetric encryption (also known as secret key encryption), refers to encryption and decryption using the same set of secret keys
Client
Server
1. The encryption strength of symmetric encryption is high, and it is difficult to crack.
2. But in the actual application process, we have to face a difficult problem: how to save the key safely? Especially considering the huge number of clients, it is difficult to guarantee that the key will not be leaked.
3. Once a client key is stolen, the security of the entire system will no longer exist.
- Asymmetric encryption, asymmetric encryption has two keys: "public key" and "private key"
The characteristics of the two keys: the ciphertext encrypted by the public key can only be decrypted by the corresponding private key. The possibility of inferring the private key from the public key is very small.
login process
1. The remote server receives the login request from the client user TopGun, and the server sends its own public key to the user.
2. Client uses this public key to encrypt the password.
3. The client sends the encrypted password to the server.
4. The remote server uses its own private key to decrypt the login password, and then verifies its legitimacy.
5. If the result of the verification is verified, a corresponding response is given to the Client.
The private key is unique to the server side, which ensures that even if the client's login information is stolen during network transmission, there is no private key to decrypt it, ensuring data security, which makes full use of the characteristics of asymmetric encryption.
But in the above process, how does the client ensure that the received public key belongs to the target server? If an attacker intercepts the Client's login request midway and sends it its own public key, the Client uses the attacker's public key to encrypt data. After receiving the encrypted information, the attacker decrypts it with his own private key. Doesn’t the attacker steal the Client’s login information? This is the so-called man-in-the-middle attack
on SSH encryption
- Password-based authentication
1. Confirm the public key by the client itself. Usually when you log in for the first time, the system will display the following prompt information
The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?
# 无法确认主机ssh-server.example.com（12.18.429.21）的真实性，不过知道它的公钥指纹，是否继续连接？
2. After entering yes
Warning: Permanently added 'ssh-server.example.com,12.18.429.21' (RSA) to the list of known hosts.
Password: (enter password)
# 该host已被确认，并被追加到文件known_hosts中，然后就需要输入密码，一般默认为空
- Authentication based on the public key
1. The client stores its own public key on the server and appends it to the file authorized_keys.
2. After receiving the client's connection request, the server will match the client's public key pubKey in authorized_keys, and generate a random number R, encrypt the random number with the client's public key to obtain pubKey®, and then send the encrypted
information Send to Client.
3. The client side decrypts with the private key to obtain the random number R, and then uses MD5 to generate a digest Digest1 for the random number R and the SessionKey of this session, and sends it to the server side.
4. The server will also use the same digest algorithm to generate Digest2 for R and SessionKey.
5. The server will finally compare whether Digest1 and Digest2 are the same, and complete the authentication process.
4. SSH practice
- The SSH server listens to the client's connection request on the specified port. After the client initiates a connection request to the server, the two parties establish a TCP connection.
$ ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/authorized_keys
ssh-keygen is a tool for generating keys.
-t: Specify the type of generated key (rsa, dsa, ecdsa, etc.)
-P: Specify passphrase to ensure the security of the private key
-f: Specify the file where the key is stored (the public key file is in the same directory as the private key by default, The difference is that the file name storing the public key needs to be suffixed with .pub)
1. id_rsa: save the private key
2. id_rsa.pub: save the public key
3. authorized_keys: save the authorized client public key
4. known_hosts: save the authenticated remote host ID, store the authenticated remote host host key, Each SSH Server has a secret, unique ID, called a host key.
login operation
# 以用户名user，登录远程主机host
$ ssh user@host
# 本地用户和远程用户相同，则用户名可省去
$ ssh host
# SSH默认端口22，可以用参数p修改端口
$ ssh -p 2017 user@host
Known_hosts plays a role. This file is mainly through the two-way authentication of Client and Server, so as to avoid man-in-the-middle attack. Every time the Client initiates a connection to the Server, not only the Server needs to verify the Client For legality, the client also needs to verify the identity of the server. The SSH client verifies the identity of the server through the host key in known_hosts.