Remote Login with SSH
Now everyone can work from home, securely (Part2/3)
Introduction
Remote login allows users to connect to servers that are located in different networks from their local machine. Similar to how we use remote to control our devices even it is just few feet away (lazy people understand this); remote login allow us to work from anywhere while accessing data stored on remote servers in the company’s private networks.
Remote Login using TELNET
The simplest way to remote login is by using TELNET. TELNET is a basic protocol that opens TCP port 23 on the server for remote access. Each users are given a unique account that is password protected. TELNET is fast because it is stripped down; but it is not intuitive since it is purely command based.
One of the biggest problem of TELNET is that the connections between TELNET_client and TELNET_server is not encrypted. An attacker can easily intercept TELNET packets and recover the data (plaintext) in transit, including the username and password. This attack is known as the Man-in-the-Middle (MITM) attacks. Once the packets are intercepted, the attacker has a choice to either discard them (denial-of-service) or to inject modified packets (injection attacks) then sending malicious packets to the destination.
The security issue of TELNET is addressed in the Secure Shell (SSH) protocol. In SSH, the authentication data exchanged between the client and server are encrypted.
Secure Shell (SSH)
Secure Shell (SSH) is the upgraded version of TELNET. What you can do on a TELNET session is exactly the same as a SSH session. In real world, SSH is the preferred option of remote login service for secure connections. SSH’s connections are encrypted using symmetric, asymmetric and hashing mechanism. The added layers of protection introduced some extra processing overhead in the edge nodes. So, it is recommended to use TELNET if remote login is used in a LAN with trusted users; and use SSH for connecting to servers located in remote LANs (Taylor: ‘I don’t trust nobody, and nobody trust me’ on the Internet).
SSH opens TCP/port 22 to establish an end-to-end encrypted channel. For SSH to works, the SSH service must be enabled on the server. SSH server can run on different versions of Windows Server, variants of Linux Distros or macOS Server. Most of the time, the server configuration is transparent to end users. Note that the command to ‘navigate’ the server is OS dependent; for example — to list all the files and folders on the server, we type ‘ls’ command in Linux server. Meanwhile, on a Windows server, we type ‘dir’ command.
Another use of SSH is to bypass firewall through SSH Tunnelling. Firewall normally inspect packets based on source+destination ports and IP address. Luckily, most corporate networks allows TCP/22 for SSH for remote login use. We can ride on this by encapsulating the traffic that are blocked into the SSH packet. For example, FIFA 2020 is using TCP/1234; this port is blocked by the perimeter firewall. Using SSH tunnel, we can hide the TCP/1234’s packet into TCP/22 packets which are allowed to bypass firewall filtering.
SSH vs TELNET (in context of network security)
SSH has mostly replaced TELNET for the added security. In a secure connection, the data (plaintext) is encrypted with cryptographic keys into secured data (ciphertext). These keys can be secret key in symmetric encryption, or a {private/public} key set in asymmetric encryption. These keys are exchanged or kept only by the sender and receiver. If the encrypted packets are intercepted in MITM; the attacker needs to guess the original key used to ‘lock’ this packet to see the packet’s contents.
Here’s the video to illustrate how MITM can break TELNET, and how this security flaws can be fixed with SSH:
This means during the MITM attacks, the attacker can only intercept packets that contains these cipher text; but to decrypt them, the attacker need to guess the original secret keys through other form of attacks like the dictionary attack or brute-force attacks.
How to use SSH
In the example network, Avocado is trying to remote connect to the data server using SSH.
On the client, we can use any remote login tool to start a SSH connection to the server. In this example, we use putty.exe to connect to a SSH server. We simply set the IP address of the target server and check the ‘SSH’ option. Putty automatically update the port number to tcp/22. Clicking on ‘open’ will initiates a SSH connection.
If the SSH server is reachable; it will asks for the username and password for authentication (similar to TELNET except the credentials are encrypted before sending). The authentication take slightly longer in the first login since the client needs to verify the public key of the server. Once the server is confirmed legit, the client store the server is added to the ‘known_hosts’ directory on the client. The subsequent connections will be faster; as the client simply retrieve the server info from ‘known_hosts’ directory (skipping the verification).
Understanding SSH prompts
If the connection is successful; Avocado should be able to perform some basic tasks like file operations using SSH commands. The command for some of the supported tasks are listed here. We can see that we are connected to the right server from the second line ‘cisco@192.168.209.244’; which is the same IP we specify in putty when starting the connection. The ‘last login’ line indicates our client IP address; which is the IP address of Avocado’s PC at 192.168.209.159. In this example; Avocado typed ‘ls’ command to list all the files and folders that are visible on the data server. The output shows that there are currently 2 files, namely ‘ftp-eagle-server.pcap’ and ‘tftp-eagle-server.pcap’ and a folder named ‘Desktop’ on the server.
Avocado can now freely perform any authorized tasks on the server. Some common actions are:
We can easily verify the connection to the SSH server by checking the opened ports on the client device. For example, Avocado can type the command:
Command
=========
‘netstat -b’ Usage
======
shows all the active ports that are opened in the client machine
The ‘netstat’ command will output a list of opened ports on the client machine. We know what SSH runs on port TCP/22; and the SSH server’s IP is 192.168.209.244.
A socket is a combination of {IP:Port} to indicate a network connection
Referring to the 4th line in command output, we can find the socket entry of 192.168.209.244:22. This imply that the SSH connection to the server is successful. More options for netstat can be found here.
Packet Analysis (TELNET vs SSH)
SSH is a secure remote login service we hoped TELNET could be. So how exactly does SSH prevent MITM that has been the archilles heel to TELNET?
First, let’s inspect the authentication packets of TELNET and SSH. Using the same example network, Avocado first connect to the remote data server using TELNET; then start a new connection to the server using SSH. For simplicity, we assume that the username (Cisco) and password (Cisco) is the same for both services.
Going deep, we look at one of the TELNET packet captured when Avocado is trying to login to the server. From the Wireshark analysis, we can clearly see character ‘C’, ‘I’, ‘S’, ‘C’, ‘O’; which is the all the characters of the username in plaintext. This is because TELNET does not encrypt the data prior to sending.
Next, we can see that the payload in the SSH packet (supposingly containining the username) is not decoded by Wireshark. This is because the packet is encrypted using some form of cryptography. For Wireshark to unpack it, the original secret keys used to lock this message is needed.
From this story, we’ve learnt that SSH adds the much needed encryption to protect sensitive data in transit. But there just one catch; to use SSH productively, we also need to be a master in Linux shell or Windows bash commands. If this sounds scary, then try out some modern remote login apps like VNC and Windows Remote Desktop that offers more functionality on sleek beautifully designed interfaces. Now, work from home is just a few clicks away.
