Telnet is a network protocol used to remotely access a computer and provides two-way text-based communication. So you need a telnet server and client to talk to each other.

Telnet is one of the popular Linux/Windows utilities that has long served its purpose.

A major problem with telnet on modern systems is that it is not secure. All communication in telnet happens in plain text, and all network traffic is unencrypted. Essentially anyone with proper access and tools can snoop on network traffic to read this traffic. As such, most modern Linux operating systems do not come with telnet pre-installed, and others recommend against using it.

With the advent of SSH or Secure Shell protocol, which is more than an encrypted replacement for telnet, the use of telnet for its intended purpose has long been outdated. But there’s an alternate use of telnet that many system administrators and tech enthusiasts still use, which is to check the connectivity of remote TCP ports.

One can simply check if the remote TCP port is listening and responding properly using the telnet command. The below snippet shows how we can check if google.com is up and working by checking HTTP/HTTPS connectivity.

$ telnet google.com 80
Trying 142.250.183.206...
Connected to google.com.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

$
$ telnet google.com 443
Trying 142.250.183.206...
Connected to google.com.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
$

A TCP port that is not open or accessible will behave like the below when checked with telnet:

$ telnet google.com 22
Trying 142.250.193.174...
^C
$

This makes troubleshooting simple network connectivity issues easy in combination with ping, traceroute or tracepath, netstat etc. commands.

If you’re using RHEL 8 (or even older versions of RHEL/CentOS), you have the option to use nc (or Ncat or Network Connector), which supports many network diagnostic-related options. We’ll be discussing how to install and use this tool on RHEL8 and similar systems.

What is nc?

nc (or Ncat) is a popular general-purpose command-line tool for reading, writing, redirecting, and encrypting data across a network. Originally written for nmap project, there are now multiple Netcat implementations available. It works with both TCP and UDP across IPv4 and IPv6 and provides limitless potential use cases.

Below are some of the major features of nc utility:

  • Ability to chain ncats together
  • Redirection of TCP, UDP, and SCTP ports to other sites
  • Encrypt communication with SSL support
  • Proxy support via SOCK4/5 or HTTP proxies (including authentication)
  • Supports multiple platforms, including Windows, Linux, and macOS

Installing nc

nc is available as part of default repositories in RHEL systems. To install it on RHEL 7 system, simply issue the below command on the terminal:

$ sudo yum install -y nc

For RHEL 8 system, you can use dnf as:

$ sudo dnf install -y nc

Check TCP Connectivity

Though nc offers a host of features that supports a number of use cases across applications, one of the common one is during network troubleshooting in place of telnet.

nc can show if you can reach a TCP port. Here’s the syntax:

$ nc -vz

As an example, if I want to check if I can reach Geekflare over http or https. I can check that using nc as shown below (port 80 is for http while 443 is for https):

$ nc -vz geekflare.com 80
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 104.26.11.88:80.
Ncat: 0 bytes sent, 0 bytes received in 0.02 seconds.
$
$ nc -vz geekflare.com 443
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 104.26.10.88:443.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
$

Similarly, a non-reachable or blocked port will show output like (multiple addresses are checked as Geekflare DNS points to multiple IPs):

$ nc -vz geekflare.com 22
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connection to 172.67.70.213 failed: Connection timed out.
Ncat: Trying next address...
Ncat: Connection to 104.26.11.88 failed: Connection timed out.
Ncat: Trying next address...
Ncat: Connection to 104.26.10.88 failed: Connection timed out.
Ncat: Trying next address...
Ncat: Connection to 2606:4700:20::681a:a58 failed: Network is unreachable.
Ncat: Trying next address...
Ncat: Connection to 2606:4700:20::681a:b58 failed: Network is unreachable.
Ncat: Trying next address...
Ncat: Network is unreachable.
$
$ dig geekflare.com  short
104.26.10.88
172.67.70.213
104.26.11.88
$

Check UDP Connectivity

telnet can only check communication with a remote TCP port while nc allows you to check TCP as well as UDP connectivity.

nc can simply send UDP packets instead of default TCP ones using:

$ nc -vzu

But UDP is a session-less protocol, unlike TCP, so as such, you can’t confirm end-to-end UDP connectivity on all possible scenarios just by sending UDP packets on one end as unless the listening process on the remote end sends some response, nc won’t be able to judge whether its sent packet reached the destination or not. But nc offers an alternative to determine end-to-end UDP connectivity by launching a UDP listener, assuming you’ve proper access to CLI on the remote server.

So assuming you need to check UDP connectivity between two Linux hosts for DNS using nc, a simple way to do this would be to launch nc server listening on required port:

$ sudo nc -ul

For DNS, we need to check port 53 which would make the above command as:

$ nc -ul 53

On the client end, you would need to launch another nc process that sends UDP packets to the server:

$ nc -u

Which would make our command:

$ nc -u  53

Considering nothing blocking the UDP traffic for port 53 between these two machines, whatever you type and enter on one machine should be visible on the other hosts like two-way chat. If not, some firewall is blocking the connectivity between these two systems.

Server and client model using nc works flawlessly for these kinds of simple connectivity checks between hosts. Like the above UDP check, nc can also listen for TCP packets on a given port:

$ sudo nc -l

On the client end, you can normally send TCP packets to check connectivity:

$ nc

The above server/client nc method is not required in the case of TCP connections (unlike UDP) as it is a connection-oriented protocol and works with acknowledgments. Any listening process working on TCP will directly respond to nc TCP packets.

Summary

This article summarizes how nc utility stands as a direct replacement for telnet in modern Linux systems as far as checking port connectivity goes and provides much more power to the end-user in diagnosing and resolving network issues.

nc help can be accessed using nc -h command:

$ nc -h
Ncat 7.70 ( https://nmap.org/ncat )
Usage: ncat [options] [hostname] [port]

Options taking a time assume seconds. Append 'ms' for milliseconds,
's' for seconds, 'm' for minutes, or 'h' for hours (e.g. 500ms).
  -4                         Use IPv4 only
  -6                         Use IPv6 only
  -U, --unixsock             Use Unix domain sockets only
  -C, --crlf                 Use CRLF for EOL sequence
  -c, --sh-exec     Executes the given command via /bin/sh
  -e, --exec        Executes the given command
      --lua-exec   Executes the given Lua script
  -g hop1[,hop2,...]         Loose source routing hop points (8 max)
  -G                      Loose source routing hop pointer (4, 8, 12, ...)
  -m, --max-conns         Maximum  simultaneous connections
  -h, --help                 Display this help screen
  -d, --delay          Wait between read/writes
  -o, --output     Dump session data to a file
  -x, --hex-dump   Dump session data as hex to a file
  -i, --idle-timeout   Idle read/write timeout
  -p, --source-port port     Specify source port to use
  -s, --source addr          Specify source address to use (doesn't affect -l)
  -l, --listen               Bind and listen for incoming connections
  -k, --keep-open            Accept multiple connections in listen mode
  -n, --nodns                Do not resolve hostnames via DNS
  -t, --telnet               Answer Telnet negotiations
  -u, --udp                  Use UDP instead of default TCP
      --sctp                 Use SCTP instead of default TCP
  -v, --verbose              Set verbosity level (can be used several times)
  -w, --wait           Connect timeout
  -z                         Zero-I/O mode, report connection status only
      --append-output        Append rather than clobber specified output files
      --send-only            Only send data, ignoring received; quit on EOF
      --recv-only            Only receive data, never send anything
      --allow                Allow only given hosts to connect to Ncat
      --allowfile            A file of hosts allowed to connect to Ncat
      --deny                 Deny given hosts from connecting to Ncat
      --denyfile             A file of hosts denied from connecting to Ncat
      --broker               Enable Ncat's connection brokering mode
      --chat                 Start a simple Ncat chat server
      --proxy   Specify address of host to proxy through
      --proxy-type     Specify proxy type ("http" or "socks4" or "socks5")
      --proxy-auth     Authenticate with HTTP or SOCKS proxy server
      --ssl                  Connect or listen with SSL
      --ssl-cert             Specify SSL certificate file (PEM) for listening
      --ssl-key              Specify SSL private key (PEM) for listening
      --ssl-verify           Verify trust and domain name of certificates
      --ssl-trustfile        PEM file containing trusted SSL certificates
      --ssl-ciphers          Cipherlist containing SSL ciphers to use
      --ssl-alpn             ALPN protocol list to use.
      --version              Display Ncat's version information and exit

See the ncat(1) manpage for full options, descriptions and usage examples
$

For more detailed information on nc command, refer to its manual page.

$ man nc

, ,
Show Comments