I can't speak for Frank, but he started his inquiry with this:
> We're looking at using an SSH tunnel (or reverse tunnel)to encrypt a
connection
> where the application on the other end does not support TLS.
SSH is an excellent choice for this kind of job.
You can use SSH directly (with client invoking SSH to launch a service
program on the target)
*or* you can establish one or more TCP listeners (either direction) over
an SSH session, or any combination.
ALL of the traffic handled by way of the SSH session would be encrypted.
So I might not have understood exactly what Frank needs, but I'm a firm
believer in SSH.
Authentication of the remote SSH host is done using the SSH host key(s)
on the target system. That's standard.
Authentication of the client can be done using an SSH client key (as is
my practice) or using PKI certificates (as Colin describes in his blog).
Frank indicated that what he needs is unattended/automatic, easily
supported using either method.
Does that help?
-- R; <><
On 12/29/23 09:20, kekronbekron wrote:
Hi Rick/Frank,
If you have time, could you explain more about this setup.
I don't get what's desired..
On Friday, December 29th, 2023 at 19:04, Rick Troth <tro...@gmail.com> wrote:
Hi Frank --
BT/DT and it works great.
I took the usual means of capturing the host key of the target: signed
on as the service account and ran 'ssh' interactively. Ever after, the
client would not be prompted, but it would fail if the key changed. (And
that's the point.)
The client signed on using an SSH client key. Of course, I had to break
a rule here and magically obviate the need for a pass phrase. (Dark
magic. Not something we speak about in public.)
In this particular case, I ran it from/etc/inittab on a traditional Unix
(Linux) system. That way when the session would die it would be restarted.
This hack used either -L or -R, I forget which, but established a TCP
listener. All traffic was limited to local (which is the default), so no
risk of someone off-box sending or seeing cleartext.
-- R; <><
On 12/29/23 04:53, Colin Paice wrote:
Frank,
What do you have on the z/OS end? If the back end supports it, it can map
from a certificate to a userid.
See Using certificates to logon to z/OS
https://colinpaice.blog/2023/03/28/using-certificates-to-logon-to-z-os/
andWhat’s the difference between RACDCERT MAP and RACMAP?
https://colinpaice.blog/2020/07/28/whats-the-difference-between-racdcert-map-and-racmap/
Colin
On Fri, 29 Dec 2023 at 06:27, Frank swarbrickfrank.swarbr...@outlook.com
wrote:
We're looking at using an SSH tunnel (or reverse tunnel) to encrypt a
connection where the application on the other end does not support TLS.
The POC looks to be working. I am now pondering on the steps required to
make setting up the tunnel an automated process. It seems to me that we'd
want the z/OS user to be a "protected" user
(NOPASSWORD/NOPHRASE/NOOIDCARD). Would this require that we use SSH host
based authentication? I imagine that the user would require an OMVS
segment. I wonder if it would need a shell or home directory. Any other
thoughts?
Thanks,
Frank
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
