Telnet lacks a secure authentication method, and the transmission process uses TCP for plaintext transmission, which has great security risks. Only providing Telnet service is easy to cause DoS (Deny of Service), host IP address spoofing, routing spoofing and other malicious attacks.
with the attention paid to network security, the traditional way of Telnet and FTP transmitting passwords and data through plaintext has gradually become unacceptable. SSH (Secure Shell) is a network security protocol, which solves this problem by encrypting network data. It provides secure remote login and other secure network services in an insecure network environment.
SSH interacts with data through TCP, which builds a secure channel over TCP. In addition, SSH service supports standard port 22 and other service ports to prevent illegal attacks.
SSH protocol includes SSH1.0, SSH1.5, SSH2.0
SSH client function allows users to establish SSH connection with routers, UNIX hosts, etc. supporting SSH Server
SFTP (SSH File Transfer Protocol) is the abbreviation of SSH FTP, which is a Secure FTP. SFTP is built on the basis of SSH connection. Remote users can log in to the device safely, perform file management, file transfer and other operations, and provide a higher security guarantee for data transmission. At the same time, because the device provides the SFTP Client function, you can safely log in to the remote ssh server from the device and transfer the files securely.
steelnet is a secure telnet service based on SSH. Compared with Telnet, ssh server provides a secure service for network terminal access by authenticating the client and encrypting the data in two directions.
SCP (Secure Copy) is a secure protocol based on SSH, which authenticates the client and encrypts the data, so as to ensure the secure file transmission in the traditional non secure network environment.
SCP uses SSH for data transmission and user authentication to ensure the reliability and confidentiality of data transmission. The client can send (upload) files to the server, or request (download) files or directories from the server. By default, SCP runs on port 22 under the TCP protocol.
the standard listening port number of SSH protocol is 22. The attacker continuously accesses the standard port, resulting in waste of bandwidth and degradation of server performance, which makes other normal users unable to access. This is a DoS (denial of service) attack.
setting the ssh server's listening port number to another port, the attacker does not know the change of SSH listening port number, which can effectively prevent the attacker from consuming bandwidth and system resources by accessing the SSH service standard port. Normal users can reduce the possibility of DoS (denial of service) attacks by accessing SSH services on non-standard ports.
only legitimate users can establish Socket connection by using non-standard listening port set by ssh server, and conduct version number negotiation, algorithm negotiation, session key generation, authentication, session request, session stage and other processes of SSH protocol.
SSH provides secure remote access over an insecure network by:
support RSA (resist Shamir Adleman algorithm asymmetric encryption algorithm) / DSA (digital signature algorithm) / ECC (Elliptic Curves Cryptography elliptic curve encryption) public key verification method, according to the encryption principle of asymmetric encryption system, through generating public key and private key, realize the safe exchange of key, and finally realize the whole process of safe session.
it supports certificate verification. The client performs server-side verification through certificate signature to effectively prevent man in the middle attack.
support Data Encryption Standard (DES), 3DES, AES (Advanced Encryption Standard).
when SSH client communicates with server, the transmitted data shall be encrypted, including user name and password, to effectively prevent password eavesdropping.
support SM2 elliptic curve cryptography algorithm. Like RSA algorithm, SM2 algorithm belongs to the same asymmetric cryptography algorithm system. It is an asymmetric algorithm based on ECC (Elliptic Curves Cryptography) algorithm. Different from RSA algorithm
RSA algorithm is a factorization algorithm based on large numbers, which leads to the increasing length of RSA algorithm's key. But the long key brings some problems, such as slow operation speed, inconvenient key storage and management. ECC algorithm is based on discrete logarithm, which is difficult to crack and has higher security. Compared with RSA algorithm, ECC algorithm can greatly reduce the length of key under the same security conditions. Compared with RSA, ECC can achieve stronger encryption strength by using shorter key length. At the same time, because the key length is relatively short, the encryption speed is relatively fast. All in all, ECC ECC has the following advantages:
- With the same security, the key length of ECC algorithm is shorter than that of RSA algorithm.
- The calculation is small and the processing speed is fast.
- Small storage space.
- Low bandwidth requirements.
in order to ensure better security, it is recommended not to use RSA algorithm with DES/3DES/RSA less than 2048 bits as SSH user authentication and data encryption method, and more secure ECC authentication algorithm is recommended
ACLS are access control lists. Through ACL, the SSH type user interface is used to restrict the incoming and outgoing permissions, to prevent some users with illegal addresses from TCP connection and SSH negotiation, so as to improve the security of ssh server.
the main difference between SSH and telnet, ftp and other protocols is security. This leads to the next question: how to achieve data security? The first idea is to encrypt the data. There are two main encryption methods:
symmetric encryption (also known as secret key encryption)
Asymmetric encryption (also known as public key encryption)
Symmetric encryption refers to the use of the same set of secret keys for encryption and decryption
Symmetric encryption has high encryption strength and is hard to crack. But in the process of practical application, we have to face a difficult problem: how to keep the key safely? Especially considering the large number of Client side, it is difficult to ensure that the key is not leaked. Once a Client's key is stolen, the security of the whole system will no longer exist.
Asymmetric encryption came into being. Asymmetric encryption has two keys: "public key" and "private key"
The characteristics of two keys: the ciphertext encrypted by the public key can only be decrypted by the corresponding private key. It is very unlikely to infer the private key through the public key.
Login process using asymmetric encryption scheme
the remote Server receives the login request from the Client user TopGun, and the Server sends its public key to the user.
The Client uses this public key to encrypt the password. The Client sends the encrypted password to the Server.
the remote Server decrypts the login password with its own private key, and then verifies its validity. If the result is verified, give the corresponding response to the Client.
the private key is unique to the Server, which ensures that even if the Client's login information is stolen in the network transmission process, there is no private key to decrypt, ensuring the security of data, which makes full use of the characteristics of asymmetric encryption.
Is it safe?
There will be a problem in the above process: how can the Client ensure that the public key received is the one of the target Server? If an attacker intercepts the Client's login request halfway and sends its own public key to it, the Client encrypts the data with the attacker's public key. After receiving the encrypted information, the attacker decrypts it with his private key, so he steals the Client's login information? This is the so-called man in the middle attack
How to solve this problem in SSH?
From the above description, we can see that the problem is how to authenticate the public key of the Server? In https, CA can be used for notarization. However, SSH's publish key and private key are generated by themselves and cannot be notarized. The public key can only be confirmed by the Client itself. Generally, when logging in for the first time, the system will display the following prompt message:
The above information says that the authenticity of the host cannot be confirmed, but its public key fingerprint is known. Do you want to continue connecting?
[~client001] stelnet 10.1.1.1 Please input the username:client001 Trying 10.1.1.1 ... Press CTRL+K to abort Connected to 10.1.1.1 ... The server is not authenticated. Continue to access it?(Y/N):y //The server is not authenticated. Continue to visit it Save the server's public key?(Y/N):y //Save the public key of the server
The reason why fingerprint is used instead of key is that the key is too long (the public key generated by RSA algorithm has 1024 bits), which is difficult to compare directly. Therefore, hash the public key to generate a 128 bit fingerprint, which is convenient for comparison.
If you enter yes, the following message appears:
The server's public key will be saved with the name 172.16.1.1. Please wait... Feb 8 2020 11:34:46-08:00 R2 %%01SSH/4/SAVE_PUBLICKEY(l):When deciding whether to save the server's public key 172.16.1.1, the user chose Y. [R2] Enter password: //Input password
In the login process described above, it can be found that each login requires a password, which is very troublesome. SSH provides another way to log in without entering a password: public key login.
the Client stores its public key on the Server
after receiving the Client's connection request, the Server generates a random number R, encrypts the random number with the Client's public key to get pubKey ®, and then sends the encrypted information to the Client
the Client decrypts the random number r through the private key, and then generates Digest 1 by MD5 for the random number R and the SessionKey of this session, and sends it to the Server
the Server will also use the same digest algorithm for R and SessionKey to generate Digest2
the Server will finally compare Digest1 and Digest2 to complete the authentication process
Configuration examples of logging in to other devices through stilnet (RSA authentication mode and password authentication mode)
an example of logging in to other device configurations through stilnet. In this example, the stelnet client is connected to the SSH server by generating local key pair on the stelnet client and SSH server, generating RSA public key on the SSH server, and binding the RSA public key for the user.
configure two login users, client001 and client002, to log in to SSH server in password mode and RSA mode respectively.
- Configure the users client001 and client002 on the SSH server, and log in to the SSH server with different authentication methods.
- The local key pair is generated in the client client002 and ssh server of the STelnet respectively, and the RSA public key of the SSH client is bound to the client client002, so that the client can be verified when logging in the server.
- SSH server side STelnet service enable.
- The service mode of SSH users client001 and client002 is set to STelnet.
- Enable SSH client authentication for the first time.
- Users client001 and client002 log in to SSH server in the form of stilnet.
SSH users mainly have Password, RSA, Password RSA, ECC, Password ECC or all authentication methods:
if the authentication mode of SSH user is password, password RSA and password ECC, the local user with the same name must be configured.
if the authentication mode of SSH user is RSA, password RSA, ECC, password ECC and all, the server shall save the RSA or ECC public key of SSH client
Generate local key pair on server side
<HUAWEI> system-view [~HUAWEI] sysname SSH Server [*HUAWEI] commit [~SSH Server] rsa local-key-pair create //Create key pair The key name will be: client002_Host The range of public key size is (2048 ~ 2048). NOTE: Key pair generation will take a short while. [*SSH Server] commit
Creating SSH users on the server side
Configure the VTY user interface.
[*SSH Server] user-interface vty 0 4 [*SSH Server-ui-vty0-4] authentication-mode aaa [*SSH Server-ui-vty0-4] protocol inbound ssh [*SSH Server-ui-vty0-4] user privilege level 3 [*SSH Server-ui-vty0-4] commit [~SSH Server-ui-vty0-4] quit
Create SSH user Client001.
Create a new SSH user whose user name is Client001, and the authentication method is password.
[~SSH Server] ssh user client001 [*SSH Server] ssh user client001 authentication-type password [*SSH Server] commit
Configure the password for SSH user Client001 as hello-huawei 123.
[~SSH Server] aaa [*SSH Server-aaa] local-user client001 password cipher Hello-huawei123 [*SSH Server-aaa] local-user client001 service-type ssh [*SSH Server-aaa] commit [~SSH Server-aaa] quit
Create SSH user Client002.
Create a new SSH user whose user name is Client002, and the authentication method is RSA.
[~SSH Server] ssh user client002 [*SSH Server] ssh user client002 authentication-type rsa [*SSH Server] ssh authorization-type default root [*SSH Server] commit
Configure server RSA public key
Client Client002 generates the client's local key pair
<HUAWEI> system-view [~HUAWEI] sysname client002 [*HUAWEI] commit [~client002] rsa local-key-pair create The key name will be: client002_Host The range of public key size is (2048 ~ 2048). NOTE: Key pair generation will take a short while. [*client002] commit
View the generated RSA public key on the client.
[~client002] display rsa local-key-pair public ======================Host Key========================== Time of Key pair created : 13:22:1 2010/10/25 Key Name : client002_Host Key Type : RSA Encryption Key ======================================================== Key Code: 308188 028180 B21315DD 859AD7E4 A6D0D9B8 121F23F0 006BB1BB A443130F 7CDB95D8 4A4AE2F3 D94A73D7 36FDFD5F 411B8B73 3CDD494A 236F35AB 9BBFE19A 7336150B 40A35DE6 2C6A82D7 5C5F2C36 67FBC275 2DF7E4C5 1987178B 8C364D57 DD0AA24A A0C2F87F 474C7931 A9F7E8FE E0D5A1B5 092F7112 660BD153 7FB7D5B2 171896FB 1FFC38CD 0203 010001 Host Public Key for PEM format Code: ---- BEGIN SSH2 PUBLIC KEY ---- AAAAB3NzaC1yc2EAAAADAQABAAAAgQCyExXdhZrX5KbQ2bgSHyPwAGuxu6RDEw98 25XYSkri89lKc9c2/f1fQRuLczzdSUojbzWrm7/hmnM2FQtAo13mLGqC11xfLDZn +8J1LffkxRmHF4uMNk1X3QqiSqDC+H9HTHkxqffo/uDVobUJL3ESZgvRU3+31bIX GJb7H/w4zQ== ---- END SSH2 PUBLIC KEY ---- Public key code for pasting into OpenSSH authorized_keys file: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCyExXdhZrX5KbQ2bgSHyPwAGuxu6RDEw9825XYSkri 89lKc9c2/f1fQRuLczzdSUojbzWrm7/hmnM2FQtAo13mLGqC11xfLDZn+8J1LffkxRmHF4uMNk1X3Qqi SqDC+H9HTHkxqffo/uDVobUJL3ESZgvRU3+31bIXGJb7H/w4zQ== rsa-key Host Public key for SSH1 format code: 1024 65537 125048203250833642388841080101906750228075076456213955541037945628567 57310398880086451511608221218821171562865637463140847157102422109476944363593619 24637760514734544191988044752471924402237145321162849626052751701862381759745461 33321165741031171160914926309797395278974490949461701171569544048167828558985421 ======================Server Key======================== Time of Key pair created : 13:22:1 2010/10/25 Key Name : client002_Server Key Type : RSA Encryption Key ======================================================== Key Code: 3067 0260 BDCEC48F 1EDA55AF 80C71881 CF22D6A4 02682F2F E50035C8 E1539F1F 9EB3FCAC 2BFEF147 EEF59F23 7270C3DD 22135C16 AAC236DE EFBF9865 E50D8D26 B7651BCB 6D87BC2B 96559C38 04FC034B 54CFE7B3 2B1BBA18 A96FFC29 EF70069D DD1EE053 0203 010001
Pass the RSA public key generated on the client to the server.
[~SSH Server] rsa peer-public-key rsakey001 Enter "RSA public key" view, return system view with "peer-public-key end". [*SSH Server-rsa-public-key] public-key-code begin Enter "RSA key code" view, return last view with "public-key-code end". [*SSH Server-rsa-public-key-rsa-key-code] 308188 [*SSH Server-rsa-public-key-rsa-key-code] 028180 [*SSH Server-rsa-public-key-rsa-key-code] B21315DD 859AD7E4 A6D0D9B8 121F23F0 006BB1BB [*SSH Server-rsa-public-key-rsa-key-code] A443130F 7CDB95D8 4A4AE2F3 D94A73D7 36FDFD5F [*SSH Server-rsa-public-key-rsa-key-code] 411B8B73 3CDD494A 236F35AB 9BBFE19A 7336150B [*SSH Server-rsa-public-key-rsa-key-code] 40A35DE6 2C6A82D7 5C5F2C36 67FBC275 2DF7E4C5 [*SSH Server-rsa-public-key-rsa-key-code] 1987178B 8C364D57 DD0AA24A A0C2F87F 474C7931 [*SSH Server-rsa-public-key-rsa-key-code] A9F7E8FE E0D5A1B5 092F7112 660BD153 7FB7D5B2 [*SSH Server-rsa-public-key-rsa-key-code] 171896FB 1FFC38CD [*SSH Server-rsa-public-key-rsa-key-code] 0203 [*SSH Server-rsa-public-key-rsa-key-code] 010001 [*SSH Server-rsa-public-key-rsa-key-code] public-key-code end [*SSH Server-rsa-public-key] peer-public-key end [*SSH Server] commit
Bind the RSA public key of SSH client for SSH user Client002.
[~SSH Server] ssh user client002 assign rsa-key RsaKey001 [*SSH Server] commit
SSH server-side STelnet service enable
Enable the STelnet service function.
[~SSH Server] stelnet server enable [*SSH Server] commit
Connection between the client and SSH server
For the first login, you need to enable the SSH client to authenticate for the first time.
Enable client Client001 to authenticate for the first time.
<HUAWEI> system-view [~HUAWEI] sysname client001 [*HUAWEI] commit [~client001] ssh client first-time enable [*client001] commit
after enabling the SSH client's first authentication function, when the stilnet client logs in to the ssh server for the first time, it does not check the validity of the RSA, DSA or ECC public key of the ssh server. After login, the client will automatically save the RSA, DSA or ECC public key for authentication at the next login. If the SSH client is not enabled to log in for the first time, when the STelnet client logs in to the ssh server for the first time, the login server will fail due to the failure of RSA, DSA or ECC public key validity check for the ssh server
Enable client Client002 first authentication function
[~client002] ssh client first-time enable [*client002] commit STelnet Client Client001 use password Authentication mode connection SSH Server, enter the configured user name and password. [~client001] stelnet 10.1.1.1 Please input the username:client001 Trying 10.1.1.1 ... Press CTRL+K to abort Connected to 10.1.1.1 ... The server is not authenticated. Continue to access it?(Y/N):y Save the server's public key?(Y/N):y The server's public key will be saved with the name 10.1.1.1. Please wait... Enter password:
Enter the password Hello Huawei 123, and the login success information is as follows:
Info: The max number of VTY users is 20, and the number of current VTY users on line is 6. The current login time is 2011-01-06 11:42:42. <SSH Server>
The client002 of the stylenet connects to the SSH server with RSA authentication.
[~client002] stelnet 10.1.1.1 Please input the username: client002 Trying 10.1.1.1 ... Press CTRL+K to abort Connected to 10.1.1.1 ... The server is not authenticated. Continue to access it?(Y/N):y Save the server's public key?(Y/N):y The server's public key will be saved with the name 10.1.1.1. Please wait... Info: The max number of VTY users is 20, and the number of current VTY users on line is 6. The current login time is 2011-01-06 11:42:42. <SSH Server>
Verify configuration results
After the configuration is completed, execute the display ssh server status command and display ssh server session on the SSH server side. You can see that the stilnet service has been enabled, and the stilnet client has successfully connected to the SSH server.
View SSH status information
[~SSH Server] display ssh server status SSH Version : 2.0 SSH authentication timeout (Seconds) : 60 SSH authentication retries (Times) : 3 SSH server key generating interval (Hours) : 0 SSH version 1.x compatibility : Enable SSH server keepalive : Disable SFTP IPv4 server : Disable SFTP IPv6 server : Disable STELNET IPv4 server : Enable STELNET IPv6 server : Enable SNETCONF IPv4 server : Enable SNETCONF IPv6 server : Enable SNETCONF IPv4 server port(830) : Disable SNETCONF IPv6 server port(830) : Disable SCP IPv4 server : Enable SCP IPv6 server : Enable SSH IPv4 server port : 22 SSH IPv6 server port : 22 SSH server source address : 10.1.1.1 SSH ipv6 server source address : 0::0 SSH ipv6 server source vpnName : ACL name : ACL number : ACL6 name : ACL6 number : SSH server ip-block : Enable
View the SSH server connection information.
[~SSH Server] display ssh server session -------------------------------------------------------------------------------- Session : 1 Conn : SFTP 0 Version : 2.0 State : Started Username : user1 Retry : 1 CTOS Cipher : aes256-ctr STOC Cipher : aes256-ctr CTOS Hmac : hmac-sha2-256 STOC Hmac : hmac-sha2-256 CTOS Compress : none STOC Compress : none Kex : diffie-hellman-group14-sha1 Public Key : ECC Service Type : stelnet Authentication Type : password Connection Port Number : 22 Idle Time : 00:00:49 Total Packet Number : 90 Packet Number after Rekey : 90 Total Data(MB) : 0 Data after Rekey(MB) : 0 Time after Session Established(Minute) : 0 Time after Rekey(Minute) : 0 --------------------------------------------------------------------------------
View SSH user information.
[~SSH Server] display ssh user-information ---------------------------------------------------- Username : client001 Authentication-type : password User-public-key-name : - User-public-key-type : - Sftp-directory : - Service-type : stelnet Username : client002 Authentication-type : rsa User-public-key-name : rsakey001 User-public-key-type : - Sftp-directory : - Service-type : stelnet ---------------------------------------------------- word User-public-key-name : - User-public-key-type : - Sftp-directory : - Service-type : stelnet Username : client002 Authentication-type : rsa User-public-key-name : rsakey001 User-public-key-type : - Sftp-directory : - Service-type : stelnet ----------------------------------------------------