Telnet vs SSH

When I was working at a small startup back in the day, there wouldn’t always be enough subject matter experts (SMEs) to solve problems due to small dev teams. In most cases, the startup required the engineering manager to be highly technical.

Back then, we were manually deploying by building the Rust web server on the EC2 instance and restarting the application server for non-prod environments.

Once, there was an issue where we were not able to SSH into the machine, and my manager quickly joined the call and fired a Telnet command first to check the connectivity. I couldn’t understand why he preferred Telnet over SSH; maybe it was just what he was familiar with, I thought.

¹

Fast forward to today, I was checking a couple of things around DNS resolution and had to use Telnet to check connectivity, which connected the dots for me.

Let’s talk a little bit about Telnet then:

• Telnet is a command-line utility, like other command-line tools such as curl or ssh.

• But the best thing about Telnet is that you can specify the port to check whether the server responds on that port.

• This helps establish the first point of connectivity we have.

  • For example, to see if a MySQL server is responsive or not, you could fire telnet root@mysql-server-ip 3306 to check if you're getting through.

  • To see if we can SSH or not, you could fire telnet root@server-ip 23

• You might be thinking, "We can use curl too, right?"

• Not really. Unlike Telnet, curl doesn’t have a direct way to make a TCP connection request. It works mostly for HTTP/HTTPS requests, meaning it strictly forwards the traffic to ports 80 or 443. If the ports are not accessible, we can’t clearly say whether the connectivity is broken or the port is inaccessible.

There are ways to use curl with Telnet, such as curl telnet://192.168.0.1:8082, but that’s a bit more verbose.

1. Image taken from . https://zoip.ir/ssh_vs_telnet/