SSH$DEFINE_COMMANDS in SYLOGIN causes multiple TCPIP services to fail

[csewell]

The instructions to add @SSH$ROOT:[BIN]SSH$DEFINE_COMMANDS.COM to SYLOGIN to define OpenSSH commands for all users logging in causes multiple TCPIP services to fail on system startup. SSH$STARTUP needs to be run after TCPIP$STARTUP and the logical name SSH$ROOT isn't defined when TCPIP$STARTUP runs. A better suggestion would be to place "IF F$SEARCH("SSH$ROOT:[BIN]SSH$DEFINE_COMMANDS.COM") .NES. "" THEN @SSH$ROOT:[BIN]SSH$DEFINE_COMMANDS" in SYLOGIN.

[m_detommaso]

Already reported in the manual "VSI OpenVMS x86-64 V9.2-1 Installation Guide" Chapter 4 (Networking Options) on page 33 :

https://docs.vmssoftware.com/vsi-openvm ... e/#d0e2900
https://docs.vmssoftware.com/docs/vsi-o ... -guide.pdf

/Maurizio

[csewell]

Sorry, not running VSI OpenVMS x86-64 V9.2-1 so I haven't looked at the installation guide for that. I was referring to the OPENSSH V8.9-1D IA64 release notes. I see they tried to improve that in OPENSSH V8.9-1E by suggesting the addition of a call in SYLOGIN to SSH$ROOT:[BIN]SSH$OPENSSH_INIT.COM that contain all that code, but same problem.

[volkerhalle]

Maurizio,

this 'solution' given in the Installation Guide is questionable ...

SYLOGIN.COM is the system-wide login procedure, which every user should execute after login.

It should NOT contain any commands, which should/could only be executing by 'privileged' users !

This problem has been discussed before, see viewtopic.php?f=1&t=8676

Volker.

[m_detommaso]

Volker,

this is reported in the official V9.2-1 VSI documentation; this is exactly the solution csewell suggested, and it seemed correct to point it out :

Personally, I prefer to run sys$startup:ssh$define_root.com dcl procedure from sys$manager:sylogicals.com.

I also take this opportunity to suggest to the VSI engineers to use the logical name of the volume and not the physical device name when defining ssh$root;

for example (my modified file ssh$define_root.com) :

dirac> type sys$startup:ssh$define_root.com
$!DEFINE/SYSTEM/EXEC/NOLOG SSH$ROOT DSA0:[SYS0.SYSCOMMON.OPENSSH.]/TRANS=CONCEALED <- OLD
$ DEFINE/SYSTEM/EXEC/NOLOG SSH$ROOT SYS$SYSDEVICE:[SYS0.SYSCOMMON.OPENSSH.]/TRANS=CONCEALED <- NEW
$ exit 1


/Maurizio

[volkerhalle]

Maurizio,

the fact, that this 'solution' is included in the offical documentation, does not mean, that this is the 'correct solution' for this problem !

The people, who have ported OpenSSH to OpenVMS, do not always seem to know all the OpenVMS basics:

- SYLOGIN is the system-wide login procedure for ALL users
- it should not contain commands, which would only work for privileged users

The correct solution for invoking SSH$DEFINE_COMMANDS in SYLOGIN should be

$ @sys$sysdevice:[vms$common.openssh.bin]SSH$DEFINE_COMMANDS

(maybe after testing, that this procedure even exists). This command seems to have been present in the 'previous' version of the installation guide.

Volker.

[csewell]

Maurizio,

this 'solution' given in the Installation Guide is questionable ...

SYLOGIN.COM is the system-wide login procedure, which every user should execute after login.

It should NOT contain any commands, which should/could only be executing by 'privileged' users !

This problem has been discussed before, see viewtopic.php?f=1&t=8676

Volker.

Oops, I see this problem has been discussed before and the same solution provided. Never mind, unless you are installing OpenSSH on Alpha or IA64 and haven't seen the X86/X64 installation guide.

I'd just like to point out that referencing specific and possibly changing directories (@sys$sysdevice:[vms$common.openssh.bin]SSH$DEFINE_COMMANDS.COM) defeats the purpose of logical names. And the instructions to cut and paste large chunks of code into SYLOGIN to get the SSH commands defined for users, or scattering SSH command file execution in multiple startup command files makes the startup procedures less maintainable and maybe more confusing.

[m_detommaso]

The people, who have ported OpenSSH to OpenVMS, do not always seem to know all the OpenVMS basics:

Very interesting

[volkerhalle]

Maurizio,

I had reported this same problem as SPS-1050 against E9.2-1 back on 9-MAY-2023 and it's status still shows: 'Under Investigation'

Whatever that means...

Volker.

[volkerhalle]

The people, who have ported OpenSSH to OpenVMS, do not always seem to know all the OpenVMS basics:

Very interesting :roll:

Maurizio,

if you don't agree with my observation and remark and just believe the official OpenVMS documentation, then please look at the following code from the VSI OpenVMS x86-64 V9.2-1 Installation Guide chapter 4.3.12:

Code: Select all

$ if f$trnlnm("SSH$ROOT", "LNM$SYSTEM_TABLE") .eqs. ""
$ then
$     write sys$output "VSI-OpenSSH is not configured. Configuring..."
$     if (f$search("SYS$STARTUP:SSH$DEFINE_ROOT") .nes. "")
$     then
...

Do you spot the problem ? The filespec for F$SEARCH is missing the file extension spec, so the result will NEVER be .nes. "" !

Now I ask you, how can some erroneous code like this get into the official documentation ?

Reported again as SPS-1121.

If you look at SYS$STARTUP:SSH$STARTUP, you'll see that this procedure would DEFINE SSH$ROOT (if not already defined). But as SSH$STARTUP should be executed at the bottom of SYSTARTUP_VMS.COM (after TCPIP$STARTUP), it's too late for the starting of the various TCPIP serrvices and some of them will fail to start, if SSH$ROOT is not defined and SYLOGIN.COM contains an unconditional invocation of @SSH$ROOT:[BIN]SSH$DEFINE_COMMANDS.COM

So the correct solution would be:

- invoke SYS$STARTUP:SSH$STARTUP.COM from SYSTARTUP_VMS.COM
- include the following code into SYLOGIN.COM (if you want the SSH commands to be defined for all users):

Code: Select all

$ IF F$SEARCH("SSH$ROOT:[BIN]SSH$DEFINE_COMMANDS.COM").NES.""
$ THEN
$    @SSH$ROOT:[BIN]SSH$DEFINE_COMMANDS.COM
$ ENDIF

Volker.