Dan O'Reilly
2007-05-31 12:56:35 UTC
Jeremy -
Sorry for the delay here. No, from the client side there's really no way
of restricting what system a client can connect with. From the server
perspective, you would use the server's restriction mechanism (e.g.,
AllowHosts/DenyHosts) to restrict access to the server.
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+
Sorry for the delay here. No, from the client side there's really no way
of restricting what system a client can connect with. From the server
perspective, you would use the server's restriction mechanism (e.g.,
AllowHosts/DenyHosts) to restrict access to the server.
Hi,
Running MultiNet 5.1 on OpenVMS Alpha V8.2.
I've been asked a question by the people at a MultiNet site I manage. They
have a requirement to provide a 3rd-party consultant with access to an
internal system (not the VMS system).
It occurred to me that one way to do this would be to create a captive
account for this consultant on VMS and then ask them to come in via SSH with
remote port forwarding to connect them through to the target system. The
site already allows SSH access through their firewall to the VMS server so
that travelling staff can log in remotely, so taking this approach would
avoid the need to change the firewall.
The problem I see in the above approach is that we need to be able to
restrict the forwarded port so that it goes *only* to the target system.
Most SSH clients allow *any* remote host and TCP port to be specified and
either port forwarding is allowed (to any specified host/port) or not at
all.
Is it possible to control the port forwarding with MultiNet in the way I
want?
Thanks,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
| "OpenVMS Systems Management & Programming" |
|---------------------------------------------------------|
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
------Running MultiNet 5.1 on OpenVMS Alpha V8.2.
I've been asked a question by the people at a MultiNet site I manage. They
have a requirement to provide a 3rd-party consultant with access to an
internal system (not the VMS system).
It occurred to me that one way to do this would be to create a captive
account for this consultant on VMS and then ask them to come in via SSH with
remote port forwarding to connect them through to the target system. The
site already allows SSH access through their firewall to the VMS server so
that travelling staff can log in remotely, so taking this approach would
avoid the need to change the firewall.
The problem I see in the above approach is that we need to be able to
restrict the forwarded port so that it goes *only* to the target system.
Most SSH clients allow *any* remote host and TCP port to be specified and
either port forwarding is allowed (to any specified host/port) or not at
all.
Is it possible to control the port forwarding with MultiNet in the way I
want?
Thanks,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
| "OpenVMS Systems Management & Programming" |
|---------------------------------------------------------|
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+