Telnet is a great tool for troubleshooting connectivity issues. But the inherent risk it poses makes many companies not allow telnet to be installed. This leaves a hole in the troubleshooting toolbelt of many administrators. Here is the solution.

alt text: PS Banner

Telnet has long been banned by many companies due to the inherent risk it poses for malicious actors to use as a easy vector. However, for many administrators, no telnet means loss of a built in tool that provides many useful features. For me, the most useful feature of telnet is as a port checker. Without requiring the installation of any tools and without using a port scanner, telnet allows us to check if a port is open for communication with a remote server.

On windows, a simple command like below allows you to quickly check and see if you can communicate via ssh to the remote machine:

telnet remotemachine.domain.com 22

However, without telnet, things get dicier. Linux works around it with other tools, built right into bash.

Bash Example:

>/dev/tcp/remotemachine.domain.com/22

However, windows is not so easy. Instead, windows users have to rely on third party tools or even do without. That is, unless, they know powershell. The nice thing about powershell is it is built into every currently supported server and workstation, and even runs on some that have lost support (ehm, Server 2003/Windows XP). As long as powershell is installed, you have an easy, built-in solution to this dilemma. The approach, however, differs based on the OS that you run it on.

If you run on Server 2012R2/Windows 8.1 or above, the following works:

Test-NetConnection -ComputerName remotemachine.domain.com -Port 22

If it is an older version of windows, the following, works because of the .Net integration.

try { 
  $tcp=new-object System.Net.Sockets.TcpClient 
  $tcp.connect("remotemachine.domain.com",22) 
  Write-Host "Connection Open"
  $tcp.close() 
} 
catch { 
  "Exception occured" 
}

In all cases, you can figure out if the connection is open or if there is some sort of firewall preventing connectivity. In the end, that is the whole point of this process. Do you have other built-in approaches? Leave a comment discussing your approach.