× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott,

From previous posts, I learned that LPR was locked down to port 515. That is why I thought about creating a device, since the port can be entered.

What I see is that on my i, I would run the ssh -L oricess, listening to some specified port that was used in the created DEVD.

I think I would still need to spawn that ssh -L process to allow use of user name and password verification on the remote system, wouldn't I?

So, I think I would create a DEVD with port 21345 (for example) on local system, then the ssh command would then use 21345 instead of 7777 in your example. Also, instead of using port 515, I would use anotehr port, such as 29488 on the remote system. Assuming the firewall was allowing that port, an additional ssh -L on that system would then redirect the received data stream from 29488 to a specific IP address inside their firewall and also back to port 515.

Why do I have to go this ugly route? Private networks. Thanks to your fantastic help in the past, I was able to create a process that sends spool file data to the remote site as after copying to a PF. But, then, somebody on the other end has to deal with breaking down the report. Which is why I wanted to do the port forwarding in the first place.

I thought the process would be simple, and, except for the remote side firewall issue, it is.

Thanks for the explanation.

John McKee


-----Original message-----
From: Scott Klement midrange-l@xxxxxxxxxxxxxxxx
Date: Wed, 25 Nov 2009 14:10:50 -0600
To: Midrange Systems Technical Discussion midrange-l@xxxxxxxxxxxx
Subject: Re: LPR over SSH

Quite frankly, creating the SSH tunnel is the EASY part. All you'll
need to do is run a command like this (from QShell)

ssh -L 7777:127.0.0.1:515 -l userid foo.example.com

The -L switch sets up the tunnel. The syntax is
-L local-port : remote-host : remote-port

So in my example, if you connect to port 7777 on my IBM i, it'll forward
that port over the SSH connection. On the remote end of the SSH
connection, the SSHD will forward all packets to 127.0.0.1 on port 515
(from it's perspective... i.e. it'll be localhost on the server's side,
not localhost on the client's side..)

So anything that connects to my IBM i on port 7777 will be communicating
with the server on port 515 of the local machine. (while that SSH
session is active.)

However, LPR itself is going to give you headaches.

a) AFIAK, there's no way to tell the LPR command (or SNDTCPSPLF) to go
to port 7777. It can only go to the default LPR port, 515.

b) There's no way (on IBM i) to tell a remote output queue (which also
uses LPR) to go to another port, either. It has to be LPR port 515.

c) Most implementations of LPD that I've worked with (mainly on BSD)
require the sender's port number to be in a privileged range. This is a
"security" feature of LPR/LPD, but unfortunately, you can't control the
"from" port in an SSH tunnel to my knowledge.

d) SSH will only allow "root" (QSECOFR on i) to forward privileged ports
like 515....

These four restrictions give you these limitations:

-- you won't be able to have LPD running on the same IBM i partition as
the ssh tunnel. You'll have to have LPD *not* running, since you *have*
to use port 515 for the local side of your tunnel. IBM doesn't give you
a choice (assuming you're using their LPR support, that is) because
their tools can only connect to port 515.

If that's okay with you, then you'll configure the remote output queue,
or the LPR command, to use 127.0.0.1 (or "localhost") as the server name.

-- Assuming you're okay with using a local 515, you still have a problem
because 515 is privileged, so you'll have to create your tunnel as QSECOFR.

-- Even if those two problems don't bother you, the remote side may
decide to reject your connection because the source port isn't in the
right range.

Those are all restrictions of LPR that have little to do with SSH
tunnels. Personally, I'd find another way to transport my spooled files...


jmmckee wrote:
I have seen examples of this with Linux. I start thinking I see how to do this on te i. But, someting is missing.

What I see:

On source computer, create a printer device. Assign loopback address to the device, with a high port number.
Start a qsh process which initiates a ssh process to listen to the loopback address and specified port. Then forward that stream to a remote location.

Problems I see now:
1) the remote location will require username/password authentication. So, an expect script is needed. But, since that process will also spawn sftp, is that an issue? Does the expect script need to do anythig more than just supply the username and password? How does the data stream get to the ssh connection to the remote system? Would a cat command work?

Is there a reference somewhere that might explain this?

John McKee

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.