On AXP ssh uses show as FT terminals, and the source can be seen, and accessed using the DVI code TT_ACCPORNAM. for example on AXP I see:
$ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:24:48.74
Total number of users = 2, number of processes = 2
Username Process Name PID Terminal
SYSTEM SYS_SYSTEM_01 0000012B OPA0:
TOWNLEYC CCT_TOWNLEYC_01 0000012A FTA1:(ssh/merlin.fritz.box:50407)
However on X86 TT_ACPORNAM is blank, and I can find no method of seeing
where they come from. OK it is probably me as it is always local, so it
is perhaps not that important. But I do like a challenge!
Currently I just see:
1 $ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:29:41.86
Total number of users = 2, number of processes = 5
Username Process Name PID Terminal
SYSTEM SYSTEM 00000431 OPA0:
TOWNLEYC FTA12_TOWNLEYC 0000044C FTA12:
TOWNLEYC FTA13_TOWNLEYC 0000044E FTA13:
TOWNLEYC FTA14_TOWNLEYC 00000450 FTA14:
TOWNLEYC TOWNLEYC 00000448 FTA11:
Any ideas how I could get this information?
On 7/27/24 12:34 PM, Chris Townley wrote:
On AXP ssh uses show as FT terminals, and the source can be seen, and
accessed using the DVI code TT_ACCPORNAM. for example on AXP I see:
$ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:24:48.74
Total number of users = 2, number of processes = 2
Username Process Name PID Terminal
SYSTEM SYS_SYSTEM_01 0000012B OPA0:
TOWNLEYC CCT_TOWNLEYC_01 0000012A FTA1:(ssh/merlin.fritz.box:50407)
However on X86 TT_ACPORNAM is blank, and I can find no method of
seeing where they come from. OK it is probably me as it is always
local, so it is perhaps not that important. But I do like a challenge!
Currently I just see:
1 $ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:29:41.86
Total number of users = 2, number of processes = 5
Username Process Name PID Terminal
SYSTEM SYSTEM 00000431 OPA0:
TOWNLEYC FTA12_TOWNLEYC 0000044C FTA12:
TOWNLEYC FTA13_TOWNLEYC 0000044E FTA13:
TOWNLEYC FTA14_TOWNLEYC 00000450 FTA14:
TOWNLEYC TOWNLEYC 00000448 FTA11:
Any ideas how I could get this information?
I don't know, but I suspect the difference is OpenSSH versus the old
TCP/IP services SSH rather than platform.
On 7/27/24 12:34 PM, Chris Townley wrote:
On AXP ssh uses show as FT terminals, and the source can be seen, and
accessed using the DVI code TT_ACCPORNAM. for example on AXP I see:
$ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:24:48.74
Total number of users = 2, number of processes = 2
Username Process Name PID Terminal
SYSTEM SYS_SYSTEM_01 0000012B OPA0:
TOWNLEYC CCT_TOWNLEYC_01 0000012A FTA1:(ssh/merlin.fritz.box:50407)
However on X86 TT_ACPORNAM is blank, and I can find no method of
seeing where they come from. OK it is probably me as it is always
local, so it is perhaps not that important. But I do like a challenge!
Currently I just see:
1 $ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:29:41.86
Total number of users = 2, number of processes = 5
Username Process Name PID Terminal
SYSTEM SYSTEM 00000431 OPA0:
TOWNLEYC FTA12_TOWNLEYC 0000044C FTA12:
TOWNLEYC FTA13_TOWNLEYC 0000044E FTA13:
TOWNLEYC FTA14_TOWNLEYC 00000450 FTA14:
TOWNLEYC TOWNLEYC 00000448 FTA11:
Any ideas how I could get this information?
I don't know, but I suspect the difference is OpenSSH versus the old
TCP/IP services SSH rather than platform.
On Sat, 27 Jul 2024 16:58:34 -0400, Arne Vajhøj wrote:
VSI obvious can and probably should add it to the VMS port.
For “port” read “fork”.
Unless these sorts of changes get accepted upstream, you end up with the burden of maintaining your own parallel version, and keeping up with
upstream developments.
Somehow, I don’t think they have the resources for that.
On 7/27/2024 6:36 PM, Lawrence D'Oliveiro wrote:
On Sat, 27 Jul 2024 16:58:34 -0400, Arne Vajhøj wrote:
VSI obvious can and probably should add it to the VMS port.
For “port” read “fork”.
Unless these sorts of changes get accepted upstream, you end up with the
burden of maintaining your own parallel version, and keeping up with
upstream developments.
Somehow, I don’t think they have the resources for that.
For a product that is important security wise it makes
sense to keep up.
And I don't think it should be that bad. 30 years ago one
would create and reapply diffs. Today I believe Git can handle
it.
Arne
VSI obvious can and probably should add it to the VMS port.
On 27/07/2024 21:54, Craig A. Berry wrote:
On 7/27/24 12:34 PM, Chris Townley wrote:
On AXP ssh uses show as FT terminals, and the source can be seen, and
accessed using the DVI code TT_ACCPORNAM. for example on AXP I see:
$ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:24:48.74
Total number of users = 2, number of processes = 2
Username Process Name PID Terminal
SYSTEM SYS_SYSTEM_01 0000012B OPA0:
TOWNLEYC CCT_TOWNLEYC_01 0000012A FTA1:(ssh/merlin.fritz.box:50407) >>>
However on X86 TT_ACPORNAM is blank, and I can find no method of
seeing where they come from. OK it is probably me as it is always
local, so it is perhaps not that important. But I do like a challenge!
Currently I just see:
1 $ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:29:41.86
Total number of users = 2, number of processes = 5
Username Process Name PID Terminal
SYSTEM SYSTEM 00000431 OPA0:
TOWNLEYC FTA12_TOWNLEYC 0000044C FTA12:
TOWNLEYC FTA13_TOWNLEYC 0000044E FTA13:
TOWNLEYC FTA14_TOWNLEYC 00000450 FTA14:
TOWNLEYC TOWNLEYC 00000448 FTA11:
Any ideas how I could get this information?
I don't know, but I suspect the difference is OpenSSH versus the old
TCP/IP services SSH rather than platform.
Possibly. Actually my AXP instance uses TCPWare, but I distinctly
remember using TCP/IP Services on I64 at work, and on my AXP machine
here before I upgraded to the VSI version. The odd one out is definitely
X86
https://wasd.vsm.com.au/cgi-bin/liner/wasd_root/src/dclinabox/dclinabox.c#78 https://wasd.vsm.com.au/cgi-bin/liner/wasd_root/src/dclinabox/dclinabox.c#2814
https://wasd.vsm.com.au/cgi-bin/liner/wasd_root/src/dclinabox/dclinabox.c#2868
On 28/07/2024 00:03, Arne Vajhøj wrote:
On 7/27/2024 6:36 PM, Lawrence D'Oliveiro wrote:
On Sat, 27 Jul 2024 16:58:34 -0400, Arne Vajhøj wrote:
VSI obvious can and probably should add it to the VMS port.
For “port” read “fork”.
Unless these sorts of changes get accepted upstream, you end up with the >>> burden of maintaining your own parallel version, and keeping up with
upstream developments.
Somehow, I don’t think they have the resources for that.
For a product that is important security wise it makes
sense to keep up.
And I don't think it should be that bad. 30 years ago one
would create and reapply diffs. Today I believe Git can handle
it.
It does worry me a bit that VSI are making their own versions of these packages, rather than putting them back into the packages as VMS
variants, that they will maintain within the package. Surely that would
imply commitment to the package, as well as the platform
Perhaps some x86 VMS infrastructure missing, DCLinabox code revision
needed, ... ?
On 7/27/2024 7:13 PM, Chris Townley wrote:
On 28/07/2024 00:03, Arne Vajhøj wrote:
On 7/27/2024 6:36 PM, Lawrence D'Oliveiro wrote:
On Sat, 27 Jul 2024 16:58:34 -0400, Arne Vajhøj wrote:
VSI obvious can and probably should add it to the VMS port.
For “port” read “fork”.
Unless these sorts of changes get accepted upstream, you end up with
the
burden of maintaining your own parallel version, and keeping up with
upstream developments.
Somehow, I don’t think they have the resources for that.
For a product that is important security wise it makes
sense to keep up.
And I don't think it should be that bad. 30 years ago one
would create and reapply diffs. Today I believe Git can handle
it.
It does worry me a bit that VSI are making their own versions of these
packages, rather than putting them back into the packages as VMS
variants, that they will maintain within the package. Surely that
would imply commitment to the package, as well as the platform
It makes sense for VSI to provide builds of something like
OpenSSH and ship with VMS. It is expected functionality
and "go get something from the internet" may not work well
for all VMS customers.
Ideally the VMS changes should be sent upstream so that VMS
is an out-of-the-box supported platform.
But there can be many reasons why that may not have happened.
Maybe VSI did not prioritize it. Maybe the upstream
project rejected the VMS changes.
My understanding is that VMS support and upstream projects
are not always easy. Sometimes it requires diplomacy at a
high level.
But VSI should definitely try.
I believe they have said (unofficially) they will do that for LLVM and
have had good interactions with the upstream developers at conferences
and what-not. I haven't seen statements for other products. For >security-related things like OpenSSL and OpenSSH they do need to be able
to incorporate and release updates quickly, which would be a lot easier
if they stayed up-to-date and had continuous builds running so
everything was already ready-to-go when a critical fix comes along.
Craig A. Berry <craigberry@nospam.mac.com> wrote:
I believe they have said (unofficially) they will do that for LLVM and
have had good interactions with the upstream developers at conferences
and what-not. I haven't seen statements for other products. For
security-related things like OpenSSL and OpenSSH they do need to be able
to incorporate and release updates quickly, which would be a lot easier
if they stayed up-to-date and had continuous builds running so
everything was already ready-to-go when a critical fix comes along.
OpenSSH is kind of a special case since it was not too long ago they
they, with great fanfare, stripped out a lot of code from their
distribution including the VMS support.
On Sun, 28 Jul 2024 09:04:01 -0500, Craig A. Berry wrote:
I don't think there was any long-standing VMS support in OpenSSH. Maybe
you are thinking of LibreSSL, which jettisoned a lot of things,
including anything VMS-specific, when it forked from OpenSSL.
There is only one reason why an open-source project might drop support for
a platform: because they can’t find any contributors willing to maintain it.
I don't think there was any long-standing VMS support in OpenSSH. Maybe
you are thinking of LibreSSL, which jettisoned a lot of things,
including anything VMS-specific, when it forked from OpenSSL.
On 7/28/24 7:28 PM, Lawrence D'Oliveiro wrote:
On Sun, 28 Jul 2024 09:04:01 -0500, Craig A. Berry wrote:
I don't think there was any long-standing VMS support in OpenSSH. Maybe >>> you are thinking of LibreSSL, which jettisoned a lot of things,
including anything VMS-specific, when it forked from OpenSSL.
There is only one reason why an open-source project might drop support for >> a platform: because they can?t find any contributors willing to maintain
it.
That was not a reason for what LibreSSL did.
On 7/28/24 7:28 PM, Lawrence D'Oliveiro wrote:
There is only one reason why an open-source project might drop support
for
a platform: because they can’t find any contributors willing to maintain >> it.
That was not a reason for what LibreSSL did.
Nor was it the reason 30 years ago when I tried repeatedly to feed my
VMS changes back to GNU sed and GNU grep. They clearly were not
interested in my changes, as they initially declined, then later
ignored, my attempts, and I eventually stopped trying.
On 7/27/2024 1:34 PM, Chris Townley wrote:
On AXP ssh uses show as FT terminals, and the source can be seen, and
accessed using the DVI code TT_ACCPORNAM. for example on AXP I see:
$ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:24:48.74
Total number of users = 2, number of processes = 2
Username Process Name PID Terminal
SYSTEM SYS_SYSTEM_01 0000012B OPA0:
TOWNLEYC CCT_TOWNLEYC_01 0000012A FTA1:(ssh/merlin.fritz.box:50407)
However on X86 TT_ACPORNAM is blank, and I can find no method of
seeing where they come from. OK it is probably me as it is always
local, so it is perhaps not that important. But I do like a challenge!
Currently I just see:
1 $ sh u /f/i
OpenVMS User Processes at 27-JUL-2024 18:29:41.86
Total number of users = 2, number of processes = 5
Username Process Name PID Terminal
SYSTEM SYSTEM 00000431 OPA0:
TOWNLEYC FTA12_TOWNLEYC 0000044C FTA12:
TOWNLEYC FTA13_TOWNLEYC 0000044E FTA13:
TOWNLEYC FTA14_TOWNLEYC 00000450 FTA14:
TOWNLEYC TOWNLEYC 00000448 FTA11:
Any ideas how I could get this information?
The best I could do was make my personal finger program do this for
SSH connections (terminal FTA1):
FINGER Version 4.9
Wed 31-JUL-2024 09:18 HOBBY:: Up Since Fri
26-JUL-2024 00:36
Job counts: Interactive = 5, Network = 4, Detached = 3
Username Name Image Line Location
---------- -------------------- ------------ ------- -------------------------
JONESD David Jones < DCL > FTA1: PTY (SSHD22_BG7584)
"" TCPIP$UCP VTA1: Host:
192.168.1.55 Port:
"" < DCL > VTA2: Host:
192.168.1.55 Port:
"" < DCL > OPA0: Unknown for OPA0:
"" finger_x86 VTA3: Host:
192.168.1.179 Port: --------------------------------------------------------------------------------
It uses $GETDVI to get the LOCKID value for the terminal, which the PTY driver
re-purposes to hold the ipid of that pseudoterminal's control process.
It then
calls EXE$IPID_TO_EPID from exec mode to get an epid we can use with
$GETJPI to
fetch its process name (SSHD22_BG7584). I never found a way to get the
remote
connect information from the name of the TCPIP device (assuming the
process name
reliably reflected it).
On 7/31/2024 2:36 PM, Chris Townley wrote:
On 31/07/2024 17:31, Chris Townley wrote:
Interestingly SYS$REM_NODE and SYS$REM_NODE_FULLNAME are both set to
the remote IP address, but SYS$REM_ID is set to the local, not the
remote username.
Equally interesting: the SSHDxx_BGnnn process that controls the PTY has SYS$REM_NODE/SYS$REM_NODE_FULLNAME
set to the actual hostname of the remote host instead of the IP address. SYS$REM_ID is set to SSH$SSH.
What I have discovered, which could make getting the parent PID
unnecessary, is that a log file is created in SSH$ROOT:[VAR] named either
<this_hostname>_<remote host or IP address>_<process_PID>.log
or
<remote host or IP address>_<process_PID>.log
but unless the login fails, nothing is written.
No idea why or when which form is used.
Can I presume that a PID will be unique until a system reboot? If so I
could delete/rename these logs at system startup, then look for the
file, at least to get the remote node, and add to the process name.
Otherwise maybe I cold hack the client startup to create a readable file
with remote node and user?
Equally interesting: the SSHDxx_BGnnn process that controls the PTY has SYS$REM_NODE/SYS$REM_NODE_FULLNAME set to the actual hostname of the
remote host instead of the IP address.
On 7/31/2024 3:40 PM, David Jones wrote:No.
On 7/31/2024 2:36 PM, Chris Townley wrote:
On 31/07/2024 17:31, Chris Townley wrote:
Interestingly SYS$REM_NODE and SYS$REM_NODE_FULLNAME are both set to the remote IP address, but SYS$REM_ID is set to the local, not the remote username.
Equally interesting: the SSHDxx_BGnnn process that controls the PTY has SYS$REM_NODE/SYS$REM_NODE_FULLNAME
set to the actual hostname of the remote host instead of the IP address. SYS$REM_ID is set to SSH$SSH.
Could that be that VMS either does or intended SSH to be usable over
DECNET where there would not have been an IP address?
On 8/1/2024 9:33 AM, Robert A. Brooks wrote:
On 8/1/2024 8:15 AM, bill wrote:
No.
Could that be that VMS either does or intended SSH to be usable over
DECNET where there would not have been an IP address?
OK. I guess it was just wishful thinking. :-)
On Thu, 1 Aug 2024 12:17:00 -0400, bill wrote:
On 8/1/2024 9:33 AM, Robert A. Brooks wrote:
On 8/1/2024 8:15 AM, bill wrote:
No.
Could that be that VMS either does or intended SSH to be usable over
DECNET where there would not have been an IP address?
OK. I guess it was just wishful thinking. :-)
What kind of person wishes they could use DECnet? ;)
On 8/2/2024 11:52 AM, David Jones wrote:
... My goal now it to make a
privileged program that SYLOGIN runs that retrieves SYS$REM_NODE and sets
tt_accpornam.
I built an ssh_set_location program base around ft_accpornam.mar exported functions (FTA_INITIALIZE(),FTA_SET_ACCPORNAM) and rewrote ft_accpornam in
C. There's no VAX support for the C version, but it's slightly incredible that the same inner mode code works on both Alpha and x86_84 (the host I
use to test IA64 appears be down).
The location it reports is the login process's sys$rem_node translation.
It would be nice if I could get the port number. As I recall, unless a
BG device is marked SHARE, attempts to do I/O from anything but the
owner process immediately shuts down the connection.
As programs go, it's pretty short. If you want to inspect it, I've
made a zip file available on my google drive:
https://drive.google.com/file/d/1O90bqUEWTa6NnyIfLlkb05RvQwfQu9q4/view?usp=sharing
Dave
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 437 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 193:30:28 |
| Calls: | 9,135 |
| Calls today: | 2 |
| Files: | 13,432 |
| Messages: | 6,035,422 |