Sorry for the delay. Holidays and family and friends and such. Ahhh...
It's been a minute, but I used SSH to carry PPP traffic back in the day.
The client side PPPD ran 'ssh' as a child process, arranging stdin and
stdout, as if it was a dial-up modem.
The server side ran the counterpart 'pppd' as its command. (People don't
always think about this, but you can run specific commands via SSH
rather than always getting a shell prompt.)
Once upon a time, I was told "it'll never work", but I used it regularly
before I learnt OpenVPN and never had problems.
So you wound up with two PPP processes talking to each other over SSH.
This is what I meant by "directly". It did not use-L or-R options for
TCP via the SSH tunnel. This is how RSYNC uses SSH even now.
Regarding your "ssh -L ...", non-standard ports are easier. (And -L
means something else. See below.)
ssh user@host:/port /
And-L means "local TCP listener" (traffic to be forwarded to the other
end), while-R means "remote TCP listener" (remote connections conveyed
back to the client end).
Clarification on -L and -R ...
-L 1234:192.168.1.1:4321
in English means "listen locally on TCP port 1234 and send that traffic
to 192.168.1.1 on the remote end at port 4321.
-R 2345:192.168.3.3:5432
in English means "listen on the remote end at TCP port 2345 and send
that traffic to 192.168.3.3 on this end at port 5432.
-- R; <><
On 12/29/23 21:47, kekronbekron wrote:
Thanks Rick.
This is the part I don't follow... "You can use SSH directly (with client invoking
SSH to launch a service program on the target)".
Is it possible to make a simple example?
User A at Machine A wants to connect via port 4321 to machine B port 22, and
it's just good old SSH connectivity.
I don't understand the "encrypt a connection" part.
Meaning, SSH-ing into machines is well known and there's encryption etc.
Correct me if I'm wrong but I think "ssh -L ..." is just to get to SSH on a
target machine via a non-standard port?
On Friday, December 29th, 2023 at 20:35, Rick Troth<tro...@gmail.com> wrote:
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 trothtro...@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, frankswarbrickfrank.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 emailtolists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send emailtolists...@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 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 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
