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
midrange.com
