What Is SSH?
Secure Shell (SSH) is a network security protocol that uses encryption and authentication mechanisms to implement services such as secure access and file transfer. Traditional remote login and file transfer methods, such as Telnet and FTP, transmit data in cleartext, which is insecure. With the growing importance of cyber security, these methods are gradually becoming less accepted. SSH provides secure network services in an insecure network environment by encrypting and authenticating network data. As a secure alternative solution to Telnet and other insecure remote shell protocols, the SSH protocol has been widely used around the world, with most devices today supporting SSH.
Why Is SSH Needed?
In conventional Internet communications, data is transmitted in cleartext. Once the data is intercepted, it is completely exposed, which is highly insecure. SSH uses a client-server model to authenticate two parties and encrypt the data between them. It provides a secure transmission channel for operating network services securely over an unsecured network.
The most common scenarios for applying SSH are remote login and file transfer. Before SSH emerged, Telnet was widely used in remote login scenarios, facilitating remote management of network devices. FTP is a common file transfer protocol that is easy to operate and delivers high transmission efficiency. However, both Telnet and FTP have the same issue: data is transmitted in cleartext, bringing security risks. To address the security issues in Telnet and FTP applications, SSH uses methods such as encrypted data transmission and authentication strength improvement, whereby secure remote login and file transfer services are implemented.
Common SSH scenarios
How Does SSH Work?
SSH uses the client-server model. To establish a secure SSH channel, the two parties need to establish a TCP connection, negotiate the version number and algorithms to be used, and generate the same session key for subsequent symmetric encryption. After the user authentication is complete, the two parties can establish a session for data exchange. The SSH working process consists of the following phases:
SSH working process
Connection Setup
SSH uses a port for communication. Before an SSH connection is established, the SSH server listens to connection requests on a specified port. After an SSH client sends a connection request to the specified port of the SSH server, a TCP connection is established between the SSH client and the SSH server, which then communicate with each other through this port.
By default, the SSH server uses port 22. When SSH is applied to NETCONF, you can specify the default port number 22 or 830. The port number used by SSH can be changed to another available port on the device. After the change, all current connections are disconnected, and the SSH server starts to listen to the new port. Because the default SSH port number 22 is well-known, you are advised to change the SSH port number during key secure transmission.
Version Negotiation
SSH has two versions: SSH1.X (earlier than SSH2.0) and SSH2.0. Compared with SSH1.X, SSH2.0 has an extended structure, supports more authentication methods and key exchange methods, and improves service capabilities. The SSH server and client negotiate to determine the SSH version to be used with the following process:
1. The SSH server sends the supported SSH version information to the SSH client through the established connection.
2. After receiving the version information, the SSH client determines the version to be used based on the SSH version it supports and sends the version to the SSH server.
3. The SSH server checks whether it supports the version determined by the client; if so, the version negotiation is successful.
Algorithm Negotiation
SSH uses multiple types of algorithms, including the key exchange algorithm for generating session keys, symmetric encryption algorithm for data encryption, public key algorithm for digital signature and authentication, and HMAC algorithm for data integrity protection. The SSH server and client support multiple algorithms of each type, and therefore need to negotiate and determine the algorithm to be used in each type. The process is as follows:
1. The SSH server and client send their supported algorithms to each other.
2. The SSH server and client negotiate the algorithm to be used in each type. During the negotiation of each type of algorithm, the SSH server and client match the algorithm supported by both of them for use as the final algorithm. After algorithms for each type are successfully matched, the algorithm negotiation is complete. If no algorithms are matched for a type, the algorithm negotiation of this type fails. As a result, the algorithm negotiation between the SSH server and client fails and the SSH connection is torn down.
Key Exchange
The SSH server and client use a key exchange algorithm to dynamically generate a shared session key and session ID for establishing an encrypted channel. The session key is used to encrypt subsequent data for transmission, and the session ID is used to identify the related SSH connection during authentication. In this phase, the client will also complete server identity authentication. The process is that the server uses its private key to sign messages and the client uses the server public key to verify the signature.
The SSH server and client need to hold the same session key for subsequent symmetric encryption. To ensure the security of key exchange, SSH generates a session key using a secure method: the SSH server and client jointly generate a session key. To be specific, based on mathematical theories, key exchange without direct key transmission is implemented, so the key does not need to be transmitted through an insecure channel. The following figure shows the detailed process.
SSH key exchange
1. The SSH server generates prime numbers G and P, and the server's private key b, and calculates the server's public key y using the following formula: y = (G^b)%P.
2. The SSH server sends prime numbers G and P and the server's public key y to the SSH client.
3. The SSH client generates a private key a and calculates a client public key x using the following formula: x = (G^a)%P.
4. The SSH client sends the client public key x to the SSH server.
5. The SSH server calculates the symmetric key K using the formula K = (x^b)%P, and the SSH client calculates the symmetric key K using the formula K = (y^a)%P. The mathematical law ensures that the symmetric keys generated by the SSH server and client are the same.
User Authentication
The SSH client sends an authentication request to the SSH server, which then authenticates the SSH client. SSH supports the following authentication modes:
- Password authentication: The client sends the encrypted username and password to the server. The server decrypts the username and password, compares them with the locally stored username and password, and returns an authentication success or failure message to the client.
- Public key authentication: The client uses the username, public key, and public key algorithm to exchange data with the server for authentication.
- Password+public key authentication: The client can log in to the system only after being authenticated by the server using both password authentication and public key authentication.
- All: Either password authentication or public key authentication is required for the client.
Password authentication and key authentication are used as two basic SSH user authentication methods. The basic principle of password authentication is that the SSH client uses the symmetric key to encrypt the password, and the SSH server uses the symmetric key to decrypt the password and then verifies the password validity. This authentication mode is simple, and the user name and password are required for each login. Key authentication can implement password-free login with higher security. The basic principle is that the SSH client uses its private key to sign messages, and the server uses the client public key to verify the signature. This method is widely used and recommended.
Session Request
After the authentication succeeds, the SSH client sends a session request to the server, requesting the server to provide a certain type of service. That is, the SSH client requests to establish a session with the server, which then responds to the request from the client.
Session Interaction
After a session is established, the SSH server and client exchange data over the session. The data sent by the SSH server and client is encrypted and decrypted using the session key.
Common SSH Connection Tools: PuTTY and OpenSSH
SSH is a set of protocol standards. Therefore, SSH-based tools are required to connect SSH clients and SSH servers. To address this issue, PuTTY and OpenSSH are developed.
PuTTY is a common SSH connection tool used for free on the Windows operating system. It is typically used to remotely log in to a device using SSH. The latest version can be downloaded from the official PuTTY website.
OpenSSH is an open-source implementation of the SSH protocol and can run on the Unix operating system. The latest version can be downloaded from the official OpenSSH website. The Windows 10 operating system comes with the OpenSSH client and server software. You can click Settings, and select Apps > Apps & Features. At the top of the page, select Add a feature, and click OpenSSH Client and OpenSSH Server to install them.
Differences Between SSH and SSL
Both SSH and SSL are network security protocols. They use encryption and authentication to improve the security of data transmitted between two devices. However, the effective modes and service targets of SSH and SSL are different.
To be specific, SSH creates a secure tunnel between two devices so that they can securely send commands and transmit data. For example, if a client remotely logs in to a server through SSH, the client can remotely manage the server and run required commands on the server.
By contrast, SSL uses SSL certificates to secure the data transmission between two devices, instead of running commands. For example, if you access a server where an SSL certificate is installed and HTTPS is enabled via a browser, data can be securely transmitted between the browser and server.
SSH is like a car. We cannot see what is loaded in this car. SSL is like a closed container. We can transport it by different means, but we cannot see what is contained in the container.
- Author： Gu Peiyue, Gao Tingting
- Updated on： 2024-03-12
- Views： 34190
- Average rating：
