Viewing SSH users on VMS

[Chris Townley]

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?

[Craig A. Berry]

Post by Chris Townley
On AXP ssh uses show as FT terminals, and the source can be seen, and
$ 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
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!
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
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.

[Arne Vajhøj]

Post by Craig A. Berry

Post by Chris Townley
On AXP ssh uses show as FT terminals, and the source can be seen, and
$ 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
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!
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
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.

Seems very likely.

OpenSSH is *nix code, so it does not set that thing in the
original code.

VSI obvious can and probably should add it to the VMS port.

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
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.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Chris Townley]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

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

[Arne Vajhøj]

Post by Chris Townley

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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.

Arne

[Craig A. Berry]

Post by Arne Vajhøj

Post by Chris Townley

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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.

It takes a lot more resources to have ongoing involvement with upstream
than it does to do a drive-by port that gets updated in a year or three
(or longer). The latter is how all of DEC/Compaq/HP(E)/VSI have usually
done things, and it has led to some awfully stale products being the
best available.

Post by Arne Vajhøj

Post by Chris Townley

Post by Arne Vajhøj
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.

[Scott Dorsey]

Post by Craig A. Berry
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.
--scott

[Craig A. Berry]

Post by Scott Dorsey

Post by Craig A. Berry
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.

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.

[Lawrence D'Oliveiro]

Post by Craig A. Berry
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.

[Craig A. Berry]

Post by Lawrence D'Oliveiro

Post by Craig A. Berry
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.

[Simon Clubley]

Post by Craig A. Berry

Post by Lawrence D'Oliveiro

Post by Craig A. Berry
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.

You are correct. I remember the attitude of "stripping out all the
junk and getting back to this pure product".

I did find the following pages with a quick search and which compare the two:

https://subscription.packtpub.com/book/security/9781800560345/2/ch02lvl1sec10/comparing-openssl-with-libressl
https://news.ycombinator.com/item?id=25346355

Simon.

[Hunter Goatley]

Post by Craig A. Berry

Post by Lawrence D'Oliveiro
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.

Hunter
------
Hunter Goatley, Process Software, https://www.process.com/

[Lawrence D'Oliveiro]

Post by Hunter Goatley
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.

30 years ago would also have been when the Linux folks tried to do the
same sort of thing, with their libc patches. And they were ignored, too.

They got their revenge by being so spectacularly successful, the GNU folks
were ultimately forced to embrace them. And so we had the transition from
the Linux-specific libc5 fork to the GNU-official libc6.

[Gary Sparkes]

Post by Chris Townley

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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.
Arne

One concern I have had as of late is the lack of even just a published
source tarball for some of these projects - which are GPL licensed.

I'm told that part of the reason they don't just blast it up on github is
they don't have the resources/people to manage external pull requests and
the like - which sounds entirely bogus to me. Microsoft has dumped tons of
historic source code on github and set the project repo to "archive" mode
which means it's read only and no one can submit any requests, post
anything, open issues, etc - effectively just publishing a source tarball
on a download link without having to host it or pay for the resources
yourself.

Supposedly you can email them and ask, and receive the source that way,
but that's a bit of a burden and very redhat-esque (Except in red hat's
case, you can get access to bulk download SRPMs for free after jumping
through some hoops).

I'd think doing something like that would ease all of my concerns
regarding licensing entirely - nevermind the chance to study some of the
differences and methods used for porting the software in the first place
that could be applied to other projects/software......

[Chris Townley]

Post by Craig A. Berry

Post by Chris Townley
On AXP ssh uses show as FT terminals, and the source can be seen, and
$ 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
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!
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
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

[Mark Daniel]

Post by Chris Townley

Post by Craig A. Berry

Post by Chris Townley
On AXP ssh uses show as FT terminals, and the source can be seen, and
$ 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
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!
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
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

WASD's DCLinabox does this on (VSI) Alpha and Itanium.

Post by Chris Townley
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

Does NOT WORK under:

X86VMS$ cc/version
VSI C x86-64 V7.5-009 (GEM 50XBR) on OpenVMS x86_64 V9.2-2

Perhaps some x86 VMS infrastructure missing, DCLinabox code revision
needed, ... ? (Apart from this haven't delved in inner modes at all.)

[Lawrence D'Oliveiro]

Post by Mark Daniel
Perhaps some x86 VMS infrastructure missing, DCLinabox code revision
needed, ... ?

Not only has that code not been revised in a while, seems like the server
it’s on has suffered some bitrot <https://wasd.vsm.com.au/cgi-bin/liner/>.

Does it do client-side SSL/TLS verification? That would be a good way of
locking things down further. At a quick glance, the answer is no.

[David Jones]

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
$ 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
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!
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
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).

[Chris Townley]

Post by David Jones

Post by Chris Townley
On AXP ssh uses show as FT terminals, and the source can be seen, and
$ 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
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!
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
Any ideas how I could get this information?

The best I could do was make my personal finger program do this for
                          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)
--------------------------------------------------------------------------------
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).

Thanks, that is interesting. Of course in the past the source node, and
user was put into the terminals TT_ACCPORNAM, so easy to get.

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?

[Chris Townley]

On 31/07/2024 17:31, Chris Townley wrote:

<snip>

Post by Chris Townley
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?

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.

[David Jones]

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.

[Chris Townley]

Post by David Jones

Post by Chris Townley
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.

So I could create a 'run' file with these - the remote user is already
available to the SSHDxx_BGnnn process.

I will see where I can slot it in!

[Dennis Boone]

Post by David Jones
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.

SSH privilege separation?

De

[bill]

Post by David Jones

Post by Chris Townley
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?

bill

[Robert A. Brooks]

Post by bill

Post by David Jones

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?

No.

[bill]

Post by bill

Post by David Jones

Post by Chris Townley
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?

 No.

OK. I guess it was just wishful thinking. :-)

bill

[Lawrence D'Oliveiro]

Post by bill

Post by bill
Could that be that VMS either does or intended SSH to be usable over
DECNET where there would not have been an IP address?

 No.

OK. I guess it was just wishful thinking. :-)

What kind of person wishes they could use DECnet? ;)

[Dave Froble]

Post by Lawrence D'Oliveiro

Post by bill

Post by bill
Could that be that VMS either does or intended SSH to be usable over
DECNET where there would not have been an IP address?

No.

OK. I guess it was just wishful thinking. :-)

What kind of person wishes they could use DECnet? ;)

A person who has his VAXstation 4000 Model 90A disks backup to a disk on his
AlphaServer 800 every morning at 4:00 AM. It just works.

[Simon Clubley]

Post by Lawrence D'Oliveiro

Post by bill

Post by bill
Could that be that VMS either does or intended SSH to be usable over
DECNET where there would not have been an IP address?

 No.

OK. I guess it was just wishful thinking. :-)

What kind of person wishes they could use DECnet? ;)

Don't ask Lawrence. :-) There are way too many people around here
who seem to think it's still OK to use DECnet these days...

I don't know if you saw the postings, but I actually found some
dodgy stuff in DECnet Phase IV a couple of years ago. Things that
were not immediately obviously exploitable, but stuff that still
should not be there, such as a fully-privileged EVL or the ability
to crash EVL remotely using a malformed packet.

I wonder if VSI ever got around to fixing the list of DECnet Phase IV
issues I sent them. I am assuming not because I never heard anything
back from them to say they had fixed them.

Simon.

[David Jones]

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!

25 years ago, Brian Schenkenberger made a nice hack that made FTAxxx device
UCBs be 64 bytes larger and let privileged processes set the TT_ACCPORNAM field
for those terminals (using the extra space to store the string). I tried
building that code last year on X86 but it failed because the conditional tests
in the VAX Macro source assume 'not Alpha' means 'VAX'.

To try to get it to work, I fudged the architecture tests and fixed some other
things it complained about and amazingly it worked! My goal now it to make a
privileged program that SYLOGIN runs that retrieves SYS$REM_NODE and sets
tt_accpornam. The tt_accpornam zap isn't robust yet because you're supposed to
use LIB$LOCK_IMAGE() now.

[David Jones]

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

[Chris Townley]

Post by David Jones

... 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
https://drive.google.com/file/d/1O90bqUEWTa6NnyIfLlkb05RvQwfQu9q4/view?usp=sharing

Dave

Thanks, I will take a look