Re: LPR over SSH

Hi Scott,

I started with the concept from Linux of LPR over SSH. That was not what I wanted. I wanted a secure print solution. Which this >might< be. I hesitate since I also use sftp to the same location. If a different port is not used, how would the remote system separate sftp and this secure print session? That was why I thought that a new port between the local and remote system could be used.

I apologize for making this as confusing as it has become. When I proposed this to my contact at the remote site, I was told that the company that provides sftp for them was confused. Lots of hops and hoops to go through, for something that seems rather simple.

John McKee


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

Hello,

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.

Sorry, I was under the impression that you were using LPR. The PORT
specified on a DEVD is not for LPR, it's for one of PJL, IPP or SNMP.
You can't do LPR with a 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?

Yes, you'd have one job that's keeping the SSH tunnel open (via Expect
script most likely.) And another job that's doing the actual printing.

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.

How does does having a separate ssh -L on the remote system help?! You
only need one ssh -L as far as I can tell.

Assuming you don't really need LPR (which was the big unsolvable
problem) and are able to use a DEVD-type connection then you could do this:

CRTDEVPRT DEVCLS(*LAN) LANATTACH(*IP)
RMTLOCNAME('127.0.0.1') PORT(21345)
SYSDRVPGM(*IBMPJLDRV)

(fill in other parameters, above, appropriately)

This says that when the writer is running, it makes a connection to the
SAME COMPUTER (127.0.0.1) on port 21345. That means that as far as the
writer knows, it's not connecting to a remote system at all, it's
connecting to the local computer. And that's what you want.

Before starting the writer, you do something like this (via an Expect
script, spawned and waiting in the background)

ssh -L 21345:RemotePrinterIP:9100 -l userid RemoteSSHDComputer

This ssh connection, while active, opens up a tunnel from port 21345 on
your local computer. It sends it across the Internet on port 22 (SSH)
until it gets to the Remote SSD computer. While travelling through that
port 22, the data is encrypted, protected, etc. The remote SSHD
computer then decrypts it and forwards the data on to port 9100 on
RemotePrinterIP.

Note that I change the port to 9100, which is a more likely port if
you're using PJL.

The problem here is that you said you wnated to use LPR. CRTDEVPRT
cannot create LPR connections. You have to use one of the SNDTCPSPLF,
LPR, or a remote output queue if you want to do LPR. And these don't
let you specify a port.

For PJL, it should work fine.
--
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.