Re: SSH tunneling for unattended process.

[Kirk Wolf]

"You may wonder why you might need -R. The SSH command exposes identification 
(e.g. userid & password). -L exposes a z/OS userid & password on each TN3270 
computer which is not easily protected. -R exposes Unix/Windows userid/password 
on z/OS where you can fully protect them in 1 location and easily restrict 
access."

I'm sorry that it went that way, but referring to Jon's statement above I 
simply asked how -L  exposes userid and password. Jon redirected the 
question to a discussion of storing passwords in script files.   Of course we 
can all agree that that is a problem, but it wasn't the issue.

PS> I tunnel tn3270 in ssh all the time, and I never store any passwords in 
files or scripts or pass them in command lines.

Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.com

On Thu, Jan 11, 2024, at 1:42 PM, Rick Troth wrote:
> bottom posting ... refreshing ... sincerely
> 
> 
> On 1/11/24 14:08, Jon Perryman wrote:
> > On Thu, 11 Jan 2024 09:47:45 -0600, Kirk Wolf  wrote:
> >
> >> Did I say anything about using passwords for ssh?
> >> Again, this has nothing to do with your assertion that
> >> using tn3270 over a ssh tunnel would expose the userid and password.
> > This thread is specifically about using ssh tunnel to provide SSL for 
> > non-SSL TCP apps. TN3270 (without enabling SSL) is being used for context 
> > that everyone in this group understands.
> >
> > You ask how I would get your TSO userid / password when you run TN3270 thru 
> > an ssh tunnel. Very simply, the userid & password would likely be the same 
> > for both. Assuming you automated ssh with userid & password exposed, I just 
> > look at your script.
> 
> 
> I don't understand the strife.
> It's true that we normally go username/password for 3270 sign-on.
> It's also true that we *can* sign-on using username/password with SSH. 
> But the latter is not recommended when you have SSH keys. And the 
> subject is "unattended" where keys would be *very* desirable.
> 
> 
> -- R; <><
> 
> --
> 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

Re: SSH tunneling for unattended process.

[Rick Troth]

bottom posting ... refreshing ... sincerely


On 1/11/24 14:08, Jon Perryman wrote:

On Thu, 11 Jan 2024 09:47:45 -0600, Kirk Wolf  wrote:


Did I say anything about using passwords for ssh?
Again, this has nothing to do with your assertion that
using tn3270 over a ssh tunnel would expose the userid and password.

This thread is specifically about using ssh tunnel to provide SSL for non-SSL 
TCP apps. TN3270 (without enabling SSL) is being used for context that everyone 
in this group understands.

You ask how I would get your TSO userid / password when you run TN3270 thru an ssh 
tunnel. Very simply, the userid & password would likely be the same for both. 
Assuming you automated ssh with userid & password exposed, I just look at your 
script.



I don't understand the strife.
It's true that we normally go username/password for 3270 sign-on.
It's also true that we *can* sign-on using username/password with SSH. 
But the latter is not recommended when you have SSH keys. And the 
subject is "unattended" where keys would be *very* desirable.



-- R; <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Thu, 11 Jan 2024 09:47:45 -0600, Kirk Wolf  wrote:

>Did I say anything about using passwords for ssh?   
>Again, this has nothing to do with your assertion that 
>using tn3270 over a ssh tunnel would expose the userid and password.

This thread is specifically about using ssh tunnel to provide SSL for non-SSL 
TCP apps. TN3270 (without enabling SSL) is being used for context that everyone 
in this group understands. 

You ask how I would get your TSO userid / password when you run TN3270 thru an 
ssh tunnel. Very simply, the userid & password would likely be the same for 
both. Assuming you automated ssh with userid & password exposed, I just look at 
your script.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Kirk Wolf]

Did I say anything about using passwords for ssh?   Again, this has nothing to 
do with your assertion that using tn3270 over a ssh tunnel would expose the 
userid and password.

Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.com

PS> I use a ssh key agent on my desktop that is unlocked by a strong password.  
No passwords are stored in any files.

On Wed, Jan 10, 2024, at 7:36 PM, Jon Perryman wrote:
> On Wed, 10 Jan 2024 11:37:11 -0600, Kirk Wolf  wrote:
> 
> >   ssh -L 623:127.0.0.1:623  zoshost
> >How EXACTLY is your userid and password exposed?
> 
> You example ignores using a script to automate SSH login. There are various 
> implementations. e.g.sshpass -p !4u2tryhack ssh usern...@host.example.com
> 
> Even IBM tells you how you can use sshpass: 
> https://www.redhat.com/sysadmin/ssh-automation-sshpass
> 
> Realize that it's not just sysadmins using it. 
> 
> --
> 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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Thu, 11 Jan 2024 13:03:07 +1100, Filip Palian  wrote:

>Passing secret material in the command line for long-running and daemon
>processes is never a good idea [;

I'm not condoning this an as you say, this isn't a good idea but my point was 
it's a common practice in the UNIX and Windows environment. There are decent 
solutions but unlike z/OS programmers, UNIX programmers are jack of all trades 
(security, performance and ???) who make their own decisions.  

I only brought this up because of the use cases for SSH -R option is not 
obvious.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Filip Palian]

Passing secret material in the command line for long-running and daemon
processes is never a good idea [;

"The sshpass utility is designed to run SSH using the keyboard-interactive
password authentication mode, but in a non-interactive way." - recommended
approach is to use key authentication instead (i.e., SSH(1) -
https://man.openbsd.org/ssh#i).


Cheers,
FP

czw., 11 sty 2024 o 12:36 Jon Perryman  napisał(a):

> On Wed, 10 Jan 2024 11:37:11 -0600, Kirk Wolf  wrote:
>
> >   ssh -L 623:127.0.0.1:623  zoshost
> >How EXACTLY is your userid and password exposed?
>
> You example ignores using a script to automate SSH login. There are
> various implementations. e.g.sshpass -p !4u2tryhack ssh
> usern...@host.example.com
>
> Even IBM tells you how you can use sshpass:
> https://www.redhat.com/sysadmin/ssh-automation-sshpass
>
> Realize that it's not just sysadmins using it.
>
> --
> 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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Wed, 10 Jan 2024 11:37:11 -0600, Kirk Wolf  wrote:

>   ssh -L 623:127.0.0.1:623  zoshost
>How EXACTLY is your userid and password exposed?

You example ignores using a script to automate SSH login. There are various 
implementations. e.g.sshpass -p !4u2tryhack ssh usern...@host.example.com

Even IBM tells you how you can use sshpass: 
https://www.redhat.com/sysadmin/ssh-automation-sshpass

Realize that it's not just sysadmins using it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Kirk Wolf]

Jon, 

I don't think you answered my question.

If on your client you set up a TN3270 tunnel with:   
   ssh -L 623:127.0.0.1:623  zoshost
and then connect your tn3270 client to port localhost:623  and login

How EXACTLY is your userid and password exposed?

Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.com

On Tue, Jan 9, 2024, at 10:18 PM, Jon Perryman wrote:
> On Tue, 9 Jan 2024 20:18:42 -0600, Kirk Wolf  wrote:
> 
> >On Tue, Jan 9, 2024, at 5:18 PM, Jon Perryman wrote:
> \>> You may wonder why you might need -R. The SSH command exposes 
> identification (e.g. userid & password).
> >> -L exposes a z/OS userid & password on each TN3270 computer which is not 
> >> easily protected. 
> >
> >Exposes how? Do you mean that traffic on one socket across the loopback 
> >adapter
> 
> Amazingly the hack is much simpler. Scan thru github for userid's / 
> passwords. There are opensource utilities that will find the most common 
> occurrences. 
> 
> Consider DB2 connect in z/OS using shared RACF, ACEE and trust for every 
> machine within the SYSPLEX. No userid / password (or some other 
> identification method is not allowed)
> 
> DB2 connect client for Linux, Windows and ??? is completely different. For 
> instance, the DB2_CONNECT for PHP is documented as follows:
> 
> db2_connect(
> string $database,
> ?string $username,
> ?string $password,
> array $options = []
> ): resource|false
> Creates a new connection to an IBM DB2 Universal Database, IBM Cloudscape, or 
> Apache Derby database.
> 
> This is a common Unix practice (not necessarily a best practice). People tend 
> to follow the documentation.
> 
> Surprisingly, some people do not sanitize their code before uploading to 
> github (or other open source repositories).  
> 
> --
> 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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Tue, 9 Jan 2024 20:18:42 -0600, Kirk Wolf  wrote:

>On Tue, Jan 9, 2024, at 5:18 PM, Jon Perryman wrote:
\>> You may wonder why you might need -R. The SSH command exposes 
identification (e.g. userid & password).
>> -L exposes a z/OS userid & password on each TN3270 computer which is not 
>> easily protected. 
>
>Exposes how? Do you mean that traffic on one socket across the loopback adapter

Amazingly the hack is much simpler. Scan thru github for userid's / passwords. 
There are opensource utilities that will find the most common occurrences. 

Consider DB2 connect in z/OS using shared RACF, ACEE and trust for every 
machine within the SYSPLEX. No userid / password (or some other identification 
method is not allowed)

DB2 connect client for Linux, Windows and ??? is completely different. For 
instance, the DB2_CONNECT for PHP is documented as follows:

db2_connect(
string $database,
?string $username,
?string $password,
array $options = []
): resource|false
Creates a new connection to an IBM DB2 Universal Database, IBM Cloudscape, or 
Apache Derby database.

This is a common Unix practice (not necessarily a best practice). People tend 
to follow the documentation.

Surprisingly, some people do not sanitize their code before uploading to github 
(or other open source repositories).  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Kirk Wolf]

On Tue, Jan 9, 2024, at 5:18 PM, Jon Perryman wrote:
> 
> You may wonder why you might need -R. The SSH command exposes identification 
> (e.g. userid & password). -L exposes a z/OS userid & password on each TN3270 
> computer which is not easily protected. -R exposes Unix/Windows 
> userid/password on z/OS where you can fully protect them in 1 location and 
> easily restrict access.
> 
> I used TN3270 as an example that is familiar to everyone in this group. But 
> this holds true for all TCP connections. Some exceptions may apply but it's 
> unlikely most people will be in those situations.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 

Exposes how? Do you mean that traffic on one socket across the loopback adapter 
can be seen by something other than the processes on the ends of the socket or 
a privileged process?
 
Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Tue, 9 Jan 2024 11:41:45 -0600, Grant Taylor  
wrote:

>This is important to keep in mind when you are considering which way the
>port forwarded traffic will go in relation to which end is the SSH client.

Tunnels are bidirectional so it does not matter which way traffic is forwarded. 
What is important is the system with the listener port (often referred to as 
server). 

>N.B. the -L and -R are reference to the ssh /client/.

This is very simple. You are moving the listener port from one computer to 
another computer. Consider TN3270 connecting to your z/OS system. You specify 
an IP address and port on TN3270 which means you want to connect to the 
listener port on z/OS.  -R means you are issuing the SSH tunnel command from 
z/OS (listener port/server machine) whereas -L means you're means you are 
issuing the SSH tunnel command from the TN3270 computer (client). Regardless of 
-R or -L, you now have the listener port on the computer where you issue the 
TN3270 command.

You may wonder why you might need -R. The SSH command exposes identification 
(e.g. userid & password). -L exposes a z/OS userid & password on each TN3270 
computer which is not easily protected. -R exposes Unix/Windows userid/password 
on z/OS where you can fully protect them in 1 location and easily restrict 
access.

I used TN3270 as an example that is familiar to everyone in this group. But 
this holds true for all TCP connections. Some exceptions may apply but it's 
unlikely most people will be in those situations.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Grant Taylor]

+10 for everything that Rick has said.

On 1/8/24 1:26 PM, Rick Troth wrote:

Clarification on -L and -R ...


N.B. the -L and -R are reference to the ssh /client/.

This is important to keep in mind when you are considering which way the 
port forwarded traffic will go in relation to which end is the SSH client.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Filip Palian]

Depending on the use case https://www.stunnel.org can also be used exactly
for this purpose.

Cheers,
FP

wt., 9 sty 2024 o 12:01 Andrew Rowley 
napisał(a):

> On 9/01/2024 6:26 am, Rick Troth wrote:
> >
> > 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.
> >
> I think this is difficult on z/OS because by default stdin and stdout
> use ASCII<->EBCDIC translation, so anything sending binary data is broken.
>
> I think you can override that, but not conveniently.
>
> --
> Andrew Rowley
> Black Hill Software
>
> --
> 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

Re: SSH tunneling for unattended process.

[Andrew Rowley]

On 9/01/2024 6:26 am, Rick Troth wrote:


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.


I think this is difficult on z/OS because by default stdin and stdout 
use ASCII<->EBCDIC translation, so anything sending binary data is broken.


I think you can override that, but not conveniently.

--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[Rick Troth]

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

Re: SSH tunneling for unattended process.

[kekronbekron]

Thank you.
You know how we sometimes only have vague understanding that somehow stays 
vague..
Your explanation below popped things into place and cleared the fog I had.
Thanks again!


On Saturday, December 30th, 2023 at 12:26, Jon Perryman  
wrote:


> On Sat, 30 Dec 2023 04:02:22 +, kekronbekron kekronbek...@protonmail.com 
> wrote:
> 
> > So SSH is used for auth and encryption,
> 
> 
> SSH has multiple features. Understand that SSH primary feature is "Secure 
> SHell" where you can issue UNIX commands on a remote UNIX system thru an 
> encrypted connection. You must login to that remote system thru SSH using one 
> of the implemented methods (e.g. userid / password). SSH is delivered on most 
> UNIX systems although it may require some configuration.
> 
> > and mainly just as a tunnel (as the first mail mentioned).
> 
> 
> Port tunneling is a second feature which I believe disables shell commands 
> (never bothered to try it). There's plenty of documentation on the internet 
> (e.g. https://linuxize.com/post/how-to-setup-ssh-tunneling/).
> 
> An unencrypted 3270 connection:
> tn3270 -host MVSsystem.com -port 3270
> 
> Encrypted 3270 connection
> ssh -L localhost:100:MVSsystem.com:3270 unix_use...@mvssystem.com
> TN3270 -host localhost -port 100
> 
> Specifying localhost is important because it limits access to his specific 
> machine. 0.0.0.0 would allow other machines to access MVSsystem.com thru this 
> machine.
> 
> The server and client can be on either side but I always used the client app 
> on the machine issuing the SSH with the server on the other machine.
> 
> > The traffic that's tunnelled may be any protocol or a TCP socket.
> 
> 
> In theory, yes but I've only used it with TCP.
> 
> > and the goal is to just use SSH's ubiquity (say port 22) to make life 
> > easier w.r.t firewalls and all that.
> 
> 
> The goal is encryption which is provided by SSH instead of building it into 
> the application. As for firewalls, I don't see how it changes anything. 
> Firewall implements NAT, filtering, proxy servers and ???. I would think that 
> implementing SSL into the client / server would be more secure.
> 
> > I wonder if spiped fits the bill - https://www.tarsnap.com/spiped.html
> 
> 
> I'm not familiar with SPIPED but from that documentation, it appears it could 
> be used for this purpose. The drawback is that you must install the client.
> 
> --
> 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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Sat, 30 Dec 2023 04:02:22 +, kekronbekron  
wrote:

>So SSH is used for auth and encryption, 

SSH has multiple features. Understand that SSH primary feature is "Secure 
SHell" where you can issue UNIX commands on a remote UNIX system thru an 
encrypted connection. You must login to that remote system thru SSH using one 
of the implemented methods (e.g. userid / password). SSH is delivered on most 
UNIX systems although it may require some configuration.

> and mainly just as a tunnel (as the first mail mentioned).

Port tunneling is a second feature which I believe disables shell commands 
(never bothered to try it). There's plenty of documentation on the internet 
(e.g. https://linuxize.com/post/how-to-setup-ssh-tunneling/).

An unencrypted 3270 connection:
tn3270 -host MVSsystem.com -port 3270 

Encrypted 3270 connection
ssh -L localhost:100:MVSsystem.com:3270 unix_use...@mvssystem.com
TN3270 -host localhost -port 100

Specifying localhost is important because it limits access to his specific 
machine. 0.0.0.0 would allow other machines to access MVSsystem.com thru this 
machine.

The server and client can be on either side but I always used the client app on 
the machine issuing the SSH with the server on the other machine. 

>The traffic that's tunnelled may be any protocol or a TCP socket.

In theory, yes but I've only used it with TCP.

> and the goal is to just use SSH's ubiquity (say port 22) to make life easier 
> w.r.t firewalls and all that.

The goal is encryption which is provided by SSH instead of building it into the 
application. As for firewalls, I don't see how it changes anything. Firewall 
implements NAT, filtering, proxy servers and ???. I would think that 
implementing SSL into the client / server would be more secure.

>I wonder if spiped fits the bill - https://www.tarsnap.com/spiped.html

 I'm not familiar with SPIPED but from that documentation, it appears it could 
be used for this purpose. The drawback is that you must install the client.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[kekronbekron]

Ah... ok.
So SSH is used for auth and encryption, and mainly just as a tunnel (as the 
first mail mentioned).
The traffic that's tunnelled may be any protocol or a TCP socket... and the 
goal is to just use SSH's ubiquity (say port 22) to make life easier w.r.t 
firewalls and all that.

Is this right?

I wonder if spiped fits the bill - https://www.tarsnap.com/spiped.html


On Saturday, December 30th, 2023 at 09:17, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:


> On Sat, 30 Dec 2023 02:47:28 +, kekronbekron wrote:
> 
> > 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?
> 
> I believe that's "ssh -oPort=" which I use regularly to get to a 
> nonstandard
> (portmapped) port.
> 
> I once knew how to use ssh to set up an encrypted connection for a 
> non-encrypted
> service, such as ftp. I no longer remember how. Perhaps see "-L" in
> https://linux.die.net/man/1/ssh
> 
> > On Friday, December 29th, 2023 at 20:35, Rick Troth 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 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
> > > > 

Re: SSH tunneling for unattended process.

[Paul Gilmartin]

On Sat, 30 Dec 2023 02:47:28 +, kekronbekron wrote:
>
>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?
> 
I believe that's "ssh -oPort=" which I use regularly to get to a nonstandard
(portmapped) port.

I once knew how to use ssh to set up an encrypted connection for a non-encrypted
service, such as ftp.  I no longer remember how.  Perhaps see "-L" in

>
>
>On Friday, December 29th, 2023 at 20:35, Rick Troth 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 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?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SSH tunneling for unattended process.

[kekronbekron]

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

Re: SSH tunneling for unattended process.

[Rick Troth]

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

Re: SSH tunneling for unattended process.

[kekronbekron]

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

Re: SSH tunneling for unattended process.

[Rick Troth]

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

andWhat’s the difference between RACDCERT MAP and RACMAP?

Colin

On Fri, 29 Dec 2023 at 06:27, Frank Swarbrick
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

Re: SSH tunneling for unattended process.

[Colin Paice]

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

andWhat’s the difference between RACDCERT MAP and RACMAP?

Colin

On Fri, 29 Dec 2023 at 06:27, Frank Swarbrick 
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 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

SSH tunneling for unattended process.

[Frank Swarbrick]

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 to lists...@listserv.ua.edu with the message: INFO IBM-MAIN