The environment we're running in is that a perl script on PC is remotely executing a perl script on remA via ssh. That script needs to run a bunch of command sets on remB via ssh, intermixed with some proccessing.
To run the command sets on remB remotely without setting up the public/private keys, the user would have to continually enter the same password over and over again for each command set. By setting up the public/private key, I can remotely run as many sets of commands I want from remA on remB without bothering the user to enter the password over and over.
If ssh had the option to provide the password on the command line then I could programmatically re-enter the password for the user each time, but it doesn't (because of some bad security implications in allowing that), so no dice here.
I could use expect to programmatically provide the password for all the command sets, but then the user would have to enter the password for each session of running this tool. That has its own set of security implications that are non-optimal, so I chose to stay away from this solution as well.
All-in-all, using expect one time to get the public-private keys setup between remA and remB for the user, so they never have to do that again seems to be a good compromise for the level of security that I'm comfortable with.
I do like your explanation of how to reenable ssh tunnels just for me on this machine, as I never thought to try this. However, I'm guessing that doing this would also be politically frowned upon, whereas my current solution seems to not ruffle any feathers.
Things would be so much easier if all I had to do was solve problems from a technical perspective...
Thanks
-Craig
In reply to Re^4: Why I'm Populating authorized_keys with Expect
by cmv
in thread Populating authorized_keys with Expect
by cmv
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |