topic Re: Debugging SSH access issues on an old vms 6.2 UCX 4.0 machine - running out of ideas in Operating System - OpenVMS

Debugging SSH access issues on an old vms 6.2 UCX 4.0 machine - running out of ideas

cgilley — Mon, 11 Dec 2023 03:49:51 GMT

I have an old vax that I'm trying to get networked properly. This vax was converted to a VM (Charon Vax) decades ago, and I am tasked with moving it into the new secure environment - different network, much more restricted, no ping, etc. Charon VAX is hosted on a Windows Server VM. I have Multinet-SSH from Process Software installed and running. I'm running SSH in non-key mode to keep things simple. Putty and SSH on the vax do their negotiation, and it works.

I can SSH telnet into the VAX from the Windows server, so I know the SSH connection is active. I see the login attempt and access on the operator's console. I also can use basic telnet and still access the Vax. What I cannot seem to do is access the Vax via remote users from a different site. The connection in putty times out. All settings in putty have been verified, and we're using the same version. Mind you, the remote users have no problem accessing the existing Vax (on a different network) via putty.

The IT network guru for the corporaton is insistant that nothing is wrong with his network configuration and is getting rather annoyed with me. He shows me his network stats showing data going to the Vax with no response from the Vax. I'm looking for ideas on how to debug this situation. My gut feel is that the network is screwing with me (the network guy has zero knowledge of VMS). Perhaps I need to make some changes in UCX?

I freely admit to not being a network configuration guru,.

Suggestions or things I can look into?

Re: Debugging SSH access issues on an old vms 6.2 UCX 4.0 machine - running out of ideas

Volker Halle — Sat, 09 Dec 2023 15:54:55 GMT

You could run $ TCPIPTRACE host-ip to capture packets on the VAX arriving from the 'remote' SSH client node. Do any packets show up on the VAX ?

With UCX SHOW SERVICE/FULL SSH (or the equivalent command for Multinet-SSH) you could look at the Accept host:n.n.n.n and Accept netw: n.n.n.n parameters. With those you could limit the remote network addresses, which can connect to the SSH port (typically 22).

Volker.

Re: Debugging SSH access issues on an old vms 6.2 UCX 4.0 machine - running out of ideas

Steven Schweda — Sat, 09 Dec 2023 20:29:12 GMT

> [...] Putty and SSH on the vax do their negotiation, and it works.

I don't know what that means. What, exactly, works?

> I can SSH telnet into the VAX [...]

SSH and Telnet are two different things. I'll assume that you mean,
"I can SSH into the VAX [...]".

> [...] I also can use basic telnet [...]

Where "basic telnet" means "Telnet", as opposed to SSH (which is
_not_ "Telnet")?

> [...] the existing Vax [...]

This is some other VAX? I 'm confused. What, exactly, works?

Did you test any kinds of network connections other than SSH and
Telnet into the VAX?

> [...] different network, much more restricted, no ping, etc. [...]

"etc." is a bit vague. Does "ping" work _from_ the VAX to a system
on the same LAN segment? Any other network client? Telnet? SSH? FTP?
Web browser or Wget ? If so, does anything that works from the VAX to
its own LAN also work from the VAX to the outside world? (For example,
"ping 8.8.8.8"?)

> [...] Perhaps I need to make some changes in UCX?

With my weak psychic powers, I know nothing about how UCX is
currently configured.

Knowing nothing about the network configuration of the VAX, my first
guess would be that it has no valid (default?) route to the outside
world. In that case, it could communicate with other systems on its own
LAN, but might have no idea how to get a packet to any other network. A
remote client (like, say, SSH or Telnet "from a different site") would
get no response, and it would have no idea why.

Hence the suggestion to try some/any client on the VAX to make an
_outgoing_ connection to the outside world. If the problem is routing
on the VAX, then a _client_ on the VAX might return an error like, say,
"No route to host". In any case, I'd guess that you have a better
chance of getting a useful error message from a client on the VAX than
from a client elsewhere.

> I freely admit to not being a network configuration guru,.

Might be a sub-ideal skill-set when configuring a network. Providing
some basic network info might be a helpful start:

ucx show interface
ucx show route

If there's some properly-working system on the LAN with the VAX, you
might get some useful hints by examining the network config on _that_
system.

Around here, for example:

ITS $ ucx show version HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 5 on an HP rx2600 (1.50GHz/6.0MB) running OpenVMS V8.4-2L3 (Somewhat newer than yours, but should be similar.) ITS $ ucx show interface Packets Interface IP_Addr Network mask Receive Send MTU LO0 127.0.0.1 255.0.0.0 108186806 108186806 4096 WE0 10.0.0.140 255.255.255.0 108285676 231659000 9000 "10.0.0.140" is the IP address of (the Ethernet interface of) this VMS system. ITS $ ucx show route DYNAMIC Type Destination Gateway AN 0.0.0.0 10.0.0.1 [... distractions omitted ...] AH 127.0.0.1 127.0.0.1 "Destination 0.0.0.0" is the default route. In this case, "10.0.0.1" is the router which connects to the outside world.

Re: Debugging SSH access issues on an old vms 6.2 UCX 4.0 machine - running out of ideas

cgilley — Sun, 10 Dec 2023 01:05:10 GMT

let me decipher both responses - which I greatly appreciate - and will provide more info. My original post was perfectly clear to me facepalm.

Re: Debugging SSH access issues on an old vms 6.2 UCX 4.0 machine - running out of ideas

cgilley — Thu, 19 Sep 2024 21:15:12 GMT

To close out this thread, I quote Steve Hoffman of DEC fame, "Don't trust the network people."

After fighting this issue over 2 f'ing years, asking really basic comments and getting stove piped from international support people, suddenly it starts working. "No one knows why..." Right.

What did I learn? Time and materials, screw this ffp crap with multinational corporations.