in reply to Why I'm Populating authorized_keys with Expect
in thread Populating authorized_keys with Expect

With out knowing exactly what you can and can not do on remA it will difficult to help you!

Can you run nc or ssh on remA?

Is tunnel forwarding also disabled in remB sshd configuration?

Replies are listed 'Best First'.
Re^2: Why I'm Populating authorized_keys with Expect
by cmv (Chaplain) on Nov 25, 2008 at 17:41 UTC
    I cannot run nc on remA, since it is not installed, however I can use ssh.

    The nc binary does not exist on remA, and there is resistance to do what they consider as "downloading" programs to the machine. Since the machine already has perl, it was easier for me to write the simple UDP forwarding perl script and run it there.

    Running ssh on remA is no problem, which is why I'm using this solution. As you surmised, tunnel forwarding is disabled.

    Many thanks for helping, even with limited information. Please feel free to ask or point me to any other possibilities that might occur to you.

    Thanks

    -Craig

[reply]
      It is still not clear to me what is the problem... If you can run ssh from remA, just ssh to remB and run the commands you need there. You will need to add option -t to your ssh commands in order to allocate a pseudo tty, so that passwords are requested. For instance: 
      $ ssh -t remA ssh remB

      [download]

      Anyway, reenabling ssh tunnels just for you is possible and not so tricky. All you need to do is to run another sshd with your own configuration in remA through another ssh connection:

      Copy /etc/ssh/sshd_config to your home and edit it enabling tunnels. Create a new set of dsa and rsa host keys on your home and set the paths on the configuration file accordingly.

      And then... 

      $ ssh remA -L... -R... -o 'ProxyCommand ssh remA sshd -i -f /your/home
+/your_sshd_config' remA-foo

      [download]
[reply]
[d/l]
[select]
        Ok, delving into more gory details...

        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

[reply]

In Section Seekers of Perl Wisdom