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

[cgilley]

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?

[Volker Halle]

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.

[Steven Schweda]

> [...] 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.

[cgilley]

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