1. Analysis of PuTTy remote login delay
While using Kali Linux, I prefer to run it in the background and install PuTTY on the Windows host system for remote access. I noticed there’s a 10-second delay each time I enter the password. Now, we utilize Wireshark for packet analysis to capture and analyze the network traffic.
For the sake of convenience, I will use Metasploitable2 based on Ubuntu operating system to analyze the problem
Step 1: First check the IP address of Metasploitable2: 192.168.70.131. Here I will not modify the network connection mode of Metasploitable2 and directly use NAT mode. Communication is possible between the local experimental host and the virtual machine. It does not affect the experiment.
Step 2: Enable SSH service By default, the SSH service of Metasploitable2de is not enabled, so enable the service for remote connection using the command: sudo /etc/init.d/ssh start
Step 3: In order to capture the communication packets of the SSH service, we first open Wireshark to capture packets (if you build a local area network by yourself, there is no communication with other services, you can directly analyze the SSH service, but in reality we often need to use filtering, here we also filter the captured data
Filtering, please note that what we use to capture is not our local physical network card but VMware Network Adapter VMnet8 (related to the NAT mode we selected earlier)
Step 4: Open the PuttY remote connection service and click OK. When you connect for the first time, the SSH key will be prompted. It is the default and has not been updated. Select Believe and continue the experiment.
Enter the Metasploitable2 account and password and press Enter to connect to the metasploitable2 operating system, but there is a delay.
Now let’s analyze the traffic data packets we just connected: At the beginning, we saw very few data packets, but when our PutTType connection was successful, the data packets increased rapidly.
The last step: Filtering and analyzing the data packets:
Now let’s analyze why there is a delay at the beginning. Because the connection uses the SSH service, we filter the protocol class for analysis.
In the figure above, I marked the key negotiation part from sequence number 25—–> sequence number 36. The protocol completes the key establishment and generates the communication key.
However, the time increment between sequence number 36 and sequence number 39 is about 10s, which is obviously larger than the others. So where did the missing packets between 36 and 39 go? What protocol was used instead of SSL protocol? Now we filter the frames between these sequence numbers.
Use the filter command: frame.number>35$$frame.number<40 Here, for the sake of obvious effect, we keep the previous two frames and the results are as follows:
Obviously, we can see that the data packets of frames 37 and 38 between these two serial numbers are TCP protocol and ARP protocol respectively. TCP is a connection protocol and ARP is an address resolution protocol, but we did not see the three-way handshake of TCP, which means that TCP did not establish a handshake and wasted about 5 seconds. In addition, ARP address resolution also wasted about 5 seconds. We can see that no domain name resolution service was performed. This is because of the NAT mode selected before. In NAT mode, the two network cards did not query the domain name. If two computers are in a remote SSL connection, they will query the domain name.
If we add the corresponding address resolution table to the routing table in the virtual network card, we can avoid reducing the time. I remember writing about how to change the address of the routing table before.
What is the essence of the problem: it is the protocol. The protocol specifies the parameters to be used when connecting, so let’s take a look at the SSH protocol
Use gedit to open the protocol. Use the command: gedit /etc/ssh/sshd_config
We make a modification to the DNS part:
The default setting is: #UseDNS no When we modify it, we only need to remove the previous comment.
2. Summary
This content provides a detailed analysis of the delay experienced when using PuTTY for remote login into a Metasploitable2 system on a Kali Linux environment. The author describes their observation of a 10-second delay when entering their password for SSH login and decides to investigate this issue using Wireshark to capture and analyze network traffic. The analysis is conducted in several steps. Initially, the IP address of the Metasploitable2 system is verified, and the SSH service, which is disabled by default, is enabled. Wireshark is then used to capture the SSH communication packets. It is noted that the analysis will focus on the VMware Network Adapter VMnet8 due to the NAT mode network setup. Upon connecting via PuTTY, a delay is consistently noted. The author identifies the problem as occurring between packet sequences 36 and 39. They perform packet filtering and highlight that packets 37 and 38 involve TCP and ARP protocols, with neither completing their expected actions—the TCP handshake and ARP resolution—which collectively account for the delay. To resolve the delay, the author suggests modifying the SSH configuration by altering DNS settings in the sshd_config file, recommending the removal of the comment on the “#UseDNS no” setting. This adjustment could optimize the connection process by bypassing unnecessary domain name queries due to the NAT mode used, thereby mitigating the delay. Overall, the issue’s essence is rooted in protocol handling within the network configuration.