ssh on X86 with pipe

[greg@tssolutions.com.au]

Have been typing to get access from Ubuntu and windows using ssh
windows
> ssh grt@vms0 "type sys$input " < x0.txt
sometime works sometimes just the first line or two gets through, sometime all the lines
Even if successful
GRT$ ty ssh$cmdrun.log
%TYPE-W-READERR, error reading _V922$FTA210:[].;
-RMS-F-RER, file read error
-SYSTEM-F-HANGUP, data set hang-up
%RMS-E-DNR, device not ready, not mounted, or unavailable
GRT job terminated at 31-MAY-2024 11:36:30.56

Accounting information:
Buffered I/O count: 200 Peak working set size: 5312
Direct I/O count: 50 Peak virtual size: 225616
Page faults: 405 Mounted volumes: 0
Charged CPU time: 0 00:00:00.06 Elapsed time: 0 00:00:00.11


ubuntu
greg@tssu1:~$ ssh grt@vms0 "type sys$input " < x0.txt

Welcome to OpenVMS (TM) x86_64 Operating System, Version V9.2-2
grt@vms0's password:

%TYPE-W-SEARCHFAIL, error searching for DISK$USER1:[GRT]sys.LIS;
-RMS-E-FNF, file not found

GRT$ ty ssh$cmdrun.log
%TYPE-W-SEARCHFAIL, error searching for DISK$USER1:[GRT]sys.LIS;
-RMS-E-FNF, file not found
GRT job terminated at 31-MAY-2024 11:35:54.93

Accounting information:
Buffered I/O count: 183 Peak working set size: 5312
Direct I/O count: 50 Peak virtual size: 225616
Page faults: 405 Mounted volumes: 0
Charged CPU time: 0 00:00:00.06 Elapsed time: 0 00:00:00.11

And for completeness
pipe ssh grt@vms0 "type sys$input " < x0.txt
or
pipe type x0.txt | ssh grt@vms0 "type sys$input "

Welcome to OpenVMS (TM) x86_64 Operating System, Version V9.2-2

grt@10.10.10.12's password:
Which appears to request the terminal for input, not the file, and ^z will terminate the session.

Which leads to a followup issue/question, see response

Added in 8 minutes 56 seconds:
The follow on issues

Device buffer size
The ssh command processing on VMS uses an FTA device, a terminal. The maximum default buffer size is 511, which is a hangover from the 1980's.
Using a pipe to move data we may nee to move from that 512 bytes (RMS uses blocks so 511 is translated to 512 bytes)
however pipe (MP device) uses a default buffer size of 4096 which would be much more useful.

Ideally the FT device for Telnet and ssh should use a default buffer size based on the type-ahead buffer size as set on sysgen, or the same as pipe (MP) 4096, or even the socket buffer size as set in tcpip.

SSH$CMDRUN
A it of a hack, as sys$input and sys$command are not define for dcl to be able to use directly, nor is there a device easily usable to access that represents the FT device, e.g. TT or may I suggest ssh$input ssh$output ssh$command if the dcl sys$* are not available, otherwise set up and environment that does have those in place.

Added in 26 minutes 20 seconds:
Oops

My ubuntu examples are wrong
Forgot to escape the $
Will post example later

Added in 44 minutes 3 seconds:
ssh grt@vms0 "type sys\$input " < x0.txt

no data comming back

ty ssh$cmdrun.log
%TYPE-W-READERR, error reading _V922$FTA215:[].;
-RMS-F-RER, file read error
-SYSTEM-F-HANGUP, data set hang-up
%RMS-E-DNR, device not ready, not mounted, or unavailable

Added in 4 minutes 14 seconds:
and going from vms to ubuntu

pipe ssh greg@tssu1 "cat /dev/stdin " < x0.txt

^Ceg@tssu1's password:

ssh_dispatch_run_fatal: Connection to 10.10.10.11 port 0: string is too large
%TCPIP-F-SSH_FATAL, non-specific fatal error condition
%NONAME-F-NOMSG, Message number 0764CFBC
\greg@tssu1 "cat /dev/stdin "\

NB from windows to ubuntu works fine

[cct]

You need to pass the pipe command as well to VMS.

From Debian to a current X86_64 VMS

Code: Select all

 $ ssh townleyc@VMS1 'pipe dir login.com > x.x5 '

 Welcome to VMS1

 Please note that access to this system is subject to the
 Computer Misuse Act 1990, as amended

$ ssh townleyc@VMS1 dir x

 Welcome to VMS1

 Please note that access to this system is subject to the
 Computer Misuse Act 1990, as amended

Directory DKA100:[TOWNLEYC]

X.X;1                                   22  12-MAY-2024 16:06:01.20
X.X5;1                                   2  31-MAY-2024 12:02:35.37

Total of 2 files, 24 blocks.

 

[greg@tssolutions.com.au]

Hi Chris

Am not trying to use pipe on vms, can do that, am trying to pipe a stream to ssh to be used on vms, and have the results piped elsewhere on the client.

Likewise using vms as the client to send a steam to a server and use the response stream.

[greg@tssolutions.com.au]

Is there a pointer to the git repository for ssh on vms?

[arne_v]

Is there a pointer to the git repository for ssh on vms?

I don't see it here:
https://github.com/orgs/vmssoftware/rep ... s?type=all
so probably not.

[greg@tssolutions.com.au]

So after some investigation, and NO access to the source as such.

If a command is supplied then ssh$root:[bin]ssh$runcmd.com is run. This .com needs some work, first define sys$input is no good if you don't have a open DCL file with it, so replace
$ ALLOCATE/NOLOG 'SSHD$INPUT_OUTPUT' SSHD$INPUT_OUTPUT
with
$ open/read/write SSHD$INPUT_OUTPUT 'SSHD$INPUT_OUTPUT'
NB this does not work as the input stream seems to be flushed.

If no command is supplied then a terminal session is started, however the input stream seems to be flushed.

Any chance of getting a pointer to the source?

[martinv]

Re: ALLOCATEing vs OPENing SSHD$INPUT_OUTPUT: I think the device behind SYS$NET (a pseudo-terminal) is open by default, though documentation on this logical mostly refers to DECnet task-to-task communication.