What is SSH (Secure shell protocol)?

SSH stands for Secure Shell which is a security protocol based on the application layer. We use the SSH to securely access the remote servers and Desktops to execute various commands. In short, we can control the complete system remotely, if we have login information and SSH server access. Because The Secure Shell (SSH) is a cryptographic network protocol designed to replace the Telnet and access the remote system even on the unsecured remote shell by encrypting data before sending.

The port 22 used as a standard port for SSH. It primarily designed for UNIX like systems and can also work on Windows systems by installing OpenSSH.

Traditional web services such as FTP, pop, and telnet are inherently insecure because they transmit passwords and data in clear text over the network, making it easy for people with ulterior motives to intercept those passwords and data.

Moreover, the security verification methods of these service programs have their weaknesses, that is, they are vulnerable to attack by a man-in-the-middle. The so-called “middleman” attack method means that the “middleman” pretends to be a real server to receive the data you pass to the server, and then pretends that you pass the data to the real server. After the data transfer between the server and you have been changed by the “middle man”, there will be serious problems.

By using SSH, you can encrypt all transmitted data, so that the “man in the middle” attack is impossible, and it can also prevent DNS spoofing and IP spoofing. Using SSH, there is an additional benefit is that data transmission is compressed, so you can speed up the transfer speed. SSH has many functions, it can replace Telnet, and can provide a secure “channel” for FTP, PoP, and even PPP

On this Page show

SSH consists mainly of three parts:

Transport layer protocol [SSH-TRANS]

Provides server authentication, confidentiality and integrity. In addition, it sometimes provides compression. SSH-TRANS typically runs on TCP/IP connections and may also be used on other reliable data streams. SSH-TRANS provides powerful 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 layer user authentication protocols can be designed to be on top of this protocol.

User Authentication Protocol [SSH-USERAUTH]

Used to provide client user authentication to the server. It runs in the transport layer protocol SSH-TRANS above. When SSH-USERAUTH starts, it receives the session identifier from the lower layer protocol (from the exchange hash H in the first key exchange). The session identifier uniquely identifies this session and applies to the token to prove ownership of the private key. SSH-USERAUTH also needs to know if the lower layer protocol provides privacy protection.

Connection protocol [SSH-CONNECT]

It runs on the user authentication protocol to provide interactive login sessions, remote command execution, forwarding TCP/IP connections, and forwarding X11 connections.

Client-side SSH security verification levels

From the client side, SSH provides two levels of security verification.

The first level (password-based security verification)

As long as you know your account and password, you can log in to the remote host. All transmitted data will be encrypted, but can not guarantee that you are connecting to a server that you want to connect. There may be other servers that are posing as real servers, that is, being attacked by “middleman”.

The second level (key-based security verification)

You need to rely on the key, which means you have to create a pair of keys for yourself and put the public key on the server you need to access. If you are connecting to an SSH server, the client software will make a request to the server for security verification with your key. After the server receives the request, look for your public key in your home directory on the server and compare it to the public key you sent. If the two keys match, the server encrypts the “challenge” with the public key and sends it to the client software. After the client software receives the “challenge”, it can decrypt it with your private key and send it to the server.

In this way, you must know the password of your key. However, the second level does not require a password to be transmitted over the network as compared to the first level.

The second level not only encrypts all transmitted data, but the “middle man” attack is also impossible (because he does not have your private key). But the entire login process may take a few seconds.

SSH is composed of client and server software.

There are two incompatible versions of SSH: 1.x and 2.x. Clients using SSH 2.x cannot connect to the SSH 1.x server. OpenSSH 2.x supports both SSH 1.x and 2.x.

The server is a daemon that runs in the background and responds to connection requests from clients. The server is generally an SSHD process that provides handling of remote connections, typically including public key authentication, key exchange, symmetric key encryption, and non-secure connections.

The client includes ssh programs and other applications like SCP (remote copy), slogin (remote login), sftp (secure file transfer).

Their working mechanism is roughly that the local client sends a connection request to the remote server. The server checks the requested package and IP address and then sends the key to the SSH client, and then sends the key back to the server. The connection has been established since then. There are some differences in the connection protocol between SSH 1.x and SSH 2.x.

Once a secure transport layer connection is established, the client sends a service request. When the user authentication is completed, a second service request is sent. This allows the newly defined protocol to coexist with the above protocol. Connection protocols provide a wide variety of channels for use, with standard methods for establishing secure interactive session shells and forwarding (“tunnelling technology “) proprietary TCP/IP ports and X11 connections.

SSH is designed to work on its own without taking advantage of the super server ( inetd ), although the SSH process can be run via tcpd on inetd, but this is completely unnecessary. After starting the SSH server, sshd runs up and listens on the default 22 port (you can use # ps -waux | grep sshd to see if sshd is running correctly). If it is not SSH started by inetd, then SSH will Always wait for a connection request. When the request comes in, the SSH daemon will generate a child process, which will perform the connection processing

Also, the SSH is designed to replace the Berkeley version of the r command set; it also inherits a similar syntax. As a result, the user does not notice the difference between using SSH and the r command set. With it, you can do some cool things. By using SSH, you don’t have to worry when you send messages over an insecure network. You can also use Telnet and POP channel mode, it can be used by SSH PPP to create a virtual private network (Virtual Private Network, channel VPN ). SSH also supports some other authentication methods, such as Kerberos and secure ID cards.
However, due to copyright and encryption algorithms, it is expected that more and more people will use SSH instead of Telnet or POP3 in the future.

You may like to see: