Access denied: Always check for protocol compatibility

It’s easy to overlook, but when devices can’t be accessed, make sure they’re both working with the same protocol versions.

A user reviews data and statistical models. [analytics / analysis / tracking / monitoring / logging]
Tzido / Getty Images

While working on a base-wide network cutover at a military installation recently, I was verifying configurations on core, distribution, and access-node devices. Using a local host computer on the network, I was connected to the distribution node via an Ethernet port in a separate room and successfully pinged the node to verify network connectivity.

Then I tried to access the node using PuTTY via SSH (port 22), the recommended and secure method, and received this error message: “Network Error: Connection Refused. The network connection PuTTY tried to make to your device/server was rejected by the server.” This error usually happens because the server does not provide the service which PuTTY is trying to access.

I was working in the same building that the distribution node was in, so I went to it and consoled in using a serial cable. I wanted to verify that the device’s SSH ACL statement allowed my host to access the node via SSH. It did.

I checked to make sure the SSH version my computer was using for the PuTTY session matched the version installed on the node. It didn’t. My computer was using SSHv1; the node used SSHv2, so I had to install a new version of SSH.

Since I had to upgrade the software anyway, I took the opportunity to switch from PuTTY to SecureCRT, which has a friendlier user interface. And I made sure it supported SSHv2.

Lesson learned: Always check for protocol compatibility when making network connections.

Copyright © 2022 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022