Hi Everyone,

Here's a bit of background which you can skip unless you want to know why I created this workaround:

There is a printer on the network in the building of my office which does not allow printing through its http interface unless you are physically connected to the network. While in my office, I generally connect to the building's routers with my laptop, as my desk is quite far from the Ethernet socket. At any rate, the printer does not consider the building's router to be a part of the network. I do have an account on a server connected to the printer which I can SSH into. So I have created a bit of a workaround (described below) which allows me to print somewhat seamlessly through CUPS. It is quite an ugly solution but I am mostly curious without potential security issues I have opened up. Of course if anyone has suggestions to make it less ugly, I certainly wouldn't turn them down.

Anyway, here's my most-likely-insecure workaround:

I created a CUPS backend which is really a script whose main function is to run

sudo ssh -l$USER -i$ID_RSA $SERVER < $6 &>> $LOGFILE || exit 1

Where $USER is of course my username on $SERVER, and $ID_RSA is a password-less ssh-key which can only be used by root which I specifically creaated for this workaround. (Note that in a CUPS backend, $6 is the location of a ps file with CUPS creates to be printed)

The corresponding entry to the ssh-key in the authorized_keys file on the server starts with

command="lp -" ssh-rsa ...

So that using the specific $ID_RSA (to my best understanding) will only try to print the file I supply and then close the connection.

The sudo command is allowed by the sudoers file as such:

%lp ALL=NOPASSWD:/usr/bin/ssh -l$USER -i$ID_RSA $SERVER

where of course the variables are the actual ones I would use. The point is only this one very specific command cay be used by users in lp without a password. Furthermore, no users are in the lp group except root (and the CUPS daemon runs as user "daemon" in group lp, so it can sudo this command without a password).

I am sure there are many security holes in this, but I don't know enough to point them out. So I am turning to those with more experience. Thanks for taking the time to read this!

Thanks,
Ryan

Seeing your already got an account on that side of the network,
why not simple set up a http tunnel. Once your set it up. the arrangements
to talk to it will be not messy at all, and it will do the job your
trying to complete.

I am away from my Linux library currently so I can't give you a step
by step break down on setting such a beast up, but most good Linux ssh/ssl
books have all the information you will be needing to get set up and running.

My 2c anyhow.
Cheers.

password-less keys are not a good idea if the client computer is mobile. Someone finding it, stealing it or gaining access to the computer wouldn't have to guess the passphrase unlocking your private key.

The passphrase is only used at the client, to unlock the private key. You can use ssh-agent and ssh-add to enter the passphrase once. This can be integrated with your distro's keychain, where you enter the passphrase once when you log in, and then you don't need to enter it again.

To use ssh-agent and ssh-add manually from the shell:
eval $(ssh-agent)
ssh-add

Your method of using a command in authorized_keys is used to allow certain users to launch backup jobs and nothing else. Perhaps for updates just posted to a website. The advantage is that they don't get shell access. It is possible to launch an ssh command to do that, but a script on the client side could be modified by the remote use, who might not be trusted.

2 members found this post helpful.

Hi,

Thanks for the responses.

WildPossum: I will look into the http tunnel, this might be a good solution. The only thing I fear about this is opening up the printer to everyone, but this might be because I am misunderstanding the concept.

jschiwal: I agree password-less keys are a bad idea. When I tend to think of security risks I suppose I forget about physical security risks. Similarly, I forget that the problem could be that someone changes the actual scripts (I am always more worried what someone can do even if everything goes right). Thanks for bringing these to my attention. Perhaps ssh-agent is the right way to go.

Thanks,
Ryan