The post is synced to the Github blog

Introduction to the

Secure Shell (SSH) is a Secure network protocol that provides data communication security, remote login, and remote command execution. It was proposed by Tatu Ylonen, a researcher at the University of Helsinki, Finland, in 1995. It is intended to replace insecure remote Shell protocols such as Telnet, RSH, and Rexec. Since then, two major versions of SSH have been developed: SSH-1 and SSH-2.

By using SSH, you can encrypt all transmitted data, making man-in-the-middle attacks impossible, as well as preventing DNS spoofing and IP spoofing. With SSH, an added benefit is that the data being transferred is compressed, so it speeds up the transfer. SSH has many features, both as a replacement for Telnet and as a secure “channel” for FTP, Pop, and even PPP.

SSH is a security protocol based on the application layer and transport layer. It provides a secure transmission and use environment for shells on computers.

The basic framework of SSH

The SSH protocol framework consists of three protocols:

  • The Transport Layer Protocol: Transport layer protocols provide support for server authentication, data confidentiality, information integrity, etc.
  • The User Authentication Protocol: User authentication protocol provides client identity authentication for the server.
  • The Connection Protocol: Connection protocol Multiplexes the encrypted information tunnel into several logical channels for higher-level application protocols.

At the same time, SSH provides extended support for many high-level network security application protocols. The hierarchical relationship between them can be expressed as follows:

SSH encryption

SSH combines Public keys, Private keys, and Secret keys to ensure security and performance.

  • Public Key/Private key: Asymmetric encryption, secure, butLow efficiencyIs not suitable for large-scale data encryption and decryption operations
  • Secret Key: Symmetrically classified, efficient, butRelatively low securityKey distribution is especially inconvenient

For basic knowledge of cryptography and digital signatures, please refer to Ruan Yifeng’s blog

  • Notes on cryptography
  • What is a digital signature

Main features of SSH

  • Encryption: Avoid data content leakage
  • Communication integrity: avoiding data tampering and sending or receiving address masquerading

    (Check whether the data has been tampered with and whether the data came from the sender rather than the attacker)SSH-2throughMD5 和 SHA-1To do that,SSH-1useCRC-32
  • Authentication: Identifies the identity of the data sender and receiver. Client Authentication: prevents attackers from impersonating the IDENTITY of the SSH server and prevents attacks by intermediaries and redirection requests.OpenSSHThrough theknow-hostsStore the host name andhost keyAuthenticating the server server authenticates the requestor: provides a less secure user password and a more secure oneper-user public-key signatures; In addition, SSH supports integration with third-party security service systems, for exampleKerberosEtc.
  • Authorization: User access control
  • Forwarding or tunneling to encrypt other TCP/IP-based sessions Can be used over SSH to ensure communication security for Telnet and FTP. Three types of sessions are supportedForwardingOperation:Port Forwarding;X Forwarding;Agent Forwarding

The SSH Key

SSH uses a combination of Public and Private keys and Secret keys:

  • Public Key/Private Key (Asymmetric encryption)Transfer between client and server before establishing secure channelSecret KeyandThe identity authentication;
  • Secret Key (symmetric encryption)It is used to encrypt and decrypt data as a security guarantee for SSH sessions.

SSH can handle four types of keys:

The name of the The life cycle create type describe
Host Key persistence The service side Public Key The Host Key is a persistent asymmetric Key that the server uses to prove its identity
User Key persistence The user Public Key A User Key is a persistent asymmetric Key that the client uses to prove the User’s identity (a User can have multiple keys/identifiers)
Server Key The default value is 1 hour The service side Public Key The Server Key is a temporary asymmetric Key used in the SSH-1 protocol. It is regenerated on the Server at regular intervals (one hour by default). It is used to encrypt the Session Key (only for SSH-1 and enhanced by SSH-2). The Server Key is used as a concept to facilitate the description of the process.
Session Key The client Session Secret Key The Session Key is a randomly generated symmetric Key that encrypts the communication between the user’S SSH client and server and is destroyed at the end of the Session

SSH framework:

Establishing a secure connection

Before a meaningful session can take place, the SSH client and server must first establish a secure connection. This connection allows both parties to share keys, passwords, and finally any data to each other.

Now let’s look at how the SSH-1 protocol ensures network connection security. The SSH-1 client and server from Aka seem to go through many steps, negotiating using encryption algorithms, generating and sharing a session key, and finally establishing a secure connection:

  1. The client connects to the server
  2. The SSH protocol version supported by the client and server is exchanged
  3. The client and server switch to the packet-based protocol
  4. The server provides its own authentication and session parameters to the client
  5. The client sends a key to the server
  6. Both parties enable encryption and complete server authentication
  7. Establishing a Secure Connection

Each phase involves multiple interactions between the client and the server, including certificate transfer, algorithm negotiation, and channel encryption.

Procedure 1 Connect the client to the server

This step is nothing more than sending a connection request to the server’s TCP port (convention 22).

2 The client and server exchange supported protocol versions

These protocols are represented by ASCII characters, for example, SSH-1.5-1.2.27, which indicates the SSH protocol. The version number is V1.5. The implementation version of SSH1 is 1.2.27. You can use the Telnet client to connect to an SSH server port to see this string:

➜ Telnet 192.168.1.200 22 Trying 192.168.1.200... Connected to doc.dinghuo123.com. Escape character is '^]'. Ssh-2.0-openssh_6.0p1 debian-4 +deb7u6Copy the code

If the client and server determine that their protocol version numbers are compatible, then the connection continues; otherwise, both sides may decide to break the connection. For example, if a client that uses only SSH-1 connects to a server that uses only SSH-2, the client disconnects and prints an error message. It’s actually possible to do something else: for example, a server that only uses SSH-2 could call the SSH-1 server to handle the connection request.

3 Switch the packet-based protocol between the client and server

Once the protocol version switching process is complete, both the client and the server switch from the underlying TCP connection to the subscription-based protocol. Each packet contains a 32-bit field, 1-8-byte padding bits [to prevent known plaintext attack unknown-plaintext], a 1-byte packet type code, packet validity data, and a 4-byte integrity check field.

4 The server sends its identity certificate and session parameters to the client

The server sends the following message (not yet encrypted) to the client:

  • Host KeyIs used later to prove the identity of the server host
  • Server KeyTo help establish a secure connection
  • A sequence of eight random bytes calledCheck bytes. The client must include these detection bytes in the next response, or the server will reject the response information, which prevents someIP Spoofing Attack.
  • Encryption, compression, and authentication methods supported by the server

At this point, both parties calculate a common 128-bit Session ID. It is used in some protocols to uniquely identify the SSH session. The value is the result of the MD5 hash function applied together with the Host Key, Server Key, and check bytes.

When the client receives the Host Key, it asks: “Have I communicated with this server before? If so, what is its host key?” To answer this question, the client consults its own well-known host database. If the newly arrived host key matches a previous key in the database, there is no problem.

At this point, however, there are two possibilities: the server is not in the well-known host database, or the server may exist but its host key is different. In both cases, the client chooses whether to trust the newly arrived key or reject it. This is where human guidance comes in; for example, the client user might be prompted to decide whether to accept or reject the key.

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)?Copy the code

If the client refuses to accept the host key, the connection is aborted. Let’s assume that the client accepts the key and move on.

5 The client sends a session key to the server

The client now randomly generates a new Key, called a Session Key, for the mutually supported Bulk Algorithms. Its purpose is to encrypt and decrypt the data sent between the client and the server. All that needs to be done is to send the Session Key to the server, and both parties can enable encryption and begin secure communication.

Of course, the client cannot simply send the Session Key to the server. If a third party intercepts the key, it can decrypt the messages between the client and the server. After that, you’re out of safety. Therefore, the client must securely send the Session Key. This is done by encrypting the Server twice: once using the Server’s public Host Key and once using the Server Key.

This step ensures that only the server can read the Session Key. After the Session Key has been encrypted twice, the client sends it to the server, along with the detection bytes and the selected algorithm (which is selected from the list of algorithms supported by the server in Step 4).

6 Enable encryption and complete server authentication on both sides

After sending the Session Key, the two sides began using the Key and the bulk of the selected algorithm to encrypt the Session data, but before starting to continue to send other data, the client must wait for the server sent a confirmation message, the message (and after all data) must use the Session Key encryption (the Session Key). This is the final step, which provides server authentication: Only the destination server can decrypt the Session Key because it is encrypted using the previous Host Key that validates the list of known hosts.

Without a Session Key, the bogus server cannot decrypt subsequent protocol traffic and generate valid traffic, which the client notices and breaks the connection.

Note that the server address is implied; There is no explicit exchange to verify the server Host Key. Therefore, the client must wait for a meaningful response from the server using the new Session Key before continuing to send data. Thus authenticating the service before processing, although there is nothing special about the SSH-1 protocol in this regard. However, SSH-2 requires that the local exchange Session Key (SSH-2) be displayed during server authentication.

Encrypting the Session Key again using the Server Key provides a feature called perfect forwarding security. This means that there is no possibility of permanent key leakage because it does not compromise the security of other parts and future SSH sessions. If only the server Host Key is used to protect the Session Key, the disclosure of the Host Key will endanger future multiplexes and allow the decryption of the previously recorded Session. A second encryption with the Server Key eliminates this disadvantage because the Server Key is temporary, it is not saved to disk and is updated periodically (once an hour by default). If an intruder has obtained the server’s private key, he must also perform a man-in-the-middle or server spoofing attack to harm the session.

7 Establish a secure connection

Because both clients and servers now know the Session Key and no one else does, they can send encrypted messages to each other (using their agreed bulk algorithm) and decrypt them. Moreover, the client can also complete server authentication. We are now ready to start client side authentication.

Client Authentication

SSH provides multiple client authentication modes.

SSH – 1:

  • Password
  • Public Key
  • Kerberos
  • Rhosts && RhostsRSA
  • TIS

SSH – 2:

  • Password
  • Public Key
  • Hostbased abandoned this method in CONSIDERATION of security vulnerabilities in Rhosts in SSH-2.

Here we discuss the Password and Public Key methods we often use.

At this point, the secure channel has been established and all subsequent content is encrypted and transmitted through the Session Key.

Password

In Password mode, the client provides the user and Password, and the server matches the user and Password for authentication. In unix-like systems, such as OpenSSH, authentication is generally performed through the local interface of the system.

Password has the advantage of being simple and can be used without any additional configuration. Disadvantages The password is not easy to remember, and a simple password is easily cracked by force.

Public Key

The basic principle of Public Key authentication is to encrypt a piece of data on the server using the Public Key based on asymmetric encryption. If the client can prove that it can decrypt the data using the private Key, the identity of the client can be identified. Because the server needs to encrypt the data using the public Key of the Key pair generated by the client, it needs to store the public Key in the server’s Auhtorized Key first. Remember that Github requires an SSH KEY before using git push code?

The following describes the process of client authentication using Public keys.

  1. The client initiates onePublic KeyThe authentication request is sentRSA KeyThe modulus of the. (For more details on RSA Key –> Wikipedia)
  2. The server checks for the presence of the public key of the request account (stored in Linux)~/.ssh/authorized_keysFile), and the access rights it has. If not, disconnect
  3. The server uses the corresponding public key to encrypt a random 256-bit string and send it to the client
  4. The client decrypts the string using the private key and combines itSession IDGenerates an MD5 value and sends it to the server. In combination withSession ID“Is to avoid being used by attackersReplay attacks.
  5. The server uses the same method to generate the MD5 value and compares it with the MD5 value returned by the client to authenticate the client.

The illustration SSH

reference

  • Overview of SSH
  • SSH Protocol Introduction
  • SSH: The Secure Shell – The Definitive Guide by O ‘Relly